Network Working Group L-E. Jonsson, Ericsson INTERNET-DRAFT P. Kremer, Ericsson Expires: April 2005 October 25, 2004 ROHC Implementer's Guide Status of this memo By submitting this Internet-Draft, I (we) certify that any applicable patent or other IPR claims of which I am (we are) aware have been disclosed, and any of which I (we) become aware will be disclosed, in accordance with RFC 3668 (BCP 79). By submitting this Internet-Draft, I (we) accept the provisions of Section 3 of RFC 3667 (BCP 78). Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is a submission of the IETF ROHC WG. Comments should be directed to the ROHC WG mailing list, rohc@ietf.org. Abstract This document describes common misinterpretations and some ambiguous points of ROHC [1], which defines the framework and four profiles of a robust and efficient header compression scheme. The members of the ROHC working group have identified these issues during implementation and at the various interoperability test events. Jonsson, et al. [Page 1] INTERNET-DRAFT ROHC Implementer's Guide October 25, 2004 Table of Contents 1. Introduction.....................................................3 2. CRC calculation and coverage issues..............................3 2.1. CRC calculation.............................................3 2.2. Padding octet in CRC........................................3 2.3. CRC coverage in CRC feedback options........................3 2.4. CRC coverage of the ESP NULL header.........................4 3. Enhanced mode transition procedures..............................4 3.1. Modified transition logic for enhanced transitions..........4 3.2. Transition from Reliable to Optimistic mode.................5 3.3. Transition to Unidirectional mode...........................6 4. Timestamp encoding considerations................................6 4.1. Encoding of TS values.......................................6 4.2. Interpretation intervals for TS encoding....................6 4.3. Recalculating TS_OFFSET.....................................7 4.4. TS_STRIDE and the Tsc flag in Extension 3...................7 5. List compression issues..........................................7 5.1. Generic extension header list...............................7 5.2. CSRC list items in RTP dynamic chain........................8 5.3. RTP dynamic chain...........................................8 5.4. Compressed lists in UO-1-ID packets.........................8 5.5. Bit masks in list compression...............................8 5.6. Headers compressed with list compression....................9 5.7. ESP NULL header list compression............................9 6. Updating properties..............................................9 6.1. Implicit updates............................................9 6.2. Updating properties of UO-1*................................9 7. Context management and CID/context re-use.......................10 7.1. Compressor and decompressor MUST keep MAX_CID contexts.....10 7.2. CID/context re-use.........................................10 7.2.1. Re-using a CID/context with the same profile..........10 7.2.2. Re-using a CID/context with a different profile.......11 7.3. Context updating properties for IR packets.................11 8. Other protocol clarifications...................................11 8.1. Meaning of NBO.............................................11 8.2. IP-ID......................................................11 8.3. Extension-3 in UO-1-ID packets.............................12 8.4. Extension-3 in UOR-2* packets..............................12 8.5. Multiple SN options in one feedback packet.................12 8.6. Multiple CRC options in one feedback packet................13 8.7. Packet decoding during mode transition.....................13 8.8. How to respond to lost feedback links?.....................13 8.9. What does "presumed zero if absent" mean on page 88?.......13 8.10. UOR-2 in profile 2 (UDP)..................................14 8.11. Sequence number LSB's in IP extension headers.............14 8.12. Expecting UOR-2 ACKs in O-mode............................14 9. ROHC negotiation clarifications.................................15 10. PROFILES suboption in ROHC-over-PPP............................15 11. Test Configuration.............................................16 12. Security considerations........................................16 Jonsson, et al. [Page 2] INTERNET-DRAFT ROHC Implementer's Guide October 25, 2004 13. Acknowledgment.................................................17 14. References.....................................................17 15. Authors' Addresses.............................................17 Appendix A - Sample CRC algorithm..................................18 Appendix B - Potential improvements in updated profiles............20 Appendix C - Issues identified but not yet resolved................20 1. Introduction ROHC [1] defines a robust and efficient header compression algorithm, and its description is rather long and complex. During the implementation and the interoperability tests of the algorithm some unclear areas have been identified. This document tries to collect and clarify these points. Note that all section and chapter references in this document refer to [1], if not stated otherwise. 2. CRC calculation and coverage issues 2.1. CRC calculation ROHC uses CRC checksum in order to provide some protection against bit errors. CRC is used in the segmentation protocol and in the compressed packets, as well. Section 5.2.5.2 describes the segmentation protocol and refers to [3], which describes a well-defined CRC algorithm for 32 bit checksums. Although, Section 5.9 only defines the polynomials for 3, 7 and 8-bit long checksum, the same algorithm can be used in these cases as well. A PERL implementation of the algorithm (written by Carsten Bormann) can be found in Appendix A. 2.2. Padding octet in CRC According to Section 5.9.1, in case of IR and IR-DYN packets the CRC "is calculated over the entire IR or IR-DYN packet, excluding Payload and including CID or Add-CID octet". Padding isn't meant to be meaningful part of a packet and not included in CRC calculation. As a result, CRC doesn't cover the Add-CID octet for CID 0, either. 2.3. CRC coverage in CRC feedback options Section 5.7.6.3 states "The CRC option contains an 8-bit CRC computed over the entire feedback payload, without the packet type and code octet, but including any CID fields, using the polynomial of section 5.9.1". However, it does not mention how the "size" field is handled, if present. Since the "size" field can be considered an extension of the "code" field, it must be treated as the "code" field, i.e. the "size" field is not covered by the CRC. Jonsson, et al. [Page 3] INTERNET-DRAFT ROHC Implementer's Guide October 25, 2004 2.4. CRC coverage of the ESP NULL header Section 5.8.7 gives the CRC coverage of the ESP NULL header as "Entire ESP header". This should be interpreted as being only the initial part of the header (i.e. SPI and Sequence number), and not the trailer part at the end of the payload. Therefore, the ESP NULL header will have the same CRC coverage as the ESP header used in the ESP profile (section 5.7.7.7). 3. Enhanced mode transition procedures To reduce transmission overhead and computational complexity (including CRC calculation) associated with feedback packets sent for each decompressed packet during mode transition, a decompressor can be implemented with slightly modified mode transition procedures, compared to those defined in [1]. These modifications affect transitions to Optimistic and Unidirectional modes of operation, i.e. the transitions described in sections 5.6.5 and 5.6.6 of [1], and make those transition diagrams more consistent with the diagram describing the transition to R-mode. However, the differences between the original diagrams of [1] were motivated by robustness concerns for mode transitions to Optimistic and Unidirectional modes. To avoid deadlock situations in mode transitions, these aspects must be addressed also when a decompressor implements the enhanced transition procedures, and that is done by following a slightly modified definition of the decompressor transition states. All aspects related to implementation of the enhanced transition procedures are described in subsequent chapters. Note that these modified operations should be seen only as an improved decompressor implementation, since interoperability is not at all affected. A decompressor implemented according to the optimized procedures would be able to interoperate with an RFC3095 compressor, as well as a decompressor implemented according to the procedures described in RFC3095 would do. 3.1. Modified transition logic for enhanced transitions The intent with these enhanced transition procedures is to allow the decompressor to stop sending feedback packets for all packets decompressed during the second half of the transition procedure, i.e. after an appropriate IR/IR-DYN/UOR-2 packet has been received from the compressor. In the transition diagrams, sections 3.2 and 3.3 below, this is realized by allowing the decompressor transition parameter (D_TRANS) to be set to P (Pending) at that stage. However, as mentioned above, there are robustness concerns related to this optimization, and to avoid deadlock situations with never completed transitions as a result of feedback losses, the decompressor must continue to send feedback at least periodically, also when in Pending Jonsson, et al. [Page 4] INTERNET-DRAFT ROHC Implementer's Guide October 25, 2004 transition state. That would be the equivalence of enhancing the D_TRANS parameter definition in section 5.6.1 of [1], to include a definition of Pending state operation. - D_TRANS: Possible values for the D_TRANS parameter are (I)NITIATED, (P)ENDING and (D)ONE. D_TRANS MUST be initialized to D, and a mode transition can be initiated only when D_TRANS is D. While D_TRANS is I, the decompressor sends a NACK or ACK carrying a CRC option for each packet received. When D_TRANS is set to P, the decompressor do not have to send a NACK or ACK for each packet received, but it MUST continue to send feedback on a regular basis, and all feedback packets sent MUST include the CRC option. This ensures that all mode transitions will be completed also in case of feedback losses. 3.2. Transition from Reliable to Optimistic mode The enhanced procedure for transition from Reliable to Optimistic mode is shown below: Compressor Decompressor ---------------------------------------------- | | | ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I | +-<-<-<-<-<-<-<-+ | C_TRANS = P |-<-<-<-+ | C_MODE = O | | |->->->-+ IR/IR-DYN/UOR-2(SN,O) | | +->->->->->->->-+ | |->-.. +->->->-| D_TRANS = P |->-.. | D_MODE = O | ACK(SN,O) +-<-<-<-| | +-<-<-<-<-<-<-<-+ | C_TRANS = D |-<-<-<-+ | | | |->->->-+ UO-0, UO-1* | | +->->->->->->->-+ | | +->->->-| D_TRANS = D | | Jonsson, et al. [Page 5] INTERNET-DRAFT ROHC Implementer's Guide October 25, 2004 3.3. Transition to Unidirectional mode The enhanced procedure for transition to Unidirectional mode is shown on the following figure: Compressor Decompressor ---------------------------------------------- | | | ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I | +-<-<-<-<-<-<-<-+ | C_TRANS = P |-<-<-<-+ | C_MODE = U | | |->->->-+ IR/IR-DYN/UOR-2(SN,U) | | +->->->->->->->-+ | |->-.. +->->->-| D_TRANS = P |->-.. | | ACK(SN,U) +-<-<-<-| | +-<-<-<-<-<-<-<-+ | C_TRANS = D |-<-<-<-+ | | | |->->->-+ UO-0, UO-1* | | +->->->->->->->-+ | | +->->->-| D_TRANS = D | | D_MODE= U 4. Timestamp encoding considerations 4.1. Encoding of TS values RTP Timestamp values (TS) are always encoded using W-LSB encoding, both when sent scaled and when sent unscaled. For TS values sent in Extension 3, W-LSB encoded values are sent using the self-describing variable-length format (section 4.5.6), and this applies to both scaled and unscaled values. 4.2. Interpretation intervals for TS encoding Section 4.5.4 defines the interpretation interval, p, for timer-based compression of the RTP timestamp. However, Section 5.7 defines a different interpretation interval, which is defined as the interpretation interval to use for all TS values. It is thus unclear which p-value to use, at least for timer-based compression. The way this should be interpreted is that the p-value differs depending on whether timer-based compression is enabled or not. For timer-based compression, the interpretation interval of section 4.5.4, p = 2^(k-1) - 1, is used for TS. Otherwise, the interval of section 5.7, p = 2^(k-2) - 1, is used for TS with regular W-LSB encoding. Jonsson, et al. [Page 6] INTERNET-DRAFT ROHC Implementer's Guide October 25, 2004 Since two different p-values are used, the compressor must take this into account during the process of enabling timer-based compression. Before timer-based compression can be used, the decompressor will have to inform the compressor (on a per-channel basis) about its clock resolution. Further, the compressor has to send (on a per- context basis) a non-zero TIME_STRIDE to the decompressor. When the compressor is confident that the decompressor has received the TIME_STRIDE value, it can switch to timer-based compression. During this transition from window-based compression to timer-based compression, it is necessary that the compressor keep k large enough to cover both interpretation intervals. 4.3. Recalculating TS_OFFSET TS can be sent unscaled if the TS value change does not match the established TS_STRIDE, but the TS_STRIDE might still stay unchanged. To ensure correct decompression of subsequent packets, the decompressor should therefore always recalculate the RTP TS modulo, TS_OFFSET, when a packet with an unscaled TS value is received. 4.4. TS_STRIDE and the Tsc flag in Extension 3 The Tsc flag in Extension 3 indicates whether TS is scaled or not. It must be noted that the Tsc value apply to all TS bits, also if there are no TS bits in the extension itself. Note also that if Tsc=1, TS is scaled using context(TS_STRIDE), not value(TS_STRIDE) as is said in the legend for Extension 3 in section 5.7.5. When a compressor uses Extension 3 to re-establish a new value for TS_STRIDE, it must send unscaled TS together with TS_STRIDE for some packets until decompressor confidence is obtained. When the TS_STRIDE field is present in Extension 3, the Tsc flag must thus be set to 0. 5. List compression issues 5.1. Generic extension header list Section 5.7.7.4 defines the static and dynamic parts of the IPv4 header. This section indicates a 'Generic extension header list' field in the dynamic chain, which has a variable length. The detailed description of this field can be found in Section 5.8.6.1. The generic extension header list starts with an octet that is always present, so its length is one octet, at least. If the 'GP' bit in the first octet is set to 1 then the length of the list is two octets, even if the list is empty. Jonsson, et al. [Page 7] INTERNET-DRAFT ROHC Implementer's Guide October 25, 2004 5.2. CSRC list items in RTP dynamic chain Section 5.7.7.6 defines the static and dynamic parts of the RTP header. This section indicates a 'Generic CSRC list' field in the dynamic chain, which has a variable length. This field uses the same encoding rules as the 'Generic extension header list' in the IPv4 header, so the same rules apply to its length. 5.3. RTP dynamic chain Section 5.7.7.6 defines the static and dynamic parts of the RTP header. In the dynamic part, a 'CC' field indicates the number of CSRC items present in the 'Generic CSRC list'. A 'CC' field can also be found within the 'Generic CSRC list' (when present), and these fields would then have the same meaning. In order to decode a compressed packet correctly it's necessary to know the 'CC' value because it has serious impact on the packet's length. In normal case, the values of the fields are equal. Proposed behavior if the values are different: Both fields are within the RTP dynamic part but only the second 'CC' field resides inside the 'Generic CSRC list' together with the XI items. Since the 'CC' value determines the number of XI items in the CSRC list and isn't used otherwise, the first CC field should be ignored and only the second field (inside the CSRC list) should be used for incoming packets. For outgoing packets both fields should be set to the same value. 5.4. Compressed lists in UO-1-ID packets This section describes the situation when a UO-1-ID packet carries a compressed list. Compressed lists are encoded using Encoding Type 0 (section 5.7.5 and 5.8.6.1) and every list may have a unique identifier (gen_id). The identifier is present in U/O-mode when the compressor decides that it may use this list as a future reference. On one hand, the decompressor shouldn't save the list because UO-1-ID packets doesn't update the context. On the other hand, the decompressor updates its translation table whenever an (Index, item) pair is received (section 5.8.1). The decompressor must be able to handle such a packet, thus it has to behave as described in the latter case. According to section 5.8.1.2, the compressor must increment Counter by 1. 5.5. Bit masks in list compression A 7-bit or 15-bit mask may be used in the insertion and/or removal schemes for compressed lists. It should be noted that even if a list has more than 7 items, a 7-bit mask could be used as long as changes are only applied in the first part of the reference list, and items with an index not covered by the 7-bit mask are thus kept unchanged. Jonsson, et al. [Page 8] INTERNET-DRAFT ROHC Implementer's Guide October 25, 2004 5.6. Headers compressed with list compression In section 5.8, it is stated that headers which can be part of extension header chains INCLUDE AH, null ESP, minimal encapsulation, GRE, and IPv6 extensions. This list of headers which can be compressed is correct, but the work INCLUDE should not be there, since only the header types listed can actually be handled. 5.7. ESP NULL header list compression Due to the offset of the fields in the trailer part of the ESP header, a compressor must only compress packets containing at most one NULL ESP header. 6. Updating properties 6.1. Implicit updates If an updating packet (e.g. R-0-CRC or UO-0) contains information about a specific field X (compressed RTP sequence number, typically), then X is updated according to the content of that packet. But this packet implicitly updates all other inferred fields (i.e. RTP timestamp) according to the current mode and the appropriate mapping function of the updated and the inferred fields. An updating packet thus updates the reference values of all header fields, either explicitly or implicitly, with an exception for the UO-1-ID packet, which only updates TS, SN, IP-ID, and sequence numbers of IP extension headers (see 5.7.3). In UO-mode, all packets are updating packets, while in R-mode all packets with a CRC are updating packets. For example, a UO-0 packet contains the compressed RTP sequence number (SN). Such a packet also implicitly updates RTP timestamp, IPv4 ID, and sequence numbers of IP extension headers. 6.2. Updating properties of UO-1* In section 5.7.3, the updating properties of UO-1* are stated: "Values provided in extensions, except those in other SN, TS, or IP-ID fields, do not update the context." However, also sequence number fields of extension headers must be updated, which means the updating properties should be rephrased as: "The only values provided in extensions that update the context are the additional bits for the SN, TS, or IP-ID fields. Other values provided in extensions do not update the context. Note that sequence number fields of extension headers are also updated." Jonsson, et al. [Page 9] INTERNET-DRAFT ROHC Implementer's Guide October 25, 2004 7. Context management and CID/context re-use 7.1. Compressor and decompressor MUST keep MAX_CID contexts As part of the negotiated channel parameters, compressor and decompressor have through the MAX_CID parameter agreed on the highest context identification (CID) number to be used. By agreeing on MAX_CID, both compressor and decompressor also agrees to provide memory resources to host at lest MAX_CID+1 contexts, and an established context with CID within this negotiated space MUST be kept by both compressor and decompressor until either the CID gets re-used, or the channel is taken down or re-negotiated. 7.2. CID/context re-use As part of the channel negotiation, the maximal number of active contexts supported is negotiated between the compressor and the decompressor through the MAX_CID parameter. The value of MAX_CID can of course vary enormously between different link scenarios, as well as the load in terms of actual packet streams to compress. Depending on link technology, the ROHC channel lifetime will also vary from almost permanent to rather short-lived. However, in general it is not expected that resources will be allocated for more contexts than what can reasonably be expected to be active concurrently over the link. As a consequence hereof, context identifiers (CIDs) and context memory are resources that will have to be re-used by the compressor as part of what can be considered normal operation. How context resources are re-used is in RFC 3095 [1] and subsequent ROHC standards basically left unspecified and up to implementation. However, re-using a CID and its allocated memory is not always as simple as initiating a contexts with a previously unused CID. Because some profiles can be operating in various modes where packet formats vary depending on current mode, care has to be taken to ensure that the old context data will be completely and safely overwritten, eliminating the risk of undesired side effects from interactions between old and new context data. On a high level, CID/context re-use can be of two kinds, either re- use for a new context based on the same profile as the old context, or for a new context based on a different profile. These cases, are discussed separately in the following two subsections. 7.2.1. Re-using a CID/context with the same profile For multi-mode profiles, such as those defined in RFC 3095 [1], when a CID/context is re-used for a new context based on the same profile as the old context, the current mode of operation MUST be inherited from the old to the new context. The reason for this is that there is no reliable way for the compressor to inform the decompressor that a CID/context re-use is happening. The decompressor can thus not be Jonsson, et al. [Page 10] INTERNET-DRAFT ROHC Implementer's Guide October 25, 2004 expected to flush the context memory for the CID, and there is no way to trigger a safe mode switching, which requires a decompressor- initiated handshake procedure, as defined in section 5.6 of [1]. It should be noted that the rule of mode inheritance applies also when the CONTEXT_REINITIALIZATION signal is used to reinitiate an entire context. 7.2.2. Re-using a CID/context with a different profile When a CID is re-used for a new context based on a different profile than the old context, operation with that context MUST start in the initial mode of the profile (if it is a multi-mode profile). This applies both to IR-initiated new contexts and profile downgrades with IR-DYN (e.g. the IP/UDP/RTP->IP/UDP downgrade in [1] section 5.11.1). A CID for an R-mode operating context SHOULD NOT be re-used for a new context based on a different profile than the old context, because of the R-0/R-1 misinterpretation risk (these packets have no CRC). If a compressor still wants or has to do this, the compressor must be very careful to minimize the misinterpretation risk, e.g. by not using packets of types beginning with 00 or 10 before the compressor is highly confident that the new context has successfully been initiated at the decompressor. 7.3. Context updating properties for IR packets It should be noted that an IR does not flush the whole context, but updates all fields carried in the IR header. Similarly, an IR without a dynamic chain simply updates the static part of the context, while the rest of the context is left unchanged. 8. Other protocol clarifications 8.1. Meaning of NBO In general, an unset flag indicates the normal operation and a set flag indicates unusual behavior. However, in IPv4 dynamic part (Section 5.7.7.4), if the 'NBO' bit is set, it means that network byte order is used. 8.2. IP-ID According to Section 5.7 IP-ID means the compressed value of the IPv4 header's 'Identification' field. Compressed packets contain this compressed value (IP-ID), while IR packets with dynamic chain and IR- DYN packets transmit the original, uncompressed Identification field value. The IP-ID field always represents the Identification value of the innermost IPv4 header whose corresponding RND flag is not 1. Jonsson, et al. [Page 11] INTERNET-DRAFT ROHC Implementer's Guide October 25, 2004 If RND or RND2 is set to 1, the corresponding IP-ID(s) is(are) sent as 16-bit original Identification value(s) at the end of the compressed base header, according to the IP-ID description (see the beginning of section 5.7). It should be noted that when RND*=0, IP-ID is always compressed, i.e. expressed as an SN offset and byte-swapped if NBO=0. This is the case even when 16 bits of IP-ID is sent in extension 3. 8.3. Extension-3 in UO-1-ID packets Extension-3 is applied to give values and indicate changes to fields other than SN, TS and IP-ID in IP header(s) and RTP header. In case of UO-1-ID packets, it should be noted that values provided in extensions do not update the context, with an exception for SN, TS and IP-ID fields, which always update the context (Section 5.7.3.). It should also be noted that a UO-1-ID packet with Extension 3 must never be sent with RND flags that changes the packet interpretation, i.e. that would violate the base condition for UO-1-ID (at least one RND value must be 0). Besides, usage of Extension-3 in UO-1-ID can be useful to compress a transient change in a packet stream. For example, if a field's value changes in the current packet but in the next packet it returns to its regular behavior. E.g. changes in TTL. 8.4. Extension-3 in UOR-2* packets If Extension-3 is used in a UOR-2* packet then the information of the extension updates the context (Section 5.7.4). Some flags of the IP header in the extension (e.g. NBO or RND) changes the interpretation of fields in UOR-2* packets. In these cases, when a flag changes in Extension-3, a decompressor should re-parse the UOR-2* packet. 8.5. Multiple SN options in one feedback packet The length of the sequence number field in the original ESP header is 32 bits. A decompressor can't send back all the 32 bits in a feedback packet unless it uses multiple SN options in one feedback packet. Section 5.7.6.1 declares that a FEEDABCK-2 packet can contain variable number of feedback options and the options can appear in any order. A compressor should be able to process multiple SN options in one feedback packet. Jonsson, et al. [Page 12] INTERNET-DRAFT ROHC Implementer's Guide October 25, 2004 8.6. Multiple CRC options in one feedback packet Although it is never required to have more than one single CRC option in a feedback packet, having multiple CRC options is still allowed. If multiple CRC options are included, all such CRC options will be identical, as they will be calculated over the same header. 8.7. Packet decoding during mode transition Each ROHC profile defines its own set of packet formats, and also its own feedback packets. The use of various operational modes is also defined by each specific profile. A decompressor can therefore not initiate a mode transfer request before at least one packet of a new context has been correctly decompressed, establishing the context based on one specific profile (as specified in IR packets). First then the context has been established, the decompressor knows the profile used, which modes are defined by that profile, and the feedback packet formats available. If the transition procedures in sections 5.6.5 and 5.6.6 of [1] are followed (and not the enhanced procedures described in section 3 of this document), it is important to note that type 0 or type 1 packets may be received by the decompressor during the first half of the transition procedure, and these packets must not mistakenly be interpreted as the packets sent by the compressor to indicate completed transition. The decompressor side must therefore keep track of the transition status, e.g. with an additional parameter. If the enhanced transition procedures described in section 3 of this document are used, the D_TRANS parameter can serve this purpose since its definition and usage is slightly modified. 8.8. How to respond to lost feedback links? One potential issue that might have to be considered, depending on link technology, is whether feedback links might get lost, and in such cases how this is handled. When the compressor is notified that the feedback channel is down, the compressor must be able to handle it by restarting compression with creating a new context. Creating a new context also implies to use a new CID value. Generally, feedback links are not expected to disappear when once present, but it should be noted that this might be the case for certain link technologies. 8.9. What does "presumed zero if absent" mean on page 88? On page 88, RFC 3095 says that R-P contains the absolute value of RTP Padding bit and it's presumed zero if absent. It could be absent from RTP header flags and fields, from the extension type 3 or from the ROHC packet. It's been agreed that the RTP padding bit is presumed zero if absent from the RTP header flags. Jonsson, et al. [Page 13] INTERNET-DRAFT ROHC Implementer's Guide October 25, 2004 8.10. UOR-2 in profile 2 (UDP) One single new format is defined for UOR-2 in profile 2, which replaces all three (UOR-2, UOR-2-ID, UOR-2-TS) formats from profile 1. The same UOR-2 format is thus used independent of if there are IP headers with a corresponding RND=1 or not. 8.11. Sequence number LSB's in IP extension headers In section 5.8.5, formats are defined for compression of IP extension header fields. These include compressed sequence number fields, and it is said that these fields contain "LSB of sequence number". This means these sequence numbers are not "LSB-encoded" as e.g. the RTP sequence number with an interpretation interval, but are actually just the LSB's of the uncompressed fields. 8.12. Expecting UOR-2 ACKs in O-mode It should be noted that the use of UOR-2 ACKs in O-mode, as discussed in section 5.4.1.1.2, is indeed optional, and a decompressor can send ACKs for other purposes than actually acking the UOR-2, without then having to continue sending them for all UOR-2. Similarly, compressor implementations can totally ignore UOR-2 ACKs for the purpose of adapting the optimistic approach strategies. Current implementation experience also suggests using that approach, and the recommendation is thus to not make use of the optional ACK mechanism in O-mode, neither in compressor nor in decompressor implementations. For implementers who still want to make use of the optional O-mode acks, the following clarifications should be taken into account. Section 5.4.1.1.2 discusses the use of optional UOR-2 ACKs in O-mode, and explains a conceptual algorithm for a compressor to determine whether such ACKs can be expected from the decompressor, simply using a condition based on unspecified parameters k_3 and n_3. However, what is not clearly pointed out is the importance of being very careful when implementing this confidence algorithm, as using an incorrect expectation on UOR-2 ACKs as a basis for compressor behavior will significantly degrade the compression performance. If a compressor implementation wants to adapt its optimistic approach behavior on potential UOR-2 ACK usage, the confidence algorithm for determining UOR-2 ACK usage must be carefully designed, with k_3 and n_3 having values much larger than 1, as UOR-2 ACKs can be sent from a decompressor for other purposes than to actually acknowledge the UOR-2 packet, e.g. to send feedback data such as clock resolution, or to initiate a mode transfer. Before adapting a compressor to the potential use of UOR-2 ACKs, the implementer must ensure all aspects are considered by the confidence algorithm. Jonsson, et al. [Page 14] INTERNET-DRAFT ROHC Implementer's Guide October 25, 2004 9. ROHC negotiation clarifications According to section 4.1, the link layer must provide means to negotiate e.g. the channel parameters listed in section 5.1.1. One of these parameters is the PROFILES parameter, which is said to be a set of non-negative integers where each integer indicates a profile supported by the decompressor. This can be interpreted as if it is sufficient to have a mechanism to announce profile support from decompressor to compressor. However, things are a little bit more complicated than that. Each profile is identified by a 16-bit value, where the 8 LSB bits indicate the actual profile, and the 8 MSB bits indicate the variant of that profile (see chapter 8). In the ROHC headers sent over the link, the profile used is identified only with the 8 LSB bits, which means that the compressor and decompressor must have agreed on which variant to use for each profile. This can be done in various ways, but the negotiation protocol must provide means to do it. In conclusion, the negotiation protocol must be able to communicate to the compressor the set of profiles supported by the decompressor, and when multiple variants of the same profile are available, also provide means for the decompressor to know which variant will be used by the compressor. This basically means that the PROFILES set after negotiation must not include more than one variant of the same profile. 10. PROFILES suboption in ROHC-over-PPP The logical union of suboptions for IPCP and IPV6CP negotiations, as specified by ROHC over PPP [2], can not be used for the PROFILES suboption, as the whole union would then have to be considered within each of the two IPCP negotiations, to avoid getting an ambiguous profile set. An implementation of RFC 3241 must therefore make sure the same profile set is negotiated for both IPv4 and IPv6 (IPCP and IPV6CP). Jonsson, et al. [Page 15] INTERNET-DRAFT ROHC Implementer's Guide October 25, 2004 11. Test Configuration ROHC is used to compress IP/UDP/RTP, IP/UDP and IP/ESP headers, thus every ROHC implementation has an interface that can send and receive IP packets (i.e. Ethernet). On the other hand, there must be an interface (a serial link for example) or other means of transport (an IP/UDP flow), which can transmit ROHC packets. Having these two interfaces several configurations can be set up. The figure below shows sample configurations that can be used for testing a ROHC implementation: IP/UDP/RTP +------------+ ROHC +--------------+ IP/UDP/RTP packets | ROHC | packets | ROHC | packets ---------->| Compressor |-----> ----->| Decompressor |----------> +------------+ +--------------+ Unfortunately, comparing the IP/UDP/RTP packets at the endpoints can only show whether the reconstructed stream differs from the original or not. In order to identify the place of the error more detailed tests are needed. The next figure shows another possible scenario: IP/UDP/RTP +------------+ ROHC ROHC +--------------+ IP/UDP/RTP packets | ROHC | packets packets | ROHC | packets +----->| Compressor |----->+ +----->| Decompressor |----->+ | +------------+ | | +--------------+ | | | | | | +------------+ | | +------------+ | | | Test | | | | Test | | +<-----| Equipment |<-----+ +<------| Equipment |<------+ +------------+ +------------+ In the first case, the test equipment generates the RTP stream and also acts as a ROHC decompressor. The tester must recognize if the original RTP stream was compressed in a bad way and gives an alarm. In the second case, it is the test equipment that sends the compressed ROHC packets and the Decompressor reconstructs the RTP stream. Since the tester knows the ROHC packets and the reconstructed RTP stream it can detect if the Decompressor makes a mistake. 12. Security considerations This document provides a number of clarifications to [1], but it does not make any changes or additions to the protocol. As a consequence, the security considerations of [1] apply without additions. Jonsson, et al. [Page 16] INTERNET-DRAFT ROHC Implementer's Guide October 25, 2004 13. Acknowledgment The authors would like to thank Vicknesan Ayadurai, Carsten Bormann, Mikael Degermark, Ghyslain Pelletier, Zhigang Liu, Abigail Surtees, Mark West, Kristofer Sandlund, Tommy Lundemo, Alan Kennington and Remi Pelland for their contributions and comments. 14. References [1] C. Bormann, et al., "RObust Header Compression (ROHC)", RFC 3095, July 2001. [2] C. Bormann, "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002. [3] W. Simpson, "PPP in HDLC-like Framing", RFC 1662, July 1994. 15. Authors' Addresses Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea, Sweden Phone: +46 8 404 29 61 EMail: lars-erik.jonsson@ericsson.com Peter Kremer Conformance and Software Test Laboratory Ericsson Hungary H-1300 Bp. 3., P.O. Box 107, HUNGARY Phone: +36 1 437 7033 EMail: peter.kremer@ericsson.com Jonsson, et al. [Page 17] INTERNET-DRAFT ROHC Implementer's Guide October 25, 2004 Appendix A - Sample CRC algorithm #!/usr/bin/perl -w use strict; #================================= # # ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02 # # This little demo shows the three types of CRC in use in RFC 3095, # the robust header compression standard. Type your data in # hexadecimal form and the press Control+D. # #--------------------------------- # # utility # sub dump_bytes($) { my $x = shift; my $i; for ($i = 0; $i < length($x); ) { printf("%02x ", ord(substr($x, $i, 1))); printf("\n") if (++$i % 16 == 0); } printf("\n") if ($i % 16 != 0); } #--------------------------------- # # The CRC calculation algorithm. # sub do_crc($$$) { my $nbits = shift; my $poly = shift; my $string = shift; my $crc = ($nbits == 32 ? 0xffffffff : (1 << $nbits) - 1); for (my $i = 0; $i < length($string); ++$i) { my $byte = ord(substr($string, $i, 1)); for( my $b = 0; $b < 8; $b++ ) { if (($crc & 1) ^ ($byte & 1)) { $crc >>= 1; $crc ^= $poly; } else { $crc >>= 1; } $byte >>= 1; } } printf "%2d bits, ", $nbits; printf "CRC: %02x\n", $crc; Jonsson, et al. [Page 18] INTERNET-DRAFT ROHC Implementer's Guide October 25, 2004 } #--------------------------------- # # Test harness # $/ = undef; $_ = <>; # read until EOF my $string = ""; # extract all that looks hex: s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg; dump_bytes($string); #--------------------------------- # # 32-bit segmentation CRC # Note that the text implies this is complemented like for PPP # (this differs from 8, 7, and 3-bit CRC) # # C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 + # x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32 # do_crc(32, 0xedb88320, $string); #--------------------------------- # # 8-bit IR/IR-DYN CRC # # C(x) = x^0 + x^1 + x^2 + x^8 # do_crc(8, 0xe0, $string); #--------------------------------- # # 7-bit FO/SO CRC # # C(x) = x^0 + x^1 + x^2 + x^3 + x^6 + x^7 # do_crc(7, 0x79, $string); #--------------------------------- # # 3-bit FO/SO CRC # # C(x) = x^0 + x^1 + x^3 # do_crc(3, 0x6, $string); Jonsson, et al. [Page 19] INTERNET-DRAFT ROHC Implementer's Guide October 25, 2004 Appendix B - Potential improvements in updated profiles Regarding the CC field and CSRC list, the following interpretation has been proposed as an improvement: "It should be noted that when the value of this CC field is equal to zero, there is no Generic CSRC list present in the dynamic chain, i.e. the field comment should have said "variable length, present if CC > 0". " Appendix C - Issues identified but not yet resolved These issues have been identified but are still under discussion on the ROHC WG mail list. Resolutions to these issues will have to be added in later revisions of this document. * Slope used to compress/decompress RTP Timestamp Jonsson, et al. [Page 20] INTERNET-DRAFT ROHC Implementer's Guide October 25, 2004 Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This Internet-Draft expires April 25, 2005. Jonsson, et al. [Page 21]