diff options
Diffstat (limited to 'doc/rfc/rfc4224.txt')
| -rw-r--r-- | doc/rfc/rfc4224.txt | 1179 |
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc4224.txt b/doc/rfc/rfc4224.txt new file mode 100644 index 0000000..790d19b --- /dev/null +++ b/doc/rfc/rfc4224.txt @@ -0,0 +1,1179 @@ + + + + + + +Network Working Group G. Pelletier +Request for Comments: 4224 L-E. Jonsson +Category: Informational K. Sandlund + Ericsson + January 2006 + + + RObust Header Compression (ROHC): + ROHC over Channels That Can Reorder Packets + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + RObust Header Compression (ROHC), RFC 3095, defines a framework for + header compression, along with a number of compression protocols + (profiles). One operating assumption for the profiles defined in RFC + 3095 is that the channel between compressor and decompressor is + required to maintain packet ordering. This document discusses + aspects of using ROHC over channels that can reorder packets. It + provides guidelines on how to implement existing profiles over such + channels, as well as suggestions for the design of new profiles. + + + + + + + + + + + + + + + + + + + + + +Pelletier, et al. Informational [Page 1] + +RFC 4224 ROHC over Reordering Channels January 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Terminology .....................................................4 + 3. Applicability of This Document to ROHC Profiles .................5 + 3.1. Profiles within Scope ......................................5 + 3.2. Profiles with Special Considerations .......................5 + 3.3. Profiles Incompatible with Reordering ......................6 + 4. Background ......................................................6 + 4.1. Reordering Channels ........................................6 + 4.2. Robustness Principles of ROHC ..............................6 + 4.2.1. Optimistic Approach (U/O-mode) ......................7 + 4.2.2. Secure Reference Principle (R-mode) .................7 + 5. Problem Description .............................................7 + 5.1. ROHC and Reordering Channels ...............................7 + 5.1.1. LSB Interpretation Interval and Reordering ..........7 + 5.1.2. Reordering of Packets in R-mode .....................9 + 5.1.2.1. Updating Packets ...........................9 + 5.1.2.2. Non-Updating Packets ......................10 + 5.1.3. Reordering of Packets in U/O-mode ..................10 + 5.1.4. Reordering on the Feedback Channel .................11 + 5.1.5. List Compression ...................................11 + 5.1.6. Reordering and Mode Transitions ....................12 + 5.2. Consequences of Reordering ................................13 + 5.2.1. Functionality Incompatible with Reordering .........13 + 5.2.2. Context Damage (Loss of Synchronization) ...........13 + 5.2.3. Detected Decompression Failures (U/O/R-mode) .......13 + 5.2.4. Undetected Decompression Failures (R-mode only) ....14 + 6. Making ROHC Tolerant against Reordering ........................14 + 6.1. Properties of ROHC Implementations ........................14 + 6.1.1. Compressing Headers with Robustness against + Reordering .........................................14 + 6.1.1.1. Reordering and the Optimistic Approach ....15 + 6.1.1.2. Reordering and the Secure + Reference Principle .......................15 + 6.1.1.3. Robust Selection of Compressed Header .....15 + 6.1.2. Implementing a Reordering-Tolerant Decompressor ....16 + 6.1.2.1. Decompressor Feedback Considerations ......16 + 6.1.2.2. Considerations for Local Repair + Mechanisms ................................17 + 6.2. Specifying ROHC Profiles with Robustness against + Reordering ................................................17 + 6.2.1. Profiles with Interpretation Interval + Offset p = -1 ......................................17 + 6.2.2. Modifying the Interpretation Interval Offset .......18 + 6.2.2.1. Example Profile for Handling Reordering ...18 + 6.2.2.2. Defining the Values of p for New + Profiles ..................................18 + + + +Pelletier, et al. Informational [Page 2] + +RFC 4224 ROHC over Reordering Channels January 2006 + + + 7. Security Considerations ........................................19 + 8. Acknowledgements ...............................................19 + 9. Informative References .........................................19 + +1. Introduction + + RObust Header Compression (ROHC), RFC 3095 [1], defines a framework + for header compression, along with a number of compression protocols + (profiles). One operating assumption for the profiles defined in RFC + 3095 is that the channel between compressor and decompressor is + required to maintain packet ordering for each compressed flow. The + motivation behind this assumption was that the primary candidate + channels considered did guarantee in-order delivery of header- + compressed packets. This assumption made it possible to meet the + design objectives that were on top of the requirements list at the + time when ROHC was being designed, namely to improve the compression + efficiency and the tolerance to packet losses. + + Since the publication of RFC 3095 in 2001, the question about ROHC + operation over channels that do not guarantee in-order delivery has + surfaced several times; arguments that ROHC cannot perform adequately + over such channels have been heard. Specifically, this has been + raised as a weakness when compared to other header compression + alternatives, as RFC 3095 explicitly states its inability to operate + if in-order delivery is not guaranteed. For those familiar with the + details of ROHC and of other header compression schemes, it is clear + that this is a misconception, but it can also be easily understood + that the wording used in RFC 3095 can lead to such interpretation. + + This document discusses the various aspects of implementing ROHC over + channels that can reorder header-compressed packets. It explains + different ways of implementing the profiles found in RFC 3095, as + well as other profiles based on those profiles, over reordering + channels. This can be achieved either by ensuring that compressor + implementations use compressed headers that are sufficiently robust + to the expected possible reordering and/or by modifying decompressor + implementations to tolerate reordered packets. Ideas regarding how + existing profiles could be updated and how new profiles can be + defined to cope efficiently with reordering are also discussed. + + In some scenarios, there might be external means (such as a sequence + number) to detect and potentially correct reordering. That is, for + example, the case when running compression over an IPsec + Encapsulating Security Payload (ESP) tunnel. With such external + means to detect reordering, the decompressor can be modified to make + use of the external information provided, and reordering can then be + handled. How to make use of external means to address reordering is, + however, out of scope for this document. + + + +Pelletier, et al. Informational [Page 3] + +RFC 4224 ROHC over Reordering Channels January 2006 + + +2. Terminology + + This document uses terminology consistent with RFC 3759 [2], and is + in itself only informative. Although it does discuss technical + aspects of implementing the ROHC specifications in particular + environments, it does not specify any new technology. + + ROHC + + The term "ROHC" herein refers to the following profiles: + + - 0x0001, 0x0002, and 0x0003 defined in RFC 3095 [1]; + - 0x0004 for compression of IP-only headers [3]; + - 0x0007 and 0x0008 for compression of UDP-Lite headers [4]. + + The term "ROHC" excludes the following profiles, which are either + not affected by reordering or have the assumption of in-order + delivery as a fundamental requirement for their proper operation: + + - 0x0000 (uncompressed) [1]; + - 0x0005 (Link-Layer Assisted (LLA)) [5] and 0x0105 + (R-mode extension to LLA) [6]; + + Reordering + + A type of transmission taking place between compressor and + decompressor where in-order delivery of header-compressed packets + is not guaranteed. + + Reordering channel + + A connection over which reordering, as defined above, can occur. + + Sequentially early packet + + A packet that reaches the decompressor before one or several + packets of the same context identifier (CID) that were delayed on + the link. At the time of the arrival of a sequentially early + packet, the packet(s) delayed on the link cannot be differentiated + from lost packet(s). + + Sequentially late packet + + A packet is late within its sequence if it reaches the + decompressor after one or several other packets belonging to the + same CID have been received, although the sequentially late packet + was sent from the compressor before the other packet(s). + + + + +Pelletier, et al. Informational [Page 4] + +RFC 4224 ROHC over Reordering Channels January 2006 + + + Updating packet + + A packet that updates the context of the decompressor, e.g., all + packets except R-0 and R-1* in RFC 3095 [1]. + + Non-updating packet + + A packet that does not update the context of the decompressor, + e.g., only R-0 and R-1* in RFC 3095 [1]. + + Change packet + + A packet that updates one or more fields of the context other than + the fields pertaining to the functions established with respect to + the sequence number (SN). Specifically, it is a packet that + updates fields other than the SN, the IPv4 identifier (IP-ID), the + sequence number of an extension header or the RTP timestamp (TS). + +3. Applicability of This Document to ROHC Profiles + + This document addresses general reordering issues for ROHC profiles. + The foremost objectives are to ensure that ROHC implementations do + not forward packets with incorrectly decompressed headers to upper + layers, as well as to limit the possible increase in the rate of + decompression failures or in events leading to context damage, when + compression is applied over reordering channels. + +3.1. Profiles within Scope + + The following sections outline solutions that are generally + applicable to profiles 0x0001 (RTP), 0x0002 (UDP), and 0x0003 (ESP) + defined in RFC 3095 [1]. Profile 0x0000 (uncompressed) is not + affected by reordering, as the headers are sent uncompressed. The + solutions also apply to profiles for IP-only (0x0004) [3] and for + UDP-Lite (0x0007 and 0x0008) [4]. These profiles are based on the + profiles of RFC 3095 [1] and inherently make the same in-order + delivery assumption. + +3.2. Profiles with Special Considerations + + Special considerations are needed to make some of the implementation + solutions of sections 6.1 and 6.2 applicable to profiles 0x0002 (UDP) + [1], 0x0004 (IP-only) [3], and 0x0008 (UDP-Lite) [4]. For these + profiles, the SN is generated at the compressor, as it is not present + in headers being compressed. For the least significant bit (LSB) + encoding method, the interpretation interval offset (p) is always + p = -1 (see section 5.1.1) when interpreting the SN. The SN is thus + + + + +Pelletier, et al. Informational [Page 5] + +RFC 4224 ROHC over Reordering Channels January 2006 + + + required to increase for each packet received at the decompressor, + which means that reordered packets cannot be decompressed. + +3.3. Profiles Incompatible with Reordering + + The ROHC LLA profiles defined in RFC 3242 [5] and RFC 3408 [6] have + been explicitly designed with in-order delivery as a fundamental + requirement to their proper operation. Profiles 0x0005 and 0x0105 + can therefore not be implemented over channels where reordering can + occur; this document therefore does not apply to these profiles. + +4. Background + + ROHC was designed with the assumption that packets are delivered in + order from compressor to decompressor. This was considered as a + reasonable working assumption for links where it was expected that + ROHC would be used. However, many have expressed that it would be + desirable to use ROHC also over connections where in-order delivery + is not guaranteed [7]. + +4.1. Reordering Channels + + The reordering channels that are potential candidates to use ROHC are + single-hop channels and multi-hop virtual channels. + + A single-hop channel is a point-to-point link that constitutes a + single IP hop. Note that one IP hop could be one or multiple + physical links. For example, a single-hop reordering channel could + be a wireless link that applies error detection and performs + retransmissions to guarantee error-free delivery of all data. + Another example could be a wireless connection that performs + bicasting of data during a handoff procedure. + + A multi-hop virtual channel is a virtual point-to-point link that + traverses multiple IP hops. A multi-hop virtual channel would + typically be an IP tunnel, where compression is applied over the + tunnel by the endpoints of the tunnel (not to be confused with single + link compression of tunneled packets). + +4.2. Robustness Principles of ROHC + + Robustness is based on the optimistic approach in the unidirectional + and optimistic modes of operation (U/O-mode), and on the secure + reference principle in the bidirectional reliable mode (R-mode). + Both approaches have different characteristics in the presence of + reordering between compressor and decompressor. However, in any + mode, decompression of sequentially early packets will generally be + + + + +Pelletier, et al. Informational [Page 6] + +RFC 4224 ROHC over Reordering Channels January 2006 + + + handled quite well since they will be perceived and treated by the + decompressor as if there had been one or more packet losses. + +4.2.1. Optimistic Approach (U/O-mode) + + A ROHC compressor uses the optimistic approach to reduce header + overhead when performing context updates in U/O-mode. The compressor + normally repeats the same update until it is fairly confident that + the decompressor has successfully received the information. The + number of consecutive packets needed to obtain this confidence is + open to implementations, and this number is normally related to the + packet loss characteristics of the link where header compression is + used (see also [1], section 5.3.1.1.1). + + All packet types used in U/O-mode are context updating. + +4.2.2. Secure Reference Principle (R-mode) + + A ROHC compressor uses the secure reference principle in R-mode to + ensure that context synchronization between ROHC peers cannot be lost + due to packet losses. The compressor obtains its confidence that the + decompressor has successfully updated the context from a packet + carrying a 7- or 8-bit Cyclic Redundancy Check (CRC) based on + acknowledgements received from the decompressor (see also [1], + section 5.5.1.2). + + The secure reference principle makes it possible for a compressor to + use packets that do not update the context (i.e., R-0 and R-1* [1]). + +5. Problem Description + +5.1. ROHC and Reordering Channels + + This section reviews different aspects of ROHC susceptible of being + impacted by reordering of compressed packets between ROHC peers. + +5.1.1. LSB Interpretation Interval and Reordering + + The least significant bit (LSB) encoding method defined in RFC 3095 + ([1], section 5.7) specifies the interpretation interval offset, + called p, as follows: + + For profiles 0x0001, 0x0003, and 0x0007: + + p = 1, when bits(SN) <= 4; + p = 2^(bits(SN)-5) - 1 otherwise. + + + + + +Pelletier, et al. Informational [Page 7] + +RFC 4224 ROHC over Reordering Channels January 2006 + + + The resulting table describing the interpretation interval is as + follows: + + +-----------+--------------+--------------+ + | bits (SN) | Offset p | (2^k-1) - p | + | k | (reordering) | (losses) | + +-----------+--------------+--------------+ + | 4 | 1 | 14 | + | 5 | 0 | 31 | + | 6 | 1 | 62 | + | 7 | 3 | 124 | + | 8 | 7 | 248 | + | 9 | 15 | 496 | + +-----------+--------------+--------------+ + + As shown in the table above, the ability for ROHC to handle + sequentially late packets depends on the number of bits sent in + each packet. For example, a sequentially late packet of type 0 + (with either 4 or 6 bits of SN) sets the limit to one packet out + of sequence for successful decompression to be possible. + + For profiles 0x0002, 0x0004, and 0x0008: + + p = - 1, independently of bits(SN). + + A value of p = -1 means that the interpretation interval offset + can only take positive values and that no sequentially late packet + can be decompressed if reordering occurs over the link. + + The trade-off between reordering and robustness + + The ability of ROHC to handle sequentially late packets is limited + by the interpretation interval offset of the sliding window used + for LSB encoding. This offset has a very small value for packets + with a small number of sequence number (SN) bits, but grows with + the number of SN bits transmitted. + + For channels where both packet losses and reordering can occur, + modifications to the interpretation interval face a trade-off + between the amount of reordering and the number of consecutive + packet losses that can be handled by the decompressor. If the + negative offset (i.e., p) is increased to handle a larger amount + of reordering, the value of the positive offset of the + interpretation interval must be decreased. This may impact the + compression efficiency when the channel has a high loss rate. + + + + + + +Pelletier, et al. Informational [Page 8] + +RFC 4224 ROHC over Reordering Channels January 2006 + + + This is shown in the figure: + + <--- interpretation interval (size is 2^k) ----> + |------------------+---------------------------| + Lower v_ref Upper + Bound Bound + <--- reordering --> <--------- losses ---------> + max delta(SN) = p max delta(SN) = (2^k-1) - p + + where v_ref is the reference value as per [1], section 4.5.1. + + In practice, the maximum variation in SN value (max delta(SN)) due + to reordering that can be handled will normally correspond to the + maximum number of packets that can be reordered. The same applies + to the maximum number of consecutive packet losses covered by the + robustness interval. + + Timer-based compression of RTP TS (see [1], section 4.5.4) provides + means to reduce the number of timestamp bits needed in compressed + headers after longer gaps in the packet stream (e.g., for an audio + stream, this is typically due to silence suppression). To use + timer-based compression, an upper limit on the inter-arrival jitter + must be reliably estimated by the compressor. It should be noted + that although the risk of reordering of course means there is a more + significant jitter on the path between the compressor and the + decompressor, there are no special reordering considerations for + timer-based compression. It all still boils down to the task of + estimating the jitter, requiring channel characteristics knowledge at + the compressor, and/or jitter estimation figures received from the + decompressor. + +5.1.2. Reordering of Packets in R-mode + +5.1.2.1. Updating Packets + + The compressor always adds references in the sliding window for all + updating packets sent. The compressor removes values older than + values for which it has received an acknowledgement to shrink the + window and thereby increase the compression efficiency. + + The decompressor always updates the context when receiving an + updating packet and uses the new reference for decompression. + Acknowledgements are sent to allow the compressor to shrink its + sliding window. + + + + + + + +Pelletier, et al. Informational [Page 9] + +RFC 4224 ROHC over Reordering Channels January 2006 + + + Reordering between updating packets + + The decompressor can update its context from the reception of a + sequentially late updating packet. The decompressor reference is + then updated with a value that is no longer in the sliding window + of the compressor. This "missing reference" can be caused by + reordering when operating in R-mode. + + The result is that the compressor and the decompressor lose + synchronization with each other. When the decompressor + acknowledges the sequentially late packet, the compressor might + already have discarded the reference to this sequence number, and + continue to compress packets based on more recent references (in + packet arrival time). Decompression will then be attempted using + the wrong reference. + +5.1.2.2. Non-Updating Packets + + Reordering between non-updating packets only + + A non-updating packet that reaches the decompressor out of + sequence only with respect to other non-updating packets can + always be decompressed properly. + + Reordering between non-updating packets and updating packets + + When a non-updating packet is reordered and becomes sequentially + late with respect to an updating packet, the decompressor may have + already updated the context with a new reference when the late + packet is received. It is thus possible for a non-updating packet + to be decompressed based on the wrong reference because of + reordering when operating in R-mode. + + Since decompression of non-updating packets cannot be verified, + this can lead to a packet erroneously decompressed to be forwarded + to upper layers. + +5.1.3. Reordering of Packets in U/O-mode + + Reordering between non-change packets only + + When only non-change packets are reordered with respect to each + other, decompression of sequentially late packets is limited by + the offset p of the interpretation interval (see section 5.1.1). + Decompression of a sequentially late packet with SN = x is + possible if the value of the SN of the packet that last updated + the context was less than or equal to x + p. + + + + +Pelletier, et al. Informational [Page 10] + +RFC 4224 ROHC over Reordering Channels January 2006 + + + Problems occur if context(SN) has increased by more than p with + respect to field(SN) carried within the packet to decompress. + + This means that for a well-behaved stream with a constant unit + increase in the RTP SN, a packet can arrive up to p packets out of + sequence and still be correctly decompressed. Otherwise, it + cannot be properly decompressed. It also means that if the + compressor sends two consecutive packets with SN(packet1)=100 and + SN(packet2)=108 when p=7, packet1 cannot be decompressed if it + arrives even one packet late due to reordering. + + Reordering involving change packets + + When a packet is reordered and becomes sequentially late with + respect to a change packet, decompression of the late packet may + eventually fail, as the context information required for + successful decompression may not be available anymore. + + Decompression can always be verified since all U/O-mode packet types + are context updating. Consequently, a failure to decompress a packet + that is caused by reordering can be detected, and context + invalidation due to reordering can thus be avoided. The risk of + forwarding incorrectly decompressed packets to upper layers is + therefore small when operating in U/O-mode. For channels known to + reorder packets, U/O-mode should therefore be the preferred mode of + operation. The additional risk of losing context synchronization, or + for erroneous packet to be delivered to upper layers, is limited. + +5.1.4. Reordering on the Feedback Channel + + For R-mode, upon reception of an acknowledgement, the compressor + searches the sliding window to locate an updating packet with the + corresponding SN; if it is not found, the acknowledgement is invalid + and is discarded ([1], section 5.5.1.2). In other words, feedback + received out of order either is still useful or is discarded. + + In U/O-mode, if the compressor updates its context based on feedback, + the same logic as for R-mode applies in practice. + + Reordering on the feedback channel has thus no impact in either mode. + +5.1.5. List Compression + + ROHC list compression is an additional compression scheme for RTP + contributing source (CSRC) lists and IP extension header chains. The + base is called table-based item compression, and it is almost + completely independent from the rest of the ROHC compression logic. + Therefore, this part of the scheme does not exhibit any special + + + +Pelletier, et al. Informational [Page 11] + +RFC 4224 ROHC over Reordering Channels January 2006 + + + vulnerabilities when it comes to reordering, assuming a reasonable + optimistic approach is used in U/O-mode. Specifically, it does not + suffer significantly from the "missing reference" problem when + operating in R-mode. + + On top of the table-based item compression mechanism, an additional + compression technique may be used, called reference based list + compression. Reference based list compression however has a logic + that is similar to the rest of the ROHC compression logic, and + therefore it suffers from similar reordering vulnerabilities, + especially the "missing reference" problem of R-mode. Note, however, + that the generation identifier used in U/O-mode makes that scheme + more robust to reordering. + + When using list encoding type 1, 2, or 3, which makes use of + reference lists, decompression will succeed only if all individual + items are known by the decompressor, along with the correct reference + list required to properly decompress the packet. List compression + using the "Generic scheme", also known as "Encoding type 0", is not + using reference based list compression, and type 0 decompression will + thus succeed as long as all individual items are known by the + decompressor. Because of this, type 0 list compression should be the + preferred method used when operating over reordering channels. + +5.1.6. Reordering and Mode Transitions + + Transition from U/O-mode to R-mode + + This transition can be affected by reordering if a packet type 0 + (UO-0) is reordered and delayed by at least one round-trip time + (RTT). If the decompressor initiates a mode change request to + R-mode in the meantime, the reordered UO-0 packet may be handled + as an R-0 packet; it can be erroneously decompressed and forwarded + to upper layers. This is because the decompressor can switch to + R-mode as soon as it sends the acknowledgement Ack(SN, R) to the + compressor (see also [1], section 5.6). + + Transition from R-mode to U/O-mode + + A similar situation as above can occur during this transition. + However, because the outcome of the decompression is always + verified using a CRC verification in U/O-mode, the reordered + packet will most likely fail decompression and will be discarded. + + The above situation, although it is not deemed to occur frequently, + is still possible; thus, mode transitions from U/O-mode to R-mode + should be avoided when reordering can occur. + + + + +Pelletier, et al. Informational [Page 12] + +RFC 4224 ROHC over Reordering Channels January 2006 + + +5.2. Consequences of Reordering + + The context updating properties of the packets exchanged between ROHC + peers are the most important factors to consider when deriving the + impacts of reordering. For this reason, the robustness properties of + the U/O-mode and of the R-mode are affected differently. + + The effects of reordering on ROHC can be summarized as follows: + + - Functionality incompatible with reordering; + - Increased probability of context damage (loss of synchronization); + - Increased number of decompression failures - Detected (U/O/R-mode); + - Increased number of decompression failures - Undetected (R-mode). + +5.2.1. Functionality Incompatible with Reordering + + There is one optional ROHC function that cannot work in the presence + of reordering between ROHC peers. + + The ROHC segmentation scheme (see [1], section 5.2.5) relies entirely + on the in-order delivery of each segment, as there is no sequencing + information in the segments. A segmented packet for which one (or + more) segment is received out of order cannot be decompressed, and it + is discarded by the decompressor. Therefore, segmentation should not + be used if there can be reordering between the ROHC peers. + + The use of this optional feature is open to implementations and is + local to the compressor only; it does not impact the decompressor. + +5.2.2. Context Damage (Loss of Synchronization) + + Reordering of packets between ROHC peers can impact the robustness + properties of the optimistic approach (U/O-mode) as well as the + reliability of the secure reference principle (R-mode). + + The successful decompression of a sequentially late change packet + (U/O-mode) and/or updating packet (R-mode) can update the context of + the decompressor in a manner unexpected by the compressor. This can + lead to a loss of context synchronization between the ROHC peers. + +5.2.3. Detected Decompression Failures (U/O/R-mode) + + Reordering of packets between ROHC peers can lead to an increase in + the number of decompression failures for context updating packets + (see sections 5.1.2.1 and 5.1.3). Fortunately, as the outcome of the + decompression of updating packets can be verified, the decompressor + can reliably detect decompression failures, including those caused by + reordering, and discard the packet. Note that local repairs, subject + + + +Pelletier, et al. Informational [Page 13] + +RFC 4224 ROHC over Reordering Channels January 2006 + + + to the limitations stated in [1] section 5.3.2.2.3, can still be + performed. + +5.2.4. Undetected Decompression Failures (R-mode only) + + Reordering of packets between ROHC peers can lead to an increase in + the number of decompression errors for non-updating packets. For + R-mode, decompression of R-0 and R-1* packets cannot be verified. If + reordering occurs and decompression is performed using the wrong + secure reference (see section 5.1.2.1 and 5.1.2.2), the decompressor + cannot reliably detect such errors. As a result, erroneous packets + may be forwarded to upper layers. + +6. Making ROHC Tolerant against Reordering + + This section describes different approaches that can improve the + performance of ROHC when used over reordering channels and minimize + the effects of reordering. Examples are provided to guide + implementers and designers of new profiles. The solutions target + either the properties of ROHC implementations or the specification of + profiles. This is covered by sections 6.1 and 6.2, respectively. + +6.1. Properties of ROHC Implementations + + Existing ROHC profiles can be implemented with the capability to + properly handle packet reordering. The methods described in this + section conform with, and thus do not require any modifications to, + the ROHC specifications within scope of this document (see section + 3). Specifically, the methods presented in this section can be + implemented without any impairment to interoperability with other + ROHC implementations that do not use these methods. + + The methods suggested here may, however, lower the compression + efficiency, and these modifications should not be used when + reordering is known not to occur. Some of these methods aim to + increase the decompression success rate at the decompressor, while + others aim to avoid context damage that would cause a loss of context + synchronization between compressor and decompressor. + + The methods proposed are each addressing specific issues listed in + section 5 and can be combined to achieve better robustness against + reordering. + +6.1.1. Compressing Headers with Robustness against Reordering + + The methods described in this section are methods local only to the + compressor implementation. They can be used without modifications or + impact to the decompressor. + + + +Pelletier, et al. Informational [Page 14] + +RFC 4224 ROHC over Reordering Channels January 2006 + + +6.1.1.1. Reordering and the Optimistic Approach + + The optimistic approach is affected by the reordering characteristics + of the channel when operating over a reordering channel. Compressor + implementations should therefore adjust their optimistic approach + strategy to match both packet loss and reordering characteristics. + + For example, the number of repetitions for each context update can be + increased. The compressor should ensure that each update is repeated + until it is reasonably confident that at least one change packet in + the sequence of repetitions has reached the decompressor before the + first packet sent after this sequence. + +6.1.1.2. Reordering and the Secure Reference Principle + + Fundamental to the secure reference principle is that only values + acknowledged by the decompressor can be used as reference for + compression. In addition, some of the packet types used in R-mode do + not include a CRC over the original uncompressed header, and the + decompressor has no means to verify the outcome of the decompression. + + Decompression of non-updating packet types thus entirely relies on + the cumulative effect of previous updates to the secure reference, + and the compressed data is based on the current value of the + reference. This reference must be synchronized between ROHC peers. + For R-0 and R-1* packets, the reception of the encoded bits applied + to the secure reference is sufficient for correct decompression, but + only when in-order delivery between ROHC peers is guaranteed. + + Avoiding the "missing reference" problem (section 5.1.2.1) + + A compressor implementation can delay the advance in the sliding + window to a reference acknowledged by the decompressor, until it + has confidence that no acknowledgement for any of the values that + could be discarded can be received. This confidence can be based + on the maximum delay that reordering can introduce over the + channel. + +6.1.1.3. Robust Selection of Compressed Header + + Packet formats can be chosen with an interpretation interval for the + LSB encoded sequence number that allows for larger negative offsets + (see section 5.1.1). This provides the capability to decompress + sequentially late packets with a greater amount of reordering. + + To achieve this, the compressor should be implemented conservatively + in terms of the choice of packet types to send, by transmitting + packets with more sequence number bits. As shown in the table in + + + +Pelletier, et al. Informational [Page 15] + +RFC 4224 ROHC over Reordering Channels January 2006 + + + section 5.1.1, using 8 bits of SN allows a packet to be decompressed + when the reordering leads to up to 7 units in sequence number + variation (i.e., delta(SN)). Increasing the number of SN bits (i.e., + using a larger SN_k [1]) transmitted will make ROHC even more + tolerant to reordering. + + For example, a conservative compressor implementation could use the + packet types as shown in the table below: + + +----------------------+-------------------------+ + | Optimal Packet Type | Alternative Packet Type | + | (without reordering) | (reordering possible) | + +----------------------+-------------------------+ + | UO-0 | UOR-2*-ext0 | + | R-0 | R-1*-ext0 | + | R-0-CRC | UOR-2*-ext0 | + | R-1* | R-1*-ext0 | + | UO-1 | UOR-2-ext0 | + | UO-1-TS | UOR-2-TS-ext0 | + | UO-1-ID | UO-1-ID-ext3 (with S=1) | + | | UOR-2-ID-ext0 | + | UOR-2* | UOR-2*-ext0 | + +----------------------+-------------------------+ + + Such a compressor implementation would thus always be sending at + least 3 octets (R-mode) or 4 octets (U/O-mode). This is a trade-off + when compared to the 1 octet that can be sent by a more aggressive + implementation operating on a channel with no reordering. + + Note that since the interpretation interval for profiles 0x0002, + 0x0004, and 0x0008 is always p = -1 independently of bits(SN), the + methods suggested in this section will not work for these profiles + unless this value is modified (section 6.2.1). + +6.1.2. Implementing a Reordering-Tolerant Decompressor + + The methods described in this section are methods local only to the + decompressor implementation. They can be used without modifications + or impact to the compressor. + +6.1.2.1. Decompressor Feedback Considerations + + Reducing the feedback rate when the flow behaves linearly + + The decompressor should reduce its feedback rate when a large + number of UOR-2 packets with extensions are received, when the + flow behaves linearly (i.e., when only fields pertaining to the + + + + +Pelletier, et al. Informational [Page 16] + +RFC 4224 ROHC over Reordering Channels January 2006 + + + functions established with respect to the sequence number are + changing). + + In particular, if the compressor implementation makes a more + conservative selection of packet types (section 6.1.1.3) in order + to handle reordering, the decompressor should try to avoid sending + more feedback than it would for the case where the more optimal + packet types are used. This can be useful to minimize the usage + of the feedback channel, thereby improving efficiency of the link. + + Note that even if the decompressor does not make this adjustment + to its feedback rate, packet losses or context damages will not + increase. + + Acknowledgements and sequentially late packets + + Reordered feedback (or feedback for packets received out of order) + will not cause problems (see section 5.1.4). However, the + decompressor should not send acknowledging feedback for a packet + that can be identified as being sequentially late (e.g., based on + the sequence number of the packet), as the current state of the + context will better reflect the compressor context than the + content of the reordered packet. + +6.1.2.2. Considerations for Local Repair Mechanisms + + When decompression fails, and if reordering can be assumed to be the + cause of this failure, subsequent decompressions may be attempted for + sequentially late packets by going backward in the interpretation + interval (as opposed to moving forward for local repair). If one of + the decompression attempts is successful, the late packet may be + passed on to upper layers with or without updating the decompressor + context. If the subsequent decompression attempt fails, the packet + should be handled according to [1] section 5.3.2.2.3. + +6.2. Specifying ROHC Profiles with Robustness against Reordering + +6.2.1. Profiles with Interpretation Interval Offset p = -1 + + New revisions of profiles 0x0002 (UDP) [1], 0x0004 (IP-only) [3], and + 0x0008 (UDP-Lite) [4] should redefine how the value of the offset p + is determined, and use the same algorithm as in profile 0x0001 [1] + instead of p = -1 independently of bits(SN) (section 5.1.1). + + While such a change would make these updated profiles slightly less + robust to packet losses, they would still be no less robust than + profile 0x0001. + + + + +Pelletier, et al. Informational [Page 17] + +RFC 4224 ROHC over Reordering Channels January 2006 + + +6.2.2. Modifying the Interpretation Interval Offset + + The interpretation interval offset p could be modified for existing + profiles to handle reordering while improving the compression + efficiency when compared to the solution in section 6.1.1.3. + +6.2.2.1. Example Profile for Handling Reordering + + The value of the interpretation interval offset p can be adjusted to + achieve a robustness against reordering similar to the effect of + selecting packet types as suggested in section 6.1.1.3. + + Consider a scenario where robustness against packet losses is kept a + priority, and for which of a value p=7 is deemed enough. In this + case, a ratio where the positive offset is about twice as large as + the negative offset can be used. This leaves a value of p = 2^k/ 3. + + The resulting values are shown in the following table: + + +-----------+--------------+----------------+ + | bits (SN) | Offset p | Positive range | + | k | (reordering) | (losses) | + +-----------+--------------+----------------+ + | 4 | 5 | 10 | + | 5 | 10 | 21 | + | 6 | 21 | 42 | + | 7 | 42 | 85 | + | 8 | 85 | 170 | + | 9 | 170 | 341 | + +-----------+--------------+----------------+ + + Using this value for p, a fair amount of reordering can be handled + without having to send UOR-2 packets most of the time. The trade-off + is that this is at the expense of robustness against packet losses. + +6.2.2.2. Defining the Values of p for New Profiles + + As described in RFC 3095 [1], the interpretation interval when + sending k bits of SN is defined as follows: + + f(v_ref, k) = [v_ref - p, v_ref + (2^k - 1) - p] + + The negative bound (v_ref - p) limits the ability to handle + reordering, and the positive bound (v_ref + (2^k - 1) - p) limits the + ability to handle packet losses. + + Adjusting p will increase one of these ranges, while the other range + will decrease. This trade-off between the capability to handle + + + +Pelletier, et al. Informational [Page 18] + +RFC 4224 ROHC over Reordering Channels January 2006 + + + reordering and packet losses, including how these correlate with each + other, should be considered in a ROHC profile that is meant to handle + reordering. + + For example, if it is desirable for a profile to be as robust against + reordering (negative range) and against packet losses (positive + range), this range can be made equal by setting p near (2^k / 2). + +7. Security Considerations + + This document does not include additional security risks to [1]. In + addition, it may lower risks related to context damage in R-mode with + injected packets when sequentially late packets do not update the + context (section 6.1.2.1). + +8. Acknowledgements + + Thanks to the committed WG document reviewers, Carl Knutsson and Mark + West, for their review efforts. Thanks also to Aniruddha Kulkarni, + Ramin Rezaiifar, and Gorry Fairhurst for their constructive comments. + +9. Informative References + + [1] 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. + + [2] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology + and Channel Mapping Examples", RFC 3759, April 2004. + + [3] Jonsson, L-E. and G. Pelletier, "RObust Header Compression + (ROHC): A Compression Profile for IP", RFC 3843, June 2004. + + [4] Pelletier, G., "RObust Header Compression (ROHC): Profiles for + User Datagram Protocol (UDP) Lite", RFC 4019, April 2005. + + [5] Jonsson, L-E. and G. Pelletier, "RObust Header Compression + (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242, + April 2002. + + [6] Liu, Z. and K. Le, "Zero-byte Support for Bidirectional Reliable + Mode (R-mode) in Extended Link-Layer Assisted RObust Header + Compression (ROHC) Profile", RFC 3408, December 2002. + + + + + +Pelletier, et al. Informational [Page 19] + +RFC 4224 ROHC over Reordering Channels January 2006 + + + [7] Ash, J., Goode, B., Hand, J., and R. Zhang, "Requirements for + Header Compression over MPLS", RFC 4247, November 2005. + +Authors' Addresses + + 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 + + + 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 + + + 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 + + + + + + + + + + + + + + + + + + +Pelletier, et al. Informational [Page 20] + +RFC 4224 ROHC over Reordering Channels 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). + + + + + + + +Pelletier, et al. Informational [Page 21] + |