Network Working Group L-E. Jonsson Request for Comments: 3242 G. Pelletier Category: Standards Track Ericsson April 2002 RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved.
AbstractThis document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed in ROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression making use of this header-free packet. 1. Introduction....................................................2 2. Terminology.....................................................4 3. Overview of the Link-Layer Assisted Profile.....................5 3.1. Providing Packet Type Identification.....................6 3.2. Replacing the Sequence Number............................6 3.3. CRC Replacement..........................................7 3.4. Applicability of This Profile............................7 4. Additions and Exceptions Compared to ROHC RTP...................8 4.1. Additional Packet Types..................................8 4.1.1. No-Header Packet (NHP)..........................8 4.1.2. Context Synchronization Packet (CSP)............8 4.1.3. Context Check Packet (CCP)......................9
4.2. Interfaces Towards the Assisting Layer..................11 4.2.1. Interface, Compressor to Assisting Layer.......11 4.2.2. Interface, Assisting Layer to Decompressor.....12 4.3. Optimistic Approach Agreement...........................13 4.4. Fast Context Initialization, IR Redefinition............13 4.5. Feedback Option, CV-REQUEST.............................14 4.6. Periodic Context Verification...........................15 4.7. Use of Context Identifier...............................15 5. Implementation Issues..........................................15 5.1. Implementation Parameters and Signals...................15 5.1.1. Implementation Parameters at the Compressor....16 5.1.2. Implementation Parameters at the Decompressor..17 5.2. Implementation over Various Link Technologies...........18 6. IANA Considerations............................................18 7. Security Considerations........................................18 8. Acknowledgements...............................................18 9. References.....................................................19 10. Authors' Addresses.............................................20 11. Full Copyright Statement.......................................21 VJHC, IPHC] have been developed to compress the network and transport protocol headers [IPv4, IPv6, UDP, TCP], and these schemes have been successful in improving efficiency over many wired bottleneck links, such as modem connections over telephone networks. In addition to IP, UDP, and TCP compression, an additional compression scheme called Compressed RTP [CRTP] has been developed to further improve compression efficiency for the case of real-time traffic using the Real-Time Transport Protocol [RTP]. The schemes mentioned above have all been designed taking into account normal assumptions about link characteristics, which traditionally have been based on wired links only. However, with an increasing number of wireless links in the Internet paths, these assumptions are no longer generally valid. In wireless environments, especially wide coverage cellular environments, relatively high error rates are tolerated in order to allow efficient usage of the radio resources. For real-time traffic, which is more sensitive to delays than to errors, such operating conditions will be norm over, for example, 3rd generation cellular links, and header compression must therefore tolerate packet loss. However, with the previously mentioned schemes, especially for real-time traffic compressed by CRTP, high error rates have been shown to significantly degrade
header compression performance [CRTPC]. This problem was the driving force behind the creation of the RObust Header Compression (ROHC) WG in the IETF. The ROHC WG has developed a header compression framework on top of which profiles can be defined for different protocol sets, or for different compression strategies. Due to the limited packet loss robustness of CRTP, and the demands of the cellular industry for an efficient way of transporting voice over IP over wireless, the main focus of ROHC has so far been on compression of IP/UDP/RTP headers, which are generous in size, especially compared to the payloads often carried by packets with such headers. ROHC RTP has become a very efficient, robust and capable compression scheme, able to compress the headers down to a total size of one octet only. Also, transparency is guaranteed to an extremely great extent even when residual bit errors are present in compressed headers delivered to the decompressor. The requirements for RTP compression [RTP-REQ], defined by the WG before and during the development process, have thus been fulfilled. As mentioned above, the 3rd generation cellular systems, where IP will be used end-to-end, have been one of the driving forces behind ROHC RTP, and the scheme has been designed to also suit new cellular air interfaces, such as WCDMA, making it possible to run even speech services with spectrum efficiency insignificantly lower than for existing one-service circuit switched solutions [VTC2000]. However, other air interfaces such as those based on GSM and IS-95 will also be used in all-IP networks, with further implications for the header compression issue. These older air interfaces are less flexible, with radio bearers optimized for specific payload sizes. This means that not even a single octet of header can be added without using the next higher fixed packet size supported by the link, something which is obviously very costly. For the already deployed speech vocoders, the spectrum efficiency over these links will thus be low compared to existing circuit switched solutions. To achieve high spectrum efficiency overall with any application, more flexible air interfaces must be deployed, and then the ROHC RTP scheme will perform excellently, as shown for WCDMA [MOMUC01]. However, for deployment reasons, it is however important to also provide a suitable header compression strategy for already existing vocoders and air interfaces, such as for GERAN and for CDMA2000, with minimal effects on spectral efficiency. This document defines a new link-layer assisted ROHC RTP profile extending ROHC RTP (profile 0x0001) [ROHC], compliant with the ROHC 0-byte requirements [0B-REQ]. The purpose of this new profile is to provide a header-free packet format that, for a certain application
behavior, can replace a majority of the 1-octet header ROHC RTP packets during normal U/O-mode operation, while still being fully transparent and complying with all the requirements of ROHC RTP [RTP-REQ]. For other applications, compression will be carried out as with normal ROHC RTP. To completely eliminate the compressed header, all functionality normally provided by the 1-octet header has to be provided by other means, typically by utilizing functionality provided by the lower layers and sacrificing efficiency for less frequently occurring larger compressed headers. The latter is not a contradiction since the argument for eliminating the last octet for most packets is not overall efficiency in general. It is important to remember that the purpose of this profile is to provide efficient matching of existing applications to existing link technologies, not efficiency in general. The additional complexity introduced by this profile, although minimized by a tight integration with already existing ROHC functionality, implies that it should therefore only be used to optimize performance of specific applications over specific links. When implementing this profile over various link technologies, care must be taken to guarantee that all the functionality needed is provided by ROHC and the lower layers together. Therefore, additional documents should specify how to incorporate this profile on top of various link technologies. RFC 2119. CCP Context Check Packet CRC Cyclic Redundancy Check CSP Context Synchronization Packet LLA Link Layer Assisted ROHC RTP profile NHP No Header Packet ROHC RObust Header Compression RHP ROHC Header Packet (a non-NHP packet, i.e., RRP, CSP or CCP) RRP ROHC RTP Packet as defined in [ROHC, profile 0x0001] Assisting layer "Assisting layer" refers to any entity implementing the interface to ROHC (section 4.2). It may, for example, refer to a sub-layer used to adapt the ROHC implementation and the physical link layer. This layer is assumed to have knowledge of the physical layer synchronization.
Compressing side "Compressing side" refers to the combination of the header compressor, operating with the LLA profile, and its associated assisting layer. Lower layers "Lower layers" in this document refers to entities located below ROHC in the protocol stack, including the assisting layer. ROHC RTP "ROHC RTP" in this document refers to the IP/UDP/RTP profile (profile 0x0001) as defined in [ROHC]. ROHC], it is possible to infer the information needed to maintain robust and transparent header compression even though the headers are completely eliminated during most of the operation time. Basically, what this profile does is to replace the smallest and most frequent ROHC U/O-mode headers with a no-header format, for which the header functionality must be provided by other means.
Smallest header in Smallest header in ROHC RTP (profile #1) LLA (profile #5) +--+--+--+--+--+--+--+--+ ++ | 1 octet | -----> || No Header +--+--+--+--+--+--+--+--+ ++ | | Header field functionality +-------------------> provided by other means The fields present in the ROHC RTP headers for U/O-mode PT0 are the packet type identifier, the sequence number and the CRC. The subsequent sections elaborate more on how the functionality of these fields is replaced for NHP. ROHC]) and at the receiving side it MUST provide an indication for each packet loss over the link. This is basically the same principle as the VJ header compression [VJHC] relies on. Note that guaranteeing in-order delivery and packet loss indication over the link not only makes it possible to infer the sequence number information, but also supersedes the main function of the CRC, which normally takes care of errors due to long link losses and bit errors in the compressed sequence number.
The LLA profile is obviously not applicable if the UDP checksum (2 bytes) is enabled, which is always the case for IPv6/UDP. For IPv4/UDP, the sender may choose to disable the UDP checksum. ROHC]. The following sections describe these packet types and their purpose in detail.
This case can be handled with the Context Synchronization Packet (CSP), which has the following format: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 0 1 0 | Packet type identifier +===+===+===+===+===+===+===+===+ : ROHC header without padding : : see [ROHC, section 5.7] : +---+---+---+---+---+---+---+---+ Updating properties: CSP maintains the updating properties of the ROHC header it carries. The CSP is defined by one of the unused packet type identifiers from ROHC RTP, carried in the one-octet base header. As for any ROHC packet, except the NHP, the packet may begin with ROHC padding and/or feedback. It may also carry context identification after the packet type identifier. It is possible to have two CID fields present, one after the packet type ID and one within the encapsulated ROHC header. If a decompressor receives a CSP with two non-equal CID values included, the packet MUST be discarded. ROHC segmentation may also be applied to the CSP. Note that when the decompressor has received and processed a CSP, the packet (including any possible data following the CSP encapsulated compressed header) MUST be discarded.
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 0 1 1 | Packet type identifier +===+===+===+===+===+===+===+===+ | C | CRC | +---+---+---+---+---+---+---+---+ C: C = 0 indicates that the CRC field is not used; C = 1 indicates that a valid CRC is present. Updating properties: CCP packets do not update context. The CCP is defined by one of the unused packet type identifiers from ROHC RTP, carried in the first octet of the base header. The first bit of the second octet, the C bit, indicates whether the CRC field is used or not. If C=1, the CRC field MUST be set to the 7-bits CRC calculated over the original uncompressed header defined in [ROHC section 5.9.2]. As for any ROHC packet, except NHP, the packet MAY begin with ROHC padding and/or carry context identification. The use of the CRC field to perform decompressor context verification is optional and is therefore a compressor implementation issue. However, a CCP MUST always be made available to the assisting layer. If the assisting layer receives CCPs with the C-bit set (C=1) from the compressor, it MUST use the last CCP received if a CCP is to be sent, i.e., the CCP corresponding to the last non-CCP packet sent (NHP, RRP or CSP). An assisting layer MAY use the CCP for other purposes, such as signaling a packet loss before the link. The decompressor is REQUIRED to handle a CCP received with the C bit set (C=1), indicating a valid CRC field, and perform context verification. The received CRC MUST then be applied to the last decompressed packet, unless a packet loss indication was previously received. Upon CRC failure, actions MUST be taken as specified in [ROHC, section 22.214.171.124.3]. A CCP received with C=0 MUST be ignored by the decompressor. The decompressor is not allowed to make any further interpretation of the CCP. The use of CCP by an assisting layer is optional and depends on the characteristics of the actual link. Whether it is used or not MUST therefore be specified in link layer implementation specifications for this profile.
figure above shows the various levels, as defined in [ROHC] and this document, constituting a complete implementation of the LLA profile. The figure also underlines the need for additional documents to specify how to implement these interfaces for a link technology for which this profile is relevant. This section defines the information to be exchanged between the LLA compressor and the assisting layer for this profile to operate properly. While it does define semantics, it does not specify how these interfaces are to be implemented.
This corresponds to the case when the compressor allows sending of an NHP packet, with or without segmentation being applied to the corresponding RRP/CSP packets. Recall that delivery of an NHP packet occurs when the ROHC RTP compressor would have used a ROHC UO-0. b. RRP, CSP, CCP and RTP Sequence Number are delivered, along with the corresponding segmentation flags set accordingly. This corresponds to the case when the compressor does not allow sending of an NHP packet. Segmentation might be applied to the corresponding RRP and CSP packets. Segmentation may be applied independently to an RRP or a CSP packet if its size exceeds the largest value provided in the PREFERRED PACKET_SIZES list and if the LARGE_PACKET_ALLOWED parameter is set to false. The segmentation flags are explicitly stated in the interface definition to emphasize that the RRP and the CSP may be delivered by the compressor as segmented packets. The RTP SN MUST be delivered for each packet by the compressor to allow the assisting layer to maintain the necessary sequencing information.
extended to indicate that the payload has been discarded when assembling the IR packet. All other fields keep their meanings as defined for ROHC RTP. The resulting structure, using small CIDs and CID=0, becomes: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 1 | 1 | 1 | 1 | 1 | 0 | D | +---+---+---+---+---+---+---+---+ | Profile | 1 octet +---+---+---+---+---+---+---+---+ | CRC | 1 octet +---+---+---+---+---+---+---+---+ | Static | variable length | chain | - - - - - - - - - - - - - - - - | Dynamic | not present if D = 0 | chain | present if D = 1, variable length - - - - - - - - - - - - - - - - | Payload | not present if D = 0 | | present if D = 1, variable length - - - - - - - - - - - - - - - - D: D = 0 indicates that the dynamic chain is not present and the payload has been discarded. After an IR packet with D=0 has been processed by the decompressor, the packet MUST be discarded.
VJHC, IPHC, CRTP], which do not make use of a header compression CRC. However, since ROHC RTP normally is extremely safe to use from a transparency point of view, it would be desirable to be able to achieve this with LLA also. To provide an additional guarantee for transparency and also catch unexpected errors, such as errors due to faulty implementations, it is RECOMMENDED to periodically send context updating packets, even when the compressor logic allows NHP packets to be used. ROHC, section 6.3], implementations use parameters to set up configuration information and to stipulate how a ROHC implementation is to operate. The following parameters are additions, useful to LLA, to the parameter set defined for ROHC RTP implementations. Note that if the PREFERRED_PACKET_SIZES parameters defined here are used, they obsolete all PACKET_SIZE and PAYLOAD_SIZE parameters of ROHC RTP.
LARGE_PACKETS_ALLOWED -- value: boolean This parameter may be set by an external entity to specify how to handle packets that do not fit any of the preferred packet sizes specified. If it is set to TRUE, the compressor MUST deliver the larger packet as-is and MUST NOT use segmentation. If it is set to FALSE, the ROHC segmentation scheme MUST be used to split the packet into two or more segments, and each segment MUST further be padded to fit one of the preferred packet sizes. By default, this parameter is set to TRUE, which means that segmentation is disabled. VERIFICATION_PERIOD -- value: integer This parameter may be set by an external entity to specify to the compressor the minimum frequency with which a packet validating the context must be sent. This tells the compressor that a packet containing a CRC field MUST be sent at least once every N packets, where N=VERIFICATION_PERIOD (see section 4.6). By default, this parameter is set to 0, which indicates that periodical verifications are disabled.
signal to indicate to the decompressor that a packet was lost before the compressor, or that a packet was discarded by the transmitting assisting layer.
[ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RTP] Schulzrinne, H., Casner S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [TCP] Postel, P., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RTP-REQ] Degermark, M., "Requirements for IP/UDP/RTP Header Compression", RFC 3096, July 2001. [0B-REQ] Jonsson, L-E., "RObust Header Compression (ROHC): Requirements and Assumptions for 0-byte IP/UDP/RTP Compression", RFC 3243, April 2002. [VJHC] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990. [IPHC] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999. [CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. [CRTPC] Degermark, M., Hannu, H., Jonsson, L-E. and K. Svanbro, "Evaluation of CRTP Performance over Cellular Radio Networks", IEEE Personal Communications Magazine, Volume 7, number 4, pp. 20-25, August 2000.
[VTC2000] Svanbro, K., Hannu, H., Jonsson, L-E. and M. Degermark, "Wireless real time IP-services enabled by header compression", proceedings of IEEE VTC2000, May 2000. [MOMUC01] Liu, G., et al., "Experimental field trials results of Voice-over IP over WCDMA links", MoMuC'01 - The International Workshop on Mobile Multimedia Communications, Conference proceedings, February 2001.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.