From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4362.txt | 1291 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1291 insertions(+) create mode 100644 doc/rfc/rfc4362.txt (limited to 'doc/rfc/rfc4362.txt') diff --git a/doc/rfc/rfc4362.txt b/doc/rfc/rfc4362.txt new file mode 100644 index 0000000..0b0cc70 --- /dev/null +++ b/doc/rfc/rfc4362.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group L-E. Jonsson +Request for Comments: 4362 G. Pelletier +Obsoletes: 3242 K. Sandlund +Category: Standards Track Ericsson + January 2006 + + 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 (2006). + +Abstract + + This 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 related to the usage of the header-free packet format. + This document is a replacement for RFC 3242, which it obsoletes. + + + + + + + + + + + + + + + + + +Jonsson, et al. Standards Track [Page 1] + +RFC 4362 A Link-Layer Assisted ROHC RTP January 2006 + + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Differences from RFC 3242 ..................................5 + 2. Terminology .....................................................5 + 3. Overview of the Link-Layer Assisted Profile .....................6 + 3.1. Providing Packet Type Identification .......................7 + 3.2. Replacing the Sequence Number ..............................7 + 3.3. CRC Replacement ............................................8 + 3.4. Applicability of This Profile ..............................8 + 4. Additions and Exceptions Compared to ROHC RTP ...................9 + 4.1. Additional Packet Types ....................................9 + 4.1.1. No-Header Packet (NHP) ..............................9 + 4.1.2. Context Synchronization Packet (CSP) ................9 + 4.1.3. Context Check Packet (CCP) .........................11 + 4.2. Interfaces Towards the Assisting Layer ....................12 + 4.2.1. Interface, Compressor to Assisting Layer ...........13 + 4.2.2. Interface, Assisting Layer to Decompressor .........13 + 4.3. Optimistic Approach Agreement .............................14 + 4.4. Fast Context Initialization, IR Redefinition ..............15 + 4.5. Feedback Option, CV-REQUEST ...............................16 + 4.6. Periodic Context Verification .............................16 + 4.7. Use of Context Identifier .................................16 + 5. Implementation Issues ..........................................17 + 5.1. Implementation Parameters and Signals .....................17 + 5.1.1. Implementation Parameters at the Compressor ........17 + 5.1.2. Implementation Parameters at the Decompressor ......19 + 5.2. Implementation over Various Link Technologies .............19 + 6. IANA Considerations ............................................20 + 7. Security Considerations ........................................20 + 8. Acknowledgements ...............................................20 + 9. References .....................................................20 + 9.1. Normative References ......................................20 + 9.2. Informative References ....................................21 + +1. Introduction + + Header compression is a technique used to compress and transparently + decompress the header information of a packet on a per-hop basis, + utilizing redundancy within individual packets and between + consecutive packets within a packet stream. Over the years, several + protocols [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 + + + + +Jonsson, et al. Standards Track [Page 2] + +RFC 4362 A Link-Layer Assisted ROHC RTP January 2006 + + + improve compression efficiency further for real-time traffic using + the Real-Time Transport Protocol [RTP]. + + The schemes mentioned above have all been designed by 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 when 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 also been designed to 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 + + + +Jonsson, et al. Standards Track [Page 3] + +RFC 4362 A Link-Layer Assisted ROHC RTP January 2006 + + + next higher fixed packet size supported by the link, something that + 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 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 describes a link-layer-assisted ROHC RTP profile, + originally defined by [LLA], extending ROHC RTP (profile 0x0001) + [ROHC], and compliant with the ROHC 0-byte requirements [0B-REQ]. + The purpose of this 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. + + The profile defined by this document was originally specified by RFC + 3242 [LLA], but to address one technical flaw and clarify one + implementation issue, this document has been issued to replace RFC + 3242, which becomes obsolete. + + + + + +Jonsson, et al. Standards Track [Page 4] + +RFC 4362 A Link-Layer Assisted ROHC RTP January 2006 + + +1.1. Differences from RFC 3242 + + This section briefly summarizes the differences of this document from + RFC 3242. Acronyms and terminology can be found in Section 2. + + The format of the CSP packet, as defined in [LLA], was identified as + non-interoperable when carrying a RHP header with a 3-bit or 7-bit + CRC. This problem occurs because the payload has been dropped by the + compressor, and the decompressor is supposed to use the payload + length to infer certain fields in the uncompressed header. These + fields are the IPv4 total length, the IPv6 payload length, the UDP + length, and the IPv4 header checksum field (all INFERRED fields in + [ROHC]). To correct this flaw, the CSP packet must carry information + about the payload length of the RHP packet. Therefore, the length of + the RTP payload has been included in the CSP packet. + + This document also clarifies an unclear referencing in RFC 3242, + where Section 4.1.3 of [LLA] states that upon CRC failure, the + actions of [ROHC], Section 5.3.2.2.3 MUST be taken. That section + specifies that detection of SN wraparound and local repair must be + performed, but neither of these steps apply when the failing packet + is a CCP. Therefore, upon CRC failure, actions to be taken are the + ones specified in Section 5.3.2.2.3, but steps a-d only. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + 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. + + + + + +Jonsson, et al. Standards Track [Page 5] + +RFC 4362 A Link-Layer Assisted ROHC RTP January 2006 + + + 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" refers to the IP/UDP/RTP profile as defined in [ROHC]. + +3. Overview of the Link-Layer Assisted Profile + + The ROHC IP/UDP/RTP profile defined in [LLA] and updated by this + document, profile 0x0005 (hex), is designed to be used over channels + that have been optimized for specific payload sizes and that + therefore cannot efficiently accommodate header information when + transmitted together with payloads corresponding to these optimal + sizes. + + The LLA profile extends, and thus also inherits all functionality + from, the ROCH RTP profile by defining some additional functionality + and an interface from the ROHC component towards an assisting lower + layer. + + +---------------------------------------+ + | | + The LLA | ROHC RTP, | + profile | Profile #1 +-----------------+ + | | LLA Additions | + +---------------------+-----------------+ + + By imposing additional requirements on the lower layers compared to + [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, this profile replaces 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. + + + + + + + +Jonsson, et al. Standards Track [Page 6] + +RFC 4362 A Link-Layer Assisted ROHC RTP January 2006 + + + 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. + +3.1. Providing Packet Type Identification + + All ROHC headers carry a packet type identifier, indicating to the + decompressor how the header should be interpreted. This is a + function that must be provided by some means in 0-byte header + compression. It will be possible to distinguish ROHC RTP packets + with compressed headers thanks to the packet type identifier, but a + mechanism is needed to separate packets with a header from packets + without a header. This function MUST therefore be provided by the + assisting layer in one way or another. + +3.2. Replacing the Sequence Number + + From the sending application, the RTP sequence number is increased by + one for each packet sent. The purpose of the sequence number is to + cope with packet reordering and packet loss. If reordering or loss + has occurred before the transmission point, the compressing side, if + needed, can easily avoid problems by not allowing the use of a + header-free packet. + + However, at the transmission point, loss or reordering that may occur + over the link can not be anticipated and covered for. Therefore, for + NHP, the assisting layer MUST guarantee in-order delivery over the + link (already assumed by [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 that which 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 link losses and bit errors in + the compressed sequence number. + + + + +Jonsson, et al. Standards Track [Page 7] + +RFC 4362 A Link-Layer Assisted ROHC RTP January 2006 + + +3.3. CRC Replacement + + All context-updating RRP packets carry a CRC calculated over the + uncompressed header. The CRC is used by the decompressor to verify + that the updated context is correct. This verification serves three + purposes in U/O-mode: + + 1) Detection of longer losses than can be covered by the sequence + number LSBs. + + 2) Protection against failures caused by residual bit errors in + compressed headers. + + 3) Protection against faulty implementations and other causes of + error. + + Since this profile defines an NHP packet without this CRC, care must + be taken to fulfill these purposes by other means when an NHP is used + as a replacement for a context-updating packet. Detection of long + losses (1) is already covered, since the assisting layer MUST provide + an indication of all packet losses. Furthermore, the NHP packet has + one important advantage over RHP packets in that residual bit errors + (2) cannot damage a header that is not even sent. + + It is thus reasonable to assume that compression and decompression + transparency can be assured with high confidence, even without a CRC + in header-free packets. However, to provide additional protection + against damage propagation due to undetected residual bit errors in + context-updating packets (2) or other unexpected errors (3), periodic + context verifications SHOULD be performed (see Section 4.6). + +3.4. Applicability of This Profile + + The LLA profile can be used with any link technology capable of + providing the required functionality described in previous sections. + Thus, whether LLA or ROHC RTP should be implemented depends on the + characteristics of the link itself. For most RTP packet streams, LLA + will work exactly as ROHC RTP, and it will have a higher compression + efficiency for packet streams with certain characteristics. LLA will + never have a lower compression efficiency than ROHC RTP. + + Note as well that LLA, like all other ROHC profiles, is fully + transparent to any packet stream reaching the compressor. LLA does + not make any assumptions about the packet stream but will perform + optimally for packet streams with certain characteristics, e.g., + synchronized streams exactly timed with the assisting link over which + the LLA profile is implemented. + + + + +Jonsson, et al. Standards Track [Page 8] + +RFC 4362 A Link-Layer Assisted ROHC RTP January 2006 + + + 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. + +4. Additions and Exceptions Compared to ROHC RTP + +4.1. Additional Packet Types + + The LLA profile defines three new packet types to be used in addition + to the RRP packet types defined by [ROHC]. The following sections + describe these packet types and their purpose in detail. + +4.1.1. No-Header Packet (NHP) + + A No-Header Packet (NHP) is a packet that consists only of the + payload of the original packet. The NHP MAY be used when only the + sequence information needs to be conveyed to the decompressor. In + other words, the NHP can be used when all header fields are either + unchanged or follow the currently established change pattern. In + addition, there are some considerations for the use of the NHP (see + sections 4.3, 4.5, and 4.6). An LLA compressor is not allowed to + deliver NHP packets when operating in R-mode. + + The assisting layer MAY send the NHP for RTP SN = X only if an NHP + was delivered by the LLA compressor AND the assisting layer can + guarantee that the decompressor will infer the proper sequencing for + this NHP. This guarantee is based on the confidence that the + decompressor + + a) has the means to infer proper sequencing for the packet + corresponding to SN = X-1, AND + + b) has either received a loss indication or the packet itself for + the packet corresponding to SN = X-1. + + Updating properties: NHP packets update context (RTP Sequence + Number). + +4.1.2. Context Synchronization Packet (CSP) + + The case where the packet stream overruns the channel bandwidth may + lead to discarded data, which may result in decompressor context + invalidation. It might therefore be beneficial to send a packet with + only the header information and to discard the payload. This would + be helpful to maintain synchronization of the decompressor context + while efficiently using the available bandwidth. + + + + + +Jonsson, et al. Standards Track [Page 9] + +RFC 4362 A Link-Layer Assisted ROHC RTP January 2006 + + + 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 + +===+===+===+===+===+===+===+===+ + / RTP Payload Length / 2 octets + +---+---+---+---+---+---+---+---+ + : ROHC header without padding : + : see [ROHC, Section 5.7] : + +---+---+---+---+---+---+---+---+ + + RTP Payload Length: This field is the length of the payload carried + inside the RTP header, stored in network byte + order. That is, this field will be set by the + compressor to (UDP length - size of the UDP + header - size of the RTP header including CSRC + identifiers). + + 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. + + In the CSP packet, the payload has been dropped by the compressor. + However, the decompressor is supposed to use the payload length to + infer certain fields in the uncompressed header (the IPv4 total + length, the IPv6 payload length, the UDP length, and the IPv4 header + checksum field). When dropping the payload, the CSP packet needs to + contain information about the payload length carried in the RHP + packet. Therefore, the length of the RTP payload is carried in the + CSP packet. When the decompressor receives a CSP packet, it can use + the RTP payload length field to calculate the value of fields + classified as INFERRED in [ROHC] when attempting to verify a 3- or + 7-bit CRC carried in the RHP header enclosed in 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. + + + +Jonsson, et al. Standards Track [Page 10] + +RFC 4362 A Link-Layer Assisted ROHC RTP January 2006 + + +4.1.3. Context Check Packet (CCP) + + A Context Check Packet (CCP), which does not carry any payload but + only an optional CRC value in addition to the packet type identifier, + is defined. + + The purpose of the CCP is to provide a useful packet that MAY be sent + by a synchronized physical link layer in the case where data must be + sent at fixed intervals, even if no compressed packet is available. + Whether the CCP is sent over the link and delivered to the + decompressor is decided by the assisting layer. The CCP has the + following format: + + 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. If C=1, the CRC field MUST be set to the 7-bit 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 to 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 + + + +Jonsson, et al. Standards Track [Page 11] + +RFC 4362 A Link-Layer Assisted ROHC RTP January 2006 + + + [ROHC, Section 5.3.2.2.3, steps a-d only]. 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. + + When using the 7-bit CRC in the CCP packet to verify the context, the + decompressor needs to have access to the entire uncompressed header + of the latest packet decompressed. Some implementations of [ROHC] + might not save the values of INFERRED fields. An implementation of + ROHC LLA MUST save these fields in the decompressor context to be + able to successfully verify CCP packets. + + The use of CCP by an assisting layer is optional and depends on the + characteristics of the actual link. Whether it is used MUST + therefore be specified in link-layer implementation specifications + for this profile. + +4.2. Interfaces Towards the Assisting Layer + + This profile relies on the lower layers to provide the necessary + functionality to allow NHP packets to be sent. This interaction + between LLA and the assisting layer is defined as interfaces between + the LLA compressor/decompressor and the LLA applicable link + technology. + + | | + + + + +-------------------------+ +-------------------------+ + | ROHC RTP HC | | ROHC RTP HD | + +-------------------------+ +-------------------------+ + | LLA profile | | LLA profile | + +=========================+ +=========================+ + | Interface | | Interface | + | ROHC to assisting layer | | Assisting layer to ROHC | + +=========================+ +=========================+ + | Applicable | | Applicable | + | link technology | | link technology | + +=========================+ +=========================+ + | | + +------>---- CHANNEL ---->-----+ + + The 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 + + + +Jonsson, et al. Standards Track [Page 12] + +RFC 4362 A Link-Layer Assisted ROHC RTP January 2006 + + + properly. While it does define semantics, it does not specify how + these interfaces are to be implemented. + +4.2.1. Interface, Compressor to Assisting Layer + + This section defines the interface semantics between the compressor + and the assisting layer, providing rules for packet delivery from the + compressor. + + The interface defines the following parameters: RRP, RRP segmentation + flag, CSP, CSP segmentation flag, NHP, and RTP Sequence Number. All + parameters, except the NHP, MUST always be delivered to the assisting + layer. This leads to two possible delivery scenarios: + + a. RRP, CSP, CCP, NHP, and RTP Sequence Number are delivered, + along with the corresponding segmentation flags, set + accordingly. + + This corresponds to the case when the compressor allows sending + of an NHP packet, with or without segmentation 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. + +4.2.2. Interface, Assisting Layer to Decompressor + + Here the interface semantics between the assisting layer and the + decompressor are defined, providing simple rules for the delivery of + received packets to the decompressor. The decompressor needs a way + + + +Jonsson, et al. Standards Track [Page 13] + +RFC 4362 A Link-Layer Assisted ROHC RTP January 2006 + + + to distinguish NHP packets from RHP packets. Also, when receiving + packets without a header, the decompressor needs a way to infer the + sequencing information to keep synchronization between the received + payload and the sequence information of the decompressed headers. To + achieve this, the decompressor MUST receive the following from the + assisting layer: + + - an indication for each packet loss over the link between the + compressing and decompressing sides for CID=0. + + - the received packet together with an indication of whether the + packet received is an NHP. + + Note that the context is updated from a packet loss indication. + +4.3. Optimistic Approach Agreement + + ROHC defines an optimistic approach for updates to reduce the header + overhead. This approach is fully exploited in the Optimistic and + Unidirectional modes of operation. Due to the presence of a CRC in + all compressed headers, the optimistic approach is defined as a + compressor issue only because the decompressor will always be able to + detect an invalid context through the CRC verification. + + However, no CRC is present in the NHP packet defined by the LLA + profile. Therefore, the loss of an RHP packet updating the context + may not always be detected. To avoid this problem, the compressing + and decompressing sides must agree on the principles for the + optimistic approach, and the agreed principles MUST be enforced not + only by the compressor but also by the transmitting assisting layer. + If, for example, three consecutive updates are sent to convey a + header field change, the decompressor must know this and invalidate + the context if three or more consecutive physical packets are lost. + Note that the mechanism used to enforce the optimistic approach must + be reinitialized if a new field change needs to be conveyed while the + compressing side is already sending packets to convey non-linear + context updates. + + An LLA decompressor MUST use the optimistic approach knowledge to + detect possible context loss events. If context loss is suspected, + it MUST invalidate the context and not forward any packets before the + context has been synchronized. + + It is REQUIRED that all documents describing how the LLA profile is + implemented over a certain link technology define how the optimistic + approach is agreed to between the compressing side and the + decompressing side. It could be handled with a fixed principle, with + + + + +Jonsson, et al. Standards Track [Page 14] + +RFC 4362 A Link-Layer Assisted ROHC RTP January 2006 + + + negotiation at startup, or by other means, but the method must be + unambiguously defined. + +4.4. Fast Context Initialization, IR Redefinition + + As initial IR packets might overrun the channel bandwidth and + significantly delay decompressor context establishment, it might be + beneficial to initially discard the payload. This allows state + transitions and higher compression efficiency to be achieved with + minimal delay. + + To serve this purpose, the D-bit from the basic structure of the ROHC + RTP IR packet [ROHC, Section 5.7.7.1] is redefined for the LLA + profile. For D=0 (no dynamic chain), the meaning of the D-bit is + 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 that the payload has been discarded. + + After an IR packet with D=0 has been processed by the decompressor, + the packet MUST be discarded. + + + + + + + + +Jonsson, et al. Standards Track [Page 15] + +RFC 4362 A Link-Layer Assisted ROHC RTP January 2006 + + +4.5. Feedback Option, CV-REQUEST + + The CV-REQUEST option MAY be used by the decompressor to request an + RRP or CSP for context verification. This option should be used if + only NHPs have been received for a long time and the context + therefore has not been verified recently. + + +---+---+---+---+---+---+---+---+ + | Opt Type = 8 | Opt Len = 0 | + +---+---+---+---+---+---+---+---+ + + If the compressor receives a feedback packet with this option, the + next packet compressed SHOULD NOT be delivered to the assisting layer + as an NHP. + +4.6. Periodic Context Verification + + As described in Section 3.3, transparency is expected to be + guaranteed by the functionality provided by the lower layers. This + ROHC profile would therefore be at least as reliable as the older + header compression schemes [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 that context updating packets be sent periodically, + even when the compressor logic allows NHP packets to be used. + +4.7. Use of Context Identifier + + Since an NHP cannot carry a context identifier (CID), there is a + restriction on how this profile may be used, related to context + identification. Independent of which CID size has been negotiated, + NHP packets can only be used for CID=0. If the decompressor receives + an NHP packet, it can only belong to CID=0. + + Note that if multiple packet streams are handled by a compressor + operating using LLA, the assisting layer must, in case of physical + packet loss, be able to tell for which CID the loss occurred, or at + least it MUST be able to tell if packets with CID=0 (packet stream + with NHPs) have been lost. + + + + + + + + +Jonsson, et al. Standards Track [Page 16] + +RFC 4362 A Link-Layer Assisted ROHC RTP January 2006 + + +5. Implementation Issues + + This document specifies mechanisms for the protocol and leaves + details on the use of these mechanisms to the implementers. The + present section aims to provide guidelines, ideas, and suggestions + for implementation of LLA. + +5.1. Implementation Parameters and Signals + + As described in [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. + +5.1.1. Implementation Parameters at the Compressor + + ALWAYS_PAD -- value: boolean + + This parameter may be set by an external entity to specify to the + compressor that every RHP packet MUST be padded with ROHC padding + of one octet, minimum. + + The assisting layer MUST provide a packet type identification. If + no field is available for this purpose from the protocol at the + link layer, then a leading sequence may be used to distinguish RHP + packets from NHP packets. Although the use of a leading sequence + is obviously not efficient, since it sacrifices efficiency for RHP + packets, the efficiency loss should be insignificant because the + leading sequence applies only to packets with headers in order to + favor the use of packets without headers. If a leading sequence + is desired for RHP identification, the lower layer MAY use ROHC + padding for the leading sequence by setting the ALWAYS_PAD + parameter. Note that in such cases, possible collisions of the + padding with the NHP payload must be avoided. + + By default, this parameter is set to FALSE. + + PREFERRED_PACKET_SIZES -- list of: + SIZE -- value: integer (octets) + RESTRICTED_TYPE -- values: [NHP_ONLY, RHP_ONLY, NO_RESTRICTION] + + This parameter set governs which packet sizes are preferred by the + assisting layer. If this parameter set is used, all RHP packets + MUST be padded to fit the smallest possible preferred size. If + the size of the unpadded packet (or, in the case of ALWAYS_PAD + + + +Jonsson, et al. Standards Track [Page 17] + +RFC 4362 A Link-Layer Assisted ROHC RTP January 2006 + + + being set, the packet with minimal one-octet padding) is larger + than the maximal preferred packet size, the compressor has two + options. Either it may deliver this larger packet with an + arbitrary size, or it may split the packet into several segments + using ROHC segmentation and pad each segment to one of the + preferred sizes. Which method to use depends on the value of the + LARGE_PACKETS_ALLOWED parameter below. + + NHP packets can be delivered to the lower layer only if the + payload size is part of the preferred packet size set. + Furthermore, if RESTRICTED_TYPE is set to one of NHP_ONLY or + RHP_ONLY for any of the preferred packet sizes, that size is + allowed only for packets of the specified type. + + By default, no preferred packet sizes are specified. When sizes + are specified, the default value for RESTRICTED_TYPE is + NO_RESTRICTION. + + 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. + + + + + + + + + + +Jonsson, et al. Standards Track [Page 18] + +RFC 4362 A Link-Layer Assisted ROHC RTP January 2006 + + +5.1.2. Implementation Parameters at the Decompressor + + NHP_PACKET -- value: boolean + + This parameter informs the decompressor that the packet being + delivered is an NHP packet. The decompressor MUST accept this + packet type indicator from the lower layer. An assisting layer + MUST set this indicator to true for every NHP packet delivered, + and to false for any other packet. + + PHYSICAL_PACKET_LOSS -- signal + + This signal indicates to the decompressor that a packet has been + lost on the link between the compressing and the decompressing + sides, due to a physical link error. The signal is given once for + each packet that was lost, and a decompressor must increase the + sequence number accordingly when this signal is received. + + PRE_LINK_PACKET_LOSS -- signal + + This signal tells the decompressor to increase the sequence number + due to a gap in the sequencing not related to a physical link + error. A receiving assisting layer may, for example, use this + 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. + +5.2. Implementation over Various Link Technologies + + This document provides the semantics and requirements of the + interface needed from the ROHC compressor and decompressor towards + the assisting layer to perform link-layer-assisted header + compression. + + However, this document does not provide any link-layer-specific + operational information, except for some implementation suggestions. + Further details about how this profile is to be implemented over + various link technologies must be described in other documents, where + specific characteristics of each link layer can be taken into account + to provide optimal usage of this profile. + + These specifications MAY use a packet-type bit pattern unused by this + profile to implement signaling on the lower layer. The pattern + available to lower layer implementations is [11111001]. + + + + + + + +Jonsson, et al. Standards Track [Page 19] + +RFC 4362 A Link-Layer Assisted ROHC RTP January 2006 + + +6. IANA Considerations + + ROHC profile identifier 0x0005 has been reserved by the IANA for the + IP/UDP/RTP profile defined in this document. + +7. Security Considerations + + The security considerations of ROHC RTP [ROHC, Section 7] apply also + to this document, with one addition: in the case of a denial-of- + service attack scenario where an intruder injects bogus CCP packets + using random CRC values onto the link, the CRC check will fail for + incorrect reasons at the decompressor side. This would obviously + greatly reduce the advantages of ROHC and any extra efficiency + provided by this profile due to unnecessary context invalidation, + feedback messages, and refresh packets. However, the same remarks + related to the presence of such an intruder apply. + +8. Acknowledgements + + The authors would like to thank Lila Madour, Ulises Olvera-Hernandez, + and Francis Lupien for input regarding the typical links in which LLA + can be applied. Thanks also to Mikael Degermark for fruitful + discussions that led to improvements of this profile, and to Zhigang + Liu for many valuable comments. + +9. References + +9.1. Normative References + + [ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., + Hannu, H., Jonsson, L-E., 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", STD 64, RFC 3550, July 2003. + + + +Jonsson, et al. Standards Track [Page 20] + +RFC 4362 A Link-Layer Assisted ROHC RTP January 2006 + + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +9.2. Informative References + + [LLA] Jonsson, L-E. and G. Pelletier, "RObust Header Compression + (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC + 3242, April 2002. + + [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RTP-REQ] Degermark, M., "Requirements for robust 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. + + + + + + + + + + +Jonsson, et al. Standards Track [Page 21] + +RFC 4362 A Link-Layer Assisted ROHC RTP January 2006 + + +Authors' Addresses + + Lars-Erik Jonsson + Ericsson AB + Box 920 + SE-971 28 Lulea, Sweden + + Phone: +46 8 404 29 61 + Fax: +46 920 996 21 + EMail: lars-erik.jonsson@ericsson.com + + + Ghyslain Pelletier + Ericsson AB + Box 920 + SE-971 28 Lulea, Sweden + + Phone: +46 8 404 29 43 + Fax: +46 920 996 21 + EMail: ghyslain.pelletier@ericsson.com + + + Kristofer Sandlund + Ericsson AB + Box 920 + SE-971 28 Lulea, Sweden + + Phone: +46 8 404 41 58 + Fax: +46 920 996 21 + EMail: kristofer.sandlund@ericsson.com + + + + + + + + + + + + + + + + + + + + + +Jonsson, et al. Standards Track [Page 22] + +RFC 4362 A Link-Layer Assisted ROHC RTP January 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + 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. + + 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Jonsson, et al. Standards Track [Page 23] + -- cgit v1.2.3