Network Working Group Peter Kremer, Ericsson INTERNET-DRAFT Lars-Erik Jonsson, Ericsson Expires: December 2002 June, 2002 ROHC Implementer's Guide Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 an individual submission to the IETF. Comments should be directed to the authors. Abstract This document describes common misinterpretations and some ambiguous points of ROHC [RFC 3095], which defines the framework and four profiles of a robust and efficient header compression scheme. These points have been identified by the members of the ROHC working group during different interoperability test events. Kremer [Page 1] INTERNET-DRAFT ROHC Implementer's Guide June, 2002 Table of Contents 1. Introduction....................................................2 2. CRC Calculation.................................................2 3. Enhanced mode transition procedures.............................3 3.1. Modified transition logic for enhanced transitions............3 3.2. Transition from Reliable to Optimistic mode...................4 3.3. Transition to Unidirectional mode.............................5 4. Other clarifications............................................5 4.1. Padding octet in CRC..........................................5 4.2. Transition to timer-based compression.........................5 4.3. Generic extension header list.................................5 4.4. Generic CSRC list.............................................6 4.5. RTP dynamic chain.............................................6 4.6. Meaning of NBO................................................6 4.7. Implicit updates..............................................6 4.8. IP-ID.........................................................7 4.9. Extension-3 in UO-1-ID packets................................7 4.10. Extension-3 in UOR-2* packets................................7 4.11. Multiple SN options in one feedback packet...................7 4.12. Packet decoding during mode transition.......................7 4.13. How to respond to lost feedback links?.......................8 4.14. What does "presumed zero if absent" mean on page 88?.........8 4.15. CSRC list in UO-1-ID packets.................................8 5. Test Configuration..............................................9 6. Acknowledgment..................................................9 7. References.....................................................10 8. Authors' Addresses.............................................10 Appendix A. Sample CRC algorithm..................................11 1. Introduction ROHC [RFC 3095] addresses a robust and efficient header compression algorithm and as a such its description is 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. 2. 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 [RFC 1662], 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. Kremer [Page 2] INTERNET-DRAFT ROHC Implementer's Guide June, 2002 A PERL implementation of the algorithm (written by Carsten Bormann) can be found in Appendix A. 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 [RFC3095]. 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 [RFC3095], and make those transition diagrams more consistent with the diagram describing the transition to R-mode. However, the differences between the original diagrams of [RFC3095] 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 transition state. That would be the equivalence of enhancing the D_TRANS parameter definition in section 5.6.1 of [RFC3095], to include a definition of Pending state operation. Kremer [Page 3] INTERNET-DRAFT ROHC Implementer's Guide June, 2002 - 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 | | Kremer [Page 4] INTERNET-DRAFT ROHC Implementer's Guide June, 2002 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. Other clarifications 4.1. 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. 4.2. Transition to timer-based compression During transition from window-based compression to timer-based compression it is necessary to keep k large enough to cover both interpretation intervals. 4.3. 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 Kremer [Page 5] INTERNET-DRAFT ROHC Implementer's Guide June, 2002 the first octet is set to 1 then the length of the list is two octets, even if the list is empty. 4.4. Generic CSRC list 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. 4.5. RTP dynamic chain Section 5.7.7.6 defines the static and dynamic parts of the RTP header. This section indicates a 'CC' field in the dynamic chain. The same field can be found in the 'Generic CSRC list' with 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. 4.6. Meaning of NBO In general, an unset flag indicates the normal operation and a set flag indicates unusual behavior. In IPv4 dynamic part (Section 5.7.7.4), if the 'NBO' bit is set, it means that network byte order is used. Although, network byte order is the more common byte alignment. 4.7. 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. For example, a UO-0 packet contains the compressed RTP sequence number (SN). Such a packet also updates RTP timestamp and IPv4 ID, implicitly. Kremer [Page 6] INTERNET-DRAFT ROHC Implementer's Guide June, 2002 4.8. IP-ID According to Section 5.7 IP-ID means the compressed value of the IPv4 header's 'Identification' field. Type 0, 1 and 2 packets contain the compressed value (IP-ID), however IR packets with dynamic chain and IR-DYN packets transmit the original, uncompressed value. This is because the dynamic part of the IPv4 header (Section 5.7.7.4) contains the 'Identification' field instead of the IP-ID. 4.9. 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, values provided in extensions do not update the context, except those in other SN, TS and IP-ID fields (Section 5.7.3.). Note, that SN, TS and IP-ID fields can also be sent in Extension-0, -1 and -2 and the other fields of Extension-3 don't update the context. 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. 4.10. 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). Some flags of the IP header in the extension (e.g. NBO or RND) can change 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. 4.11. Multiple SN options in one feedback packet The length of the sequence number field in the original RTP 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 - that wants to be conform to the specification - should be able to process multiple SN options in one feedback packet. 4.12. 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 Kremer [Page 7] INTERNET-DRAFT ROHC Implementer's Guide June, 2002 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 [RFC3095] 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. 4.13. 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. 4.14. 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. 4.15. CSRC list in UO-1-ID packets This section describes the situation when a UO-1-ID packet carries a CSRC list. Compressed CSRC 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) Kremer [Page 8] INTERNET-DRAFT ROHC Implementer's Guide June, 2002 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. 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 IP/UDP/RTP +--------------+ ROHC 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. 6. Acknowledgment The authors would like thank Vicknesan Ayadurai, Carsten Bormann, Zhigang Liu, Abigail Surtees and Mark West for their contributions and comments. Kremer [Page 9] INTERNET-DRAFT ROHC Implementer's Guide June, 2002 7. References [RFC-3095] C. Bormann, Editor, RObust Header Compression (ROHC), RFC 3095, July 2001. [RFC-1662] W. Simpson, Editor, PPP in HDLC-like Framing, RFC 1662, July 1994. 8. Authors' Addresses Peter Kremer Conformance and Software Test Laboratory Ericsson Hungary H-1300 Bp. 3., P.O. Box 107, HUNGARY Phone: +36-1-437-7033 Fax: +36-1-437-7767 Email: Peter.Kremer@ericsson.com Lars-Erik Jonsson Box 920 Ericsson AB SE-971 28 Lulea, Sweden Phone: +46 920 20 21 07 Fax: +46 920 20 20 99 EMail: lars-erik.jonsson@ericsson.com Kremer [Page 10] INTERNET-DRAFT ROHC Implementer's Guide June, 2002 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; } Kremer [Page 11] INTERNET-DRAFT ROHC Implementer's Guide June, 2002 #--------------------------------- # # 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); Kremer [Page 12]