diff options
Diffstat (limited to 'doc/rfc/rfc3242.txt')
| -rw-r--r-- | doc/rfc/rfc3242.txt | 1179 |
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc3242.txt b/doc/rfc/rfc3242.txt new file mode 100644 index 0000000..408337e --- /dev/null +++ b/doc/rfc/rfc3242.txt @@ -0,0 +1,1179 @@ + + + + + + +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. + +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 making use of this header-free packet. + +Table of Contents + + 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 + + + +Jonsson, et. al Standards Track [Page 1] + +RFC 3242 A Link-Layer Assisted ROHC RTP April 2002 + + + 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 + +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 + 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 + + + +Jonsson, et. al Standards Track [Page 2] + +RFC 3242 A Link-Layer Assisted ROHC RTP April 2002 + + + 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 + + + +Jonsson, et. al Standards Track [Page 3] + +RFC 3242 A Link-Layer Assisted ROHC RTP April 2002 + + + 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. + +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. + + 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 4] + +RFC 3242 A Link-Layer Assisted ROHC RTP April 2002 + + + 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]. + +3. Overview of the Link-Layer Assisted Profile + + The ROHC IP/UDP/RTP profile defined in this document, profile 0x0005 + (hex), is designed to be used over channels that have been optimized + for specific payload sizes and 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, 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. + + + + + + + +Jonsson, et. al Standards Track [Page 5] + +RFC 3242 A Link-Layer Assisted ROHC RTP April 2002 + + + 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. ROHC RTP packets with compressed headers will be + possible to distinguish 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, if needed the compressing + side 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 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. + + + + +Jonsson, et. al Standards Track [Page 6] + +RFC 3242 A Link-Layer Assisted ROHC RTP April 2002 + + +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 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. + Whether LLA or ROHC RTP should be implemented thus depends on the + characteristics of the link itself. For most RTP packet streams, LLA + will work exactly as ROHC RTP, while it will be more efficient for + packet streams with certain characteristics. LLA will never be less + efficient 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 7] + +RFC 3242 A Link-Layer Assisted ROHC RTP April 2002 + + + 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), i.e., a packet consisting only of a + payload, is defined and MAY be used when only sequencing must be + conveyed, i.e., 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 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 data being discarded, which may result in decompressor + context invalidation. It might therefore be beneficial to send a + packet with only the header information and 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 8] + +RFC 3242 A Link-Layer Assisted ROHC RTP April 2002 + + + 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. + +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: + + + + + + + + + + + +Jonsson, et. al Standards Track [Page 9] + +RFC 3242 A Link-Layer Assisted ROHC RTP April 2002 + + + 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 5.3.2.2.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. + + + + + + + + +Jonsson, et. al Standards Track [Page 10] + +RFC 3242 A Link-Layer Assisted ROHC RTP April 2002 + + +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 + 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. + + + +Jonsson, et. al Standards Track [Page 11] + +RFC 3242 A Link-Layer Assisted ROHC RTP April 2002 + + + 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. + +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 + 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 whether the packet + received is an NHP or not + + Note that the context is updated from a packet loss indication. + + + + + + + + +Jonsson, et. al Standards Track [Page 12] + +RFC 3242 A Link-Layer Assisted ROHC RTP April 2002 + + +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 in case of three or more consecutive physical packet + losses. 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 between the compressing side and the decompressing + side. It could be handled with a fixed principle, 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 + + + + + +Jonsson, et. al Standards Track [Page 13] + +RFC 3242 A Link-Layer Assisted ROHC RTP April 2002 + + + 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. + +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 NHP 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. + + + + + + + +Jonsson, et. al Standards Track [Page 14] + +RFC 3242 A Link-Layer Assisted ROHC RTP April 2002 + + +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 to periodically send context updating packets, 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. + +5. Implementation Issues + + This document specifies mechanisms for the protocol and leaves + details on the use of these mechanisms to the implementers. The + present chapter 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. + + + + + + +Jonsson, et. al Standards Track [Page 15] + +RFC 3242 A Link-Layer Assisted ROHC RTP April 2002 + + +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 a minimum of + one octet ROHC padding. + + 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 + 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. + + + +Jonsson, et. al Standards Track [Page 16] + +RFC 3242 A Link-Layer Assisted ROHC RTP April 2002 + + + 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. + +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 + + + + +Jonsson, et. al Standards Track [Page 17] + +RFC 3242 A Link-Layer Assisted ROHC RTP April 2002 + + + 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]. + +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 + onto the link using random CRC values, 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. + + + + + +Jonsson, et. al Standards Track [Page 18] + +RFC 3242 A Link-Layer Assisted ROHC RTP April 2002 + + +9. References + + [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. + + + + + +Jonsson, et. al Standards Track [Page 19] + +RFC 3242 A Link-Layer Assisted ROHC RTP April 2002 + + + [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. + +10. Authors' Addresses + + Lars-Erik Jonsson + Ericsson AB + Box 920 + SE-971 28 Lulea + Sweden + + Phone: +46 920 20 21 07 + Fax: +46 920 20 20 99 + EMail: lars-erik.jonsson@ericsson.com + + + Ghyslain Pelletier + Ericsson AB + Box 920 + SE-971 28 Lulea + Sweden + + Phone: +46 920 20 24 32 + Fax: +46 920 20 20 99 + EMail: ghyslain.pelletier@epl.ericsson.se + + + + + + + + + + + + + + + + + + + + +Jonsson, et. al Standards Track [Page 20] + +RFC 3242 A Link-Layer Assisted ROHC RTP April 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Jonsson, et. al Standards Track [Page 21] + |