diff options
Diffstat (limited to 'doc/rfc/rfc4815.txt')
| -rw-r--r-- | doc/rfc/rfc4815.txt | 1851 |
1 files changed, 1851 insertions, 0 deletions
diff --git a/doc/rfc/rfc4815.txt b/doc/rfc/rfc4815.txt new file mode 100644 index 0000000..3307cf2 --- /dev/null +++ b/doc/rfc/rfc4815.txt @@ -0,0 +1,1851 @@ + + + + + + +Network Working Group L-E. Jonsson +Request for Comments: 4815 K. Sandlund +Updates: 3095, 3241, 3843, 4019, 4362 G. Pelletier +Category: Standards Track P. Kremer + February 2007 + + + RObust Header Compression (ROHC): + Corrections and Clarifications to RFC 3095 + +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 IETF Trust (2007). + +Abstract + + RFC 3095 defines the RObust Header Compression (ROHC) framework and + profiles for IP (Internet Protocol), UDP (User Datagram Protocol), + RTP (Real-Time Transport Protocol), and ESP (Encapsulating Security + Payload). Some parts of the specification are unclear or contain + errors that may lead to misinterpretations that may impair + interoperability between different implementations. This document + provides corrections, additions, and clarifications to RFC 3095; this + document thus updates RFC 3095. In addition, other clarifications + related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) and + RFC 4109 (ROHC UDP-Lite profiles) are also provided. + + + + + + + + + + + + + + + + + +Jonsson, et al. Standards Track [Page 1] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + +Table of Contents + + 1. Introduction and Terminology ....................................3 + 2. CRC Calculation and Coverage ....................................4 + 2.1. CRC Calculation ............................................4 + 2.2. Padding Octet and CRC Calculations .........................4 + 2.3. CRC Coverage in CRC Feedback Options .......................5 + 2.4. CRC Coverage of the ESP NULL Header ........................5 + 3. Mode Transition .................................................5 + 3.1. Feedback During Mode Transition to U- and O-Mode ...........5 + 3.1.1. Mode Transition Procedures Allowing Sparse Feedback .6 + 3.1.2. Transition from Reliable to Optimistic Mode .........7 + 3.1.3. Transition to Unidirectional Mode ...................8 + 3.2. Feedback During Mode Transition ............................8 + 3.3. Packet Decoding During Mode Transition .....................9 + 4. Timestamp Encoding ..............................................9 + 4.1. Encoding Used for Compressed TS Bits .......................9 + 4.2. (De)compression of TS without Transmitted TS Bits .........10 + 4.3. Interpretation Intervals for TS Encoding ..................11 + 4.4. Scaled RTP Timestamp Encoding .............................11 + 4.4.1. TS_STRIDE for Scaled Timestamp Encoding ............11 + 4.4.2. TS Wraparound with Scaled Timestamp Encoding .......12 + 4.4.3. Algorithm for Scaled Timestamp Encoding ............12 + 4.5. Recalculating TS_OFFSET ...................................14 + 4.6. TS_STRIDE and the Tsc Flag in Extension 3 .................14 + 4.7. Using Timer-Based Compression .............................15 + 5. List Compression ...............................................15 + 5.1. CSRC List Items in RTP Dynamic Chain ......................15 + 5.2. Multiple Occurrences of the CC Field ......................15 + 5.3. Bit Masks in List Compression .............................16 + 5.4. Headers Compressed with List Compression ..................16 + 5.5. ESP NULL Header List Compression ..........................17 + 5.6. Translation Tables and Indexes for IP Extension Headers ...17 + 5.7. Reference List ............................................17 + 5.8. Compression of AH and GRE Sequence Numbers ................18 + 6. Updating Properties ............................................19 + 6.1. Implicit Updates ..........................................19 + 6.2. Updating Properties of UO-1* ..............................20 + 6.3. Context Updating Properties for IR Packets ................20 + 6.4. RTP Padding Field (R-P) in Extension 3 ....................20 + 6.5. RTP eXtension bit (X) in dynamic part .....................21 + 7. Context management and CID/context Reuse .......................21 + 7.1. Persistence of Decompressor Contexts ......................21 + 7.2. CID/Context Reuse .........................................21 + 7.2.1. Reusing a CID/Context with the Same Profile ........22 + 7.2.2. Reusing a CID/Context with a Different Profile .....23 + 8. Other Protocol Clarifications ..................................23 + 8.1. Meaning of NBO ............................................23 + + + +Jonsson, et al. Standards Track [Page 2] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + + 8.2. IP-ID .....................................................23 + 8.3. Extension-3 in UOR-2* Packets .............................24 + 8.4. Multiple Occurrences of the M Bit .........................24 + 8.5. Multiple SN options in one feedback packet ................24 + 8.6. Multiple CRC Options in One Feedback Packet ...............25 + 8.7. Responding to Lost Feedback Links .........................25 + 8.8. UOR-2 in Profile 0x0002 (UDP) and Profile 0x0003 (ESP) ....25 + 8.9. Sequence Number LSB's in IP Extension Headers .............25 + 8.10. Expecting UOR-2 ACKs in O-Mode ...........................26 + 8.11. Context Repairs, TS_STRIDE and TIME_STRIDE ...............26 + 9. ROHC Negotiation ...............................................27 + 10. PROFILES Sub-option in ROHC-over-PPP ..........................27 + 11. Constant IP-ID Encoding in IP-only and UPD-Lite Profiles ......27 + 12. Security Considerations .......................................28 + 13. Acknowledgments ...............................................28 + 14. References ....................................................28 + 14.1. Normative References .....................................28 + 14.2. Informative References ...................................29 + Appendix A. Sample CRC Algorithm ..................................30 + +1. Introduction and Terminology + + RFC 3095 [1] defines the RObust Header Compression (ROHC) framework + and profiles for IP (Internet Protocol) [8][9], UDP (User Datagram + Protocol) [10], RTP (Real-Time Transport Protocol) [11], and ESP + (Encapsulating Security Payload) [12]. During implementation and + interoperability testing of RFC 3095, some ambiguities and common + misinterpretations have been identified, as well as a few errors. + + This document summarizes identified issues and provides corrections + needed for implementations of RFC 3095 to interoperate, i.e., it + constitutes an update to RFC 3095. This document also provides other + clarifications related to common misinterpretations of the + specification. References to RFC 3095 should, therefore, also + include this document. + + In addition, some clarifications and corrections are also provided + for RFC 3241 (ROHC over PPP) [2], RFC 3843 (ROHC IP-only profile) + [4], and RFC 4019 (ROHC UDP-Lite profiles) [5], which are thus also + updated by this document. Furthermore, RFC 4362 (ROHC Link-Layer + Assisted Profile) [7] is implicitly updated by this document, since + RFC 4362 is also based on RFC 3095. + + 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 [6]. + + + + + +Jonsson, et al. Standards Track [Page 3] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + + When a section of this document makes formal corrections, additions + or invalidations to text in RFC 3095, this is clearly summarized. + The text from RFC 3095 that is being addressed is given and labeled + "INCOMPLETE", "INCORRECT", or "INCORRECT AND INVALIDATED", followed + by the correct text labeled "CORRECTED", where applicable. When text + is added that does not simply correct text in previous + specifications, it is given with the label "FORMAL ADDITION". + + In this document, a reference to a section in RFC 3095 [1] is written + as RFC 3095-Section <number>. + +2. CRC Calculation and Coverage + +2.1. CRC Calculation + + RFC 3095-Section 5.9 defines polynomials for 3-, 7-, and 8-bit Cyclic + Redundancy Checks (CRCs), but it does not specify what algorithm is + used. The 3-, 7- and 8-bit CRCs are calculated using the CRC + algorithm defined in [3]. + + A Perl implementation of the algorithm can be found in Appendix A of + this document. + +2.2. Padding Octet and CRC Calculations + + RFC 3095-Section 5.9.1 is incomplete, as it does not mention how to + handle the padding octet in CRC calculations for IR and IR-DYN + packets. Padding isn't meant to be a meaningful part of a packet and + is not included in the CRC calculation. As a result, the CRC does + not cover the Add-CID octet for CID 0, either. + + INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.9.1): + + "The CRC in the IR and IR-DYN packet is calculated over the entire + IR or IR-DYN packet, excluding Payload and including CID or any + Add-CID octet." + + CORRECTED TEXT: + + "The CRC in the IR and IR-DYN packet is calculated over the entire + IR or IR-DYN packet, excluding Payload, Padding and including CID + or any Add-CID octet, except for the add-CID octet for CID 0." + + + + + + + + + +Jonsson, et al. Standards Track [Page 4] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + +2.3. CRC Coverage in CRC Feedback Options + + RFC 3095-Section 5.7.6.3 is incomplete, as it does not mention how + the "size" field is handled when calculating the 8-bit CRC used in + the CRC feedback option. Since the "size" field is an extension of + the "code" field, it must be treated in the same way. + + INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7.6.3): + + "The CRC option contains an 8-bit CRC computed over the entire + feedback payload, without the packet type and code octet, but + including any CID fields, using the polynomial of section 5.9.1." + + CORRECTED TEXT: + + "The CRC option contains an 8-bit CRC computed over the entire + feedback payload including any CID fields but excluding the + packet type, the 'Size' field and the 'Code' octet, using the + polynomial of Section 5.9.1." + +2.4. CRC Coverage of the ESP NULL Header + + RFC 3095-Section 5.8.7 gives the CRC coverage of the ESP NULL [13] + header as "Entire ESP header". This must be interpreted as including + only the initial part of the header (i.e., Security Parameter Index + (SPI) and sequence number), and not the trailer part at the end of + the payload. Therefore, the ESP NULL header has the same CRC + coverage as the ESP header used in the ESP profile (RFC 3095-Section + 5.7.7.7). + +3. Mode Transition + +3.1. Feedback During Mode Transition to U- and O-Mode + + RFC 3095-Section 5.6.1 states that during mode transitions, while the + D_TRANS parameter is I, the decompressor sends feedback for each + received packet. This restrictive behavior prevents the decompressor + from using a sparse feedback algorithm during mode transitions. + + To reduce transmission overhead and computational complexity + (including CRC calculation) associated with feedback packets sent for + each decompressed packet during mode transition, a decompressor MAY + be implemented with slightly modified mode transition procedures + compared to those defined in [1], as described in this section. + + These enhanced procedures should be considered only as a possible + improvement to a decompressor implementation, since interoperability + is not affected in any way. A decompressor implemented according to + + + +Jonsson, et al. Standards Track [Page 5] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + + the optimized procedures will interoperate with an RFC 3095 + compressor, as well as a decompressor implemented according to the + procedures described in RFC 3095. + +3.1.1. Mode Transition Procedures Allowing Sparse Feedback + + The purpose of these enhanced transition procedures is to allow the + decompressor to sparsely send feedback for packets decompressed + during the second half of the transition procedure, i.e., after an + appropriate IR/IR-DYN/UOR-2 packet has been received from the + compressor. This is achieved by allowing the decompressor transition + parameter (D_TRANS) to be set to P (Pending) at that stage, as shown + in the transition diagrams of Sections 3.1.2 and 3.1.3 below. + + This enhanced transition, where feedback need not be sent for every + decompressed packet, does however introduce some considerations in + case feedback messages would be lost. Specifically, there is a risk + for a deadlock situation when a transition from R-mode is performed; + if no feedback message successfully reaches the compressor, the + transition is never completed. For transition between U-mode and + O-mode, there is also a small risk for reduced compression + efficiency. + + To avoid this, the decompressor MUST continue to send feedback at + least periodically, as well as when in a Pending transition state. + This is equivalent to enhancing the definition of the D_TRANS + parameter in RFC 3095-Section 5.6.1, to include the definition of a + Pending state: + + - D_TRANS: + Possible values for the D_TRANS parameter are (I)NITIATED, + (P)ENDING, and (D)ONE. D_TRANS MUST be initialized to D, and a + mode transition can be initiated only when D_TRANS is D. While + D_TRANS is I, the decompressor sends a NACK or ACK carrying a CRC + option for each packet received. When D_TRANS is set to P, the + decompressor does not have to send a NACK or ACK for each packet + received, but it MUST continue to send feedback with some + periodicity, and all feedback packets sent MUST include the CRC + option. This ensures that all mode transitions will be completed + also in case of feedback losses. + + The modifications affect transitions to Optimistic and Unidirectional + modes of operation (i.e., the transitions described in RFC 3095- + Section 5.6.5 and RFC 3095-Section 5.6.6) and make those transition + diagrams more consistent with the diagram describing the transition + to R-mode. + + + + + +Jonsson, et al. Standards Track [Page 6] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + +3.1.2. Transition from Reliable to Optimistic Mode + + The enhanced procedure for transition from Reliable to Optimistic + mode is shown below: + + Compressor Decompressor + ---------------------------------------------- + | | + | ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I + | +-<-<-<-<-<-<-<-+ | + C_TRANS = P |-<-<-<-+ | + C_MODE = O | | + |->->->-+ IR/IR-DYN/UOR-2(SN,O) | + | +->->->->->->->-+ | + |->-.. +->->->-| D_TRANS = P + |->-.. | D_MODE = O + | ACK(SN,O) +-<-<-<-| + | +-<-<-<-<-<-<-<-+ | + C_TRANS = D |-<-<-<-+ | + | | + |->->->-+ UO-0, UO-1* | + | +->->->->->->->-+ | + | +->->->-| D_TRANS = D + | | + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jonsson, et al. Standards Track [Page 7] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + +3.1.3. Transition to Unidirectional Mode + + The enhanced procedure for transition to Unidirectional mode is shown + on the following figure: + + Compressor Decompressor + ---------------------------------------------- + | | + | ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I + | +-<-<-<-<-<-<-<-+ | + C_TRANS = P |-<-<-<-+ | + C_MODE = U | | + |->->->-+ IR/IR-DYN/UOR-2(SN,U) | + | +->->->->->->->-+ | + |->-.. +->->->-| D_TRANS = P + |->-.. | + | ACK(SN,U) +-<-<-<-| + | +-<-<-<-<-<-<-<-+ | + C_TRANS = D |-<-<-<-+ | + | | + |->->->-+ UO-0, UO-1* | + | +->->->->->->->-+ | + | +->->->-| D_TRANS = D + | | D_MODE= U + +3.2. Feedback During Mode Transition + + RFC 3095-Section 5.6.1 states that feedback is always used during + mode transitions. However, the text then continues by making + concrete applications of the rule in an inconsistent way, making it + unclear when CRCs are used. Further, the text does not define how + the compressor should act during mode transitions based on feedback + not protected by CRCs, i.e., whether or not to carry out mode + transition actions. The proper behavior from the compressor is to + perform any action related to mode transitions only when the feedback + is protected by the CRC option. + + INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.6.1): + + "As a safeguard against residual errors, all feedback sent during + a mode transition MUST be protected by a CRC, i.e., the CRC + option MUST be used." + + CORRECTED TEXT: + + "As a safeguard against residual errors, all feedback sent by the + decompressor during a mode transition MUST be protected by a CRC, + i.e., the CRC option MUST be used. The compressor MUST ignore + + + +Jonsson, et al. Standards Track [Page 8] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + + feedback information related to mode transition if the feedback + is not protected by the CRC option." + + One more related issue that requires clarifications comes from the + following text at the end of RFC 3095-Section 5.6.1: + + "While D_TRANS is I, the decompressor sends a NACK or ACK carrying + a CRC option for each received packet." + + However, RFC 3095-Section 5.5.2.2 already stated that for R-mode, + feedback is never sent for packets that do not update the context, + i.e., for packets that do not carry a CRC, such as R-0 and R-1*. + + This means that when D_TRANS=I during mode transition, a decompressor + operating in R-mode sends an acknowledgement for each packet it + receives and MUST use the sequence number that corresponds to the + packet that last updated the context, i.e., the decompressor MUST NOT + use the sequence number of the R-0 or the R-1* packet. + +3.3. Packet Decoding During Mode Transition + + The purpose of a mode transition is to ensure that the compressor and + the decompressor coherently move from one mode of operation to + another using a three-way handshake. At one point during the mode + transition, the decompressor acknowledges the reception of one (or + more) IR, IR-DYN or UOR-2 packet(s) that have mode bits set to the + new mode. Packets of type 0 or type 1 that are received up to this + point are decompressed using the old mode, while afterwards they are + decompressed using the new mode. If the enhanced transition + procedures described in Section 3.1 are used, the setting of the + D_TRANS parameter to P represents this breakpoint. The successful + decompression of a packet of type 0 or type 1 completes the mode + transition. + +4. Timestamp Encoding + +4.1. Encoding Used for Compressed TS Bits + + RTP Timestamp (TS) values are always encoded using W-LSB encoding, + both when sent scaled and unscaled. When no TS bits are transmitted + in a compressed packet, TS is always scaled. If a compressed packet + carries an Extension 3 and field(Tsc)=0, the compressed packet must + thus always carry unscaled TS bits. For TS values sent in Extension + 3, W-LSB encoded values are sent using the self-describing variable- + length format (RFC 3095-Section 4.5.6), and this applies to both + scaled and unscaled values. + + + + + +Jonsson, et al. Standards Track [Page 9] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + +4.2. (De)compression of TS without Transmitted TS Bits + + When ROHC RTP operates using its most efficient packet types, apart + from packet type identification and the error detection CRC, only RTP + sequence number (SN) bits are transmitted in RTP compressed headers. + All other fields are then omitted either because they are unchanged + or because they can be reconstructed through a function from the SN + (i.e., by combining the transmitted SN bits with state information + from the context). Fields that can be inferred from the SN are the + IP Identification (IP-ID) and the RTP Timestamp (TS). + + IP-ID compression and decompression, both with and without + transmitted IP-ID bits in the compressed header, are well defined in + RFC 3095-Section 4.5.5 (see Section 8.2). For the TS field, however, + RFC 3095 only defines how to decompress based on actual TS bits in + the compressed header, either scaled or unscaled, but not how to + infer the TS from the SN when there are no TS bits present in the + compressed header. + + When no TS bits are received in the compressed header, the scaled TS + value is reconstructed assuming a linear extrapolation from the SN, + i.e., delta_TS = delta_SN * default-slope, where delta_SN and + delta_TS are both signed integers. RFC 3095-Section 5.7 defines the + potential values for default-slope. + + INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7): + + "If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before + compression (see section 4.5.3), and default-slope(TS) = 1. + + If value(Tsc) = 0, the Timestamp value is compressed as-is, and + default-slope(TS) = value(TS_STRIDE)." + + CORRECTED TEXT: + + "When a compressed header with no TS bits is received, the scaled + TS value is reconstructed assuming a linear extrapolation from + the SN, i.e., delta_TS = delta_SN * default-slope(TS). + + If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before + compression (see Section 4.5.3), and default-slope(TS) = 1. + + If value(Tsc) = 0, the Timestamp value is compressed as-is, and + default-slope(TS) = value(TS_STRIDE). If a packet with no TS + bits is received with Tsc = 0, the decompressor MUST discard the + packet." + + + + + +Jonsson, et al. Standards Track [Page 10] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + + INCORRECT AND INVALIDATED RFC 3095 TEXT (Section RFC 3095-5.5.1.2): + + "For example, in a typical case where the string pattern has the + form of non-SN-field = SN * slope + offset, one ACK is enough if + the slope has been previously established by the decompressor + (i.e., only the new offset needs to be synchronized). Otherwise, + two ACKs are required since the decompressor needs two headers to + learn both the new slope and the new offset." + + Consequently, there is no other slope value than the default-slope, + as defined in RFC 3095-Section 5.7. + +4.3. Interpretation Intervals for TS Encoding + + RFC 3095-Section 4.5.4 defines the interpretation interval, p, for + timer-based compression of the RTP timestamp. However, RFC 3095- + Section 5.7 defines a different interpretation interval, which is + defined as the interpretation interval to use for all TS values. It + is thus unclear which p-value to use, at least for timer-based + compression. + + The way this should be interpreted is that the p-value differs + depending on whether or not timer-based compression is enabled. + + For timer-based compression (TIME_STRIDE set to a non-zero value), + the interpretation interval is: + + p = 2^(k-1) - 1 (as per RFC 3095-Section 4.5.4) + + Otherwise, the interpretation interval is: + + p = 2^(k-2) - 1 (as per RFC 3095-Section 5.7) + +4.4. Scaled RTP Timestamp Encoding + + This section redefines the algorithm for scaled RTP timestamp + encoding, defined as a 5-step procedure in RFC 3095-Section 4.5.3. + Two formal errors have been corrected, as described in sub-sections + 4.4.1 and 4.4.2 below, and the whole algorithm has been reworked to + be more concise and to use well-defined terminology. The resulting + text can be found in 4.4.3 below. + +4.4.1. TS_STRIDE for Scaled Timestamp Encoding + + RFC 3095 defines the timestamp stride (TS_STRIDE) as the expected + increase in the timestamp value between two RTP packets with + consecutive sequence numbers. TS_STRIDE is set by the compressor and + + + + +Jonsson, et al. Standards Track [Page 11] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + + explicitly communicated to the decompressor, and it is used as the + scaling factor for scaled TS encoding. + + The relation between TS and TS_SCALED, given by the following + equality in RFC 3095-Section 4.5.3, defines the mathematical meaning + of TS_STRIDE: + + TS = TS_SCALED * TS_STRIDE + TS_OFFSET + + TS_SCALED is incompletely written as TS / TS_STRIDE in the + compression step following the above core equality. This formula is + incorrect both because it excludes TS_OFFSET and because it would + prevent a TS_STRIDE value of 0, which is an alternative not excluded + by the definition or by the core equality above. If "/" were a + generally unambiguously defined operation meaning "the integral part + of the result from dividing X by Y", the absence of TS_OFFSET could + be explained, but the formula would still lack a proper output for + TS_STRIDE equal to 0. The formula of "2. Compression" is thus valid + only with the following requirements: + + a) "/" means "the integral part of the result from dividing X by Y" + + b) TS_STRIDE>0 (TS is never sent scaled when TS_STRIDE=0) + +4.4.2. TS Wraparound with Scaled Timestamp Encoding + + RFC 3095-Section 4.5.3 states in points 4 and 5 that the compressor + is not required to initialize TS_OFFSET at wraparound, but that it is + required to increase the number of bits sent for the scaled TS value + when there is a TS wraparound. The decompressor is also required to + detect and cope with TS wraparound, including updating TS_OFFSET. + + This method is not interoperable and not robust. The gain is also + insignificant, as TS wraparound happens very seldomly. Therefore, + the compressor should reinitialize TS_OFFSET upon TS wraparound, by + sending an unscaled TS. + +4.4.3. Algorithm for Scaled Timestamp Encoding + + INCORRECT RFC 3095 TEXT (RFC 3095-Section 4.5.3): + + "1. Initialization: The compressor sends to the decompressor the + value of TS_STRIDE and the absolute value of one or several TS + fields. The latter are used by the decompressor to initialize + TS_OFFSET to (absolute value) modulo TS_STRIDE. Note that + TS_OFFSET is the same regardless of which absolute value is + used, as long as the unscaled TS value does not wrap around; + see 4) below. + + + +Jonsson, et al. Standards Track [Page 12] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + + 2. Compression: After initialization, the compressor no longer + compresses the original TS values. Instead, it compresses the + downscaled values: TS_SCALED = TS / TS_STRIDE. The compression + method could be either W-LSB encoding or the timer-based + encoding described in the next section. + + 3. Decompression: When receiving the compressed value of + TS_SCALED, the decompressor first derives the value of the + original TS_SCALED. The original RTP TS is then calculated as + TS = TS_SCALED * TS_STRIDE + TS_OFFSET. + + 4. Offset at wraparound: Wraparound of the unscaled 32-bit TS will + invalidate the current value of TS_OFFSET used in the equation + above. For example, let us assume TS_STRIDE = 160 = 0xA0 and + the current TS = 0xFFFFFFF0. TS_OFFSET is then 0x50 = 80. + Then if the next RTP TS = 0x00000130 (i.e., the increment is + 160 * 2 = 320), the new TS_OFFSET should be 0x00000130 modulo + 0xA0 = 0x90 = 144. The compressor is not required to re- + initialize TS_OFFSET at wraparound. Instead, the decompressor + MUST detect wraparound of the unscaled TS (which is trivial) + and update TS_OFFSET to TS_OFFSET = (Wrapped around unscaled + TS) modulo TS_STRIDE" + + CORRECTED TEXT: + + "1. Initialization and updating of RTP TS scaling function: The + compressor sends to the decompressor the value of TS_STRIDE + along with an unscaled TS. These are both needed by the + decompressor to initialize TS_OFFSET as hdr(TS) modulo + field(TS_STRIDE). Note that TS_OFFSET is the same for any TS + as long as TS_STRIDE does not change and as long as the + unscaled TS value does not wrap around; see 4) below. + + 2. Compression: After initialization, the compressor no longer + compresses the unscaled TS values. Instead, it compresses the + scaled values. The compression method can be either W-LSB + encoding or timer-based encoding. + + 3. Decompression: When receiving a (compressed) TS_SCALED, the + field is first decompressed, and the unscaled RTP TS is then + calculated as TS = TS_SCALED * TS_STRIDE + TS_OFFSET. + + 4. Offset at wraparound: If the value of TS_STRIDE is not equal to + a power of two, wraparound of the unscaled 32-bit TS will + change the value of TS_OFFSET. When this happens, the + compressor SHOULD reinitialize TS_OFFSET by sending unscaled + TS, as in 1 above." + + + + +Jonsson, et al. Standards Track [Page 13] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + + INCORRECT AND INVALIDATED RFC 3095 TEXT (RFC 3095-Section 4.5.3): + + The entire point 5, i.e. the entire text starting from "5. + Interpretation interval at wraparound ...", down to and including + the block of text that starts with "Let a be the number of LSBs" + and that ends with "...interpretation interval is b." is incorrect + and is thus invalid. + +4.5. Recalculating TS_OFFSET + + TS can be sent unscaled if the TS value change does not match the + established TS_STRIDE, but the TS_STRIDE might still stay unchanged. + To ensure correct decompression of subsequent packets, the + decompressor MUST therefore always recalculate TS_OFFSET (RTP TS + modulo TS_STRIDE) when a packet with an unscaled TS value is + received. + +4.6. TS_STRIDE and the Tsc Flag in Extension 3 + + The Tsc flag in Extension 3 indicates whether or not TS is scaled. + The value of the Tsc flag thus applies to all TS bits, as well as if + there are no TS bits in the extension itself. When TS is scaled, it + is always scaled using context(TS_STRIDE). The legend for Extension + 3 in RFC 3095-Section 5.7.5 incorrectly states that value(TS_STRIDE) + is used for scaled TS. + + If TS_STRIDE is present in Extension 3, as indicated by the Tss flag + being set, the compressed header SHOULD carry unscaled TS bits; i.e., + the Tsc flag SHOULD NOT be set when Tss is set since an unscaled TS + is needed together with TS_STRIDE to recalculate the TS_OFFSET. If + TS_STRIDE is included in a compressed header with scaled TS, the + decompressor must ignore and discard field(TS_STRIDE). + + INCORRECT RFC 3095 TEXT (RFC 3095-Section 5.7.5): + + "Tsc: Tsc = 0 indicates that TS is not scaled; + Tsc = 1 indicates that TS is scaled according to section + 4.5.3, using value(TS_STRIDE). + Context(Tsc) is always 1. If scaling is not desired, the + compressor will establish TS_STRIDE = 1." + + CORRECTED TEXT: + + "Tsc: Tsc = 0 indicates that TS is not scaled; + Tsc = 1 indicates that TS is scaled according to Section + 4.5.3, using context(TS_STRIDE). + + + + + +Jonsson, et al. Standards Track [Page 14] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + + Context(Tsc) is always 1. If scaling is not desired, the + compressor will establish TS_STRIDE = 1. + + If field(Tsc) = 1, and if TSS = 1 (meaning that TS_STRIDE is + present in the extension), field(TS_STRIDE) MUST be ignored + and discarded." + + When the compressor re-establishes a new value for TS_STRIDE using + Extension 3, it should send unscaled TS bits together with TS_STRIDE. + +4.7. Using Timer-Based Compression + + Timer-based compression of the RTP timestamp, as described in RFC + 3095-Section 4.5.4, may be used to reduce the number of transmitted + timestamp bits (bytes) needed when the timestamp cannot be inferred + from the SN. Timer-based compression is only used for decompression + of compressed headers that contains a TS field; otherwise, when no + timestamp bits are present, the timestamp is linearly inferred from + the SN (see Section 4.2 of this document). + + Whether or not to use timer-based compression is controlled by the + TIME_STRIDE control field, which can be set by either an IR, an IR- + DYN, or a compressed packet with Extension 3. Before timer-based + compression can be used, the decompressor has to inform the + compressor (on a per-channel basis) about its clock resolution by + sending a CLOCK feedback option for any CID on the channel. The + compressor can then initiate timer-based compression by sending (on a + per-context basis) a non-zero TIME_STRIDE to the decompressor. When + the compressor is confident that the decompressor has received the + TIME_STRIDE value, it can switch to timer-based compression. + +5. List Compression + +5.1. CSRC List Items in RTP Dynamic Chain + + RFC 3095-Section 5.7.7.6 defines the static and dynamic parts of the + RTP header. This section indicates a 'Generic CSRC list' field in + the dynamic chain, which has a variable length (see RFC 3095-Section + 5.8.6). This field is always at least one octet in size, even if the + list is empty (as opposed to the CSRC list in the uncompressed RTP + header, which is not present when the RTP CC field is set to 0). + +5.2. Multiple Occurrences of the CC Field + + The static and the dynamic parts of the RTP header are defined in RFC + 3095-Section 5.7.7.6. In the dynamic part, a CC field indicates the + number of CSRC items present in the 'Generic CSRC list'. Another CC + field also appears within the 'Generic CSRC list' (RFC 3095-Section + + + +Jonsson, et al. Standards Track [Page 15] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + + 5.8.6.1), because Encoding Type 0 is always used in the dynamic + chain. Both CC fields have the same meaning: the value of the CC + field determines the number of XI items in the CSRC list for Encoding + Type 0, and it is not used otherwise. Therefore, the following + applies: + + FORMAL ADDITION TO RFC 3095: + + "The first octet in the dynamic part of the RTP header contains a + CC field, as defined in Section 5.7.7.6. A second occurrence + appears in the 'Generic CSRC list', which is also in the dynamic + part of the RTP header, where Encoding Type 0 is used according + to the format defined in RFC 3095-5.8.6.1. + + The compressor MUST set both occurrences of the CC field to the + same value. + + The decompressor MUST use the value of the CC field from the + Encoding Type 0 within the Generic CRSC list, and it MUST thus + ignore the first occurrence of the CC field." + +5.3. Bit Masks in List Compression + + The insertion and/or removal schemes, described in RFC 3095-Sections + 5.8.6.2 - 5.8.6.4, use bit masks to indicates insertion or removal + positions within the reference list. The size of the bit mask can be + 7 bits or 15 bits. + + The compressor MAY use a 7-bit mask, even if the reference list has + more than seven items, provided that changes to the list are only + applied to items within the first seven items of the reference list, + leaving items with an index not covered by the 7-bit mask unchanged. + The decompressor MUST NOT modify items with an index not covered by + the 7-bit mask, when a 7-bit mask is received for a reference list + that contains more than seven items. + +5.4. Headers Compressed with List Compression + + In RFC 3095-Section 5.8, it states that headers that can be part of + extension header chains "include" AH [14], ESP NULL [13], minimal + encapsulation (MINE) [15], GRE [16][17], and IPv6 [9] extensions. + This list of headers that can be compressed is correct, but the word + "include" should not be there, since only the header types listed can + actually be handled. It should further be noted that for the Minimal + Encapsulation (MINE) header, there is no explicit discussion of how + to compress it, as the header is sent either uncompressed or fully + compressed away. + + + + +Jonsson, et al. Standards Track [Page 16] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + +5.5. ESP NULL Header List Compression + + Due to the offset of the fields in the trailer part of the ESP + header, a compressor MUST NOT compress packets containing more than + one NULL ESP [13] header, unless the second-outermost header is + treated as a regular ESP [12] header and the packets are compressed + using profile 0x0003. + +5.6. Translation Tables and Indexes for IP Extension Headers + + RFC 3095-Section 5.8.4 describes how list indexes are associated to + list items and how table lists are built for IP extension headers. + The text incorrectly states that one index per type is used, since + the same type can appear several times with different content in one + single chain. + + In IP extension header list compression, an index is associated with + each individual extension header of an extension header chain. When + there are multiple non-identical occurrences of the same extension + type (Protocol Number) within a header chain, each MUST be given its + own index. + + In the case where there are multiple identical occurrences of the + same extension type, the compressor can associate them to the same + index. When the value of an item whose index occurs more than once + in the list is updated, the compressor MUST send the value for each + occurrence of that index in the list. + + When content of extension headers changes, an implementation can + choose to either use a different index or update the existing one. + Some extensions can be compressed away even when some fields change, + as those changes can be conveyed to the decompressor implicitly (e.g. + sequence numbers in extension headers that can be inferred from the + RTP SN) or explicitly (e.g., as part of the 'IP extension header(s)' + field in Extension 3). + + When there is more than one IP header, there is more than one list of + extension headers, and a translation table is maintained for each + list independently of one another. + +5.7. Reference List + + A list compressed using encoding type 1 (insertion), type 2 + (removal), or type 3 (removal/insertion) uses a coding scheme that is + based on the use of a reference list in the context (identified as + ref_id). + + + + + +Jonsson, et al. Standards Track [Page 17] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + + While it could seem to be a fair choice to send a type 1 list when + ref_id is an empty list, there is nothing gained in doing so with + respect to using a type 0 list. Sending a type 2 list when ref_id is + an empty list would lead to a failure, while sending a type 3 list + has very little meaning. All these alternatives could be seen as + possible, based on how list compression is specified in RFC 3095. + + If these alternatives were allowed, a decompressor would become + required to maintain a sliding window of ref_id lists in R-mode, even + for the case where no items are sent in the compressed list, and this + is not a desirable requirement. Using list encoding type 1, type 2, + and type 3 is therefore only allowed for non-empty reference lists. + + FORMAL ADDITION TO RFC 3095: + + "Regardless of the operating mode, for list encoding of type 1, + type 2, and type 3 lists, ref_id MUST refer to a non-empty list." + +5.8. Compression of AH and GRE Sequence Numbers + + RFC 3095-Section 5.8.4.2 and RFC 3095-Section 5.8.4.4 describe how to + compress the Authentication Header (AH) [14] and the Generic Routing + Encapsulation (GRE) [16][17] header. Both these sections present a + possibility to omit the AH/GRE sequence number in the compressed + header, under certain circumstances. However, the specific + conditions for omitting the AH/GRE sequence number, as well as the + concrete compression and decompression procedures to apply, are not + clearly defined to guarantee robustness and facilitate interoperable + implementation. + + Proper rules are provided for the ESP case, i.e.,: + + "Sequence Number: Not sent when the offset from the sequence + number of the compressed header is constant, when the compressor + has confidence that the decompressor has established the correct + offset. When the offset is not constant, the sequence number may + be compressed by sending LSBs" + + The same logic applies to the AH/GRE sequence numbers. + + INCORRECT RFC 3095 TEXT (RFC 3095-Section 5.8.4.2): + + "If the sequence number in the AH linearly increases as the RTP + Sequence Number increases, and the compressor is confident that + the decompressor has obtained the pattern, the sequence number in + AH need not be sent. The decompressor applies linear + extrapolation to reconstruct the sequence number in the AH." + + + + +Jonsson, et al. Standards Track [Page 18] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + + CORRECTED TEXT: + + "The AH sequence number can be omitted from the compressed header + when the offset from the sequence number (SN) of the compressed + header is constant, when the compressor has confidence that the + decompressor has established the correct offset." + + INCORRECT RFC 3095 TEXT (RFC 3095-Section 5.8.4.4): + + "If the sequence number in the GRE header linearly increases as + the RTP Sequence Number increases and the compressor is confident + that the decompressor has received the pattern, the sequence + number in GRE need not be sent. The decompressor applies linear + extrapolation to reconstruct the sequence number in the GRE + header." + + CORRECTED TEXT: + + "The GRE sequence number can be omitted from the compressed header + when the offset from the sequence number (SN) of the compressed + header is constant, when the compressor has confidence that the + decompressor has established the correct offset." + +6. Updating Properties + +6.1. Implicit Updates + + A context updating packet that contains compressed sequence number + information may also carry information about other fields; in such + cases, these fields are updated according to the content of the + packet. The updating packet also implicitly updates inferred fields + (e.g., RTP Timestamp) according to the current mode and the + appropriate mapping function of the updated and inferred fields. + + An updating packet thus updates the reference values of all header + fields, either explicitly or implicitly, except for the UO-1-ID + packet (see Section 6.2 of this document). In UO-mode, all packets + are updating packets, while in R-mode, all packets with a CRC are + updating packets. + + For example, a UO-0 packet contains the compressed RTP sequence + number (SN). Such a packet also implicitly updates RTP timestamp, + IPv4 ID, and sequence numbers of IP extension headers. + + + + + + + + +Jonsson, et al. Standards Track [Page 19] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + +6.2. Updating Properties of UO-1* + + RFC 3095-Section 5.7.3 states that the values provided in extensions + carried by a UO-1-ID packet do not update the context, except for SN, + TS, or IP-ID fields. However, RFC 3095-Section 5.8.1 correctly + states that the translation table in the context is updated whenever + an (Index, item) pair is received, something that is contradicted by + the statement in RFC 3095-5.7.3 because the UO-1-ID packet can carry + Extension 3 with (Index, item) pair items within the 'Compressed CSRC + list' field. In addition to this contradiction, the text does not + mention what to do with the other sequence numbers inferred from the + SN, which are also to be implicitly updated. The updating properties + of UO-1* as stated by RFC 3095-Section 5.7.3 are thus incomplete. + + INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7.3): + + "Values provided in extensions, except those in other SN, TS, or + IP-ID fields, do not update the context." + + CORRECTED TEXT: + + "UO-1-ID packets only updates TS, SN, IP-ID, and sequence numbers + of IP extension headers. Other values provided in extensions do + not update the context. + + The decompressor MUST update its translation table whenever an + (Index, item) pair is received, as per RFC 3095-Section 5.8.1, + and this rule applies also to UO-1-ID packets." + +6.3. Context Updating Properties for IR Packets + + IR packets do not clear the whole context, but update all fields + carried in the IR header. Similarly, an IR without a dynamic chain + simply updates the static part of the context, while the rest of the + context is left unchanged. + + A consequence of this is that fields that are not updated by the IR + packet, e.g., the translation tables for list compression, MUST NOT + be invalidated by the decompressor when it assumes context damage. + +6.4. RTP Padding Field (R-P) in Extension 3 + + RFC 3095-Section 5.7.5 defines the properties of RTP header flags and + fields in Extension 3. These get updated when the rtp flag of the + Extension 3 is set, i.e., when rtp = 1; otherwise, they are not + updated. However, it is unclear how Extension 3 updates the R-P bit + in the context. + + + + +Jonsson, et al. Standards Track [Page 20] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + + INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7.5): + + "R-P: RTP Padding bit, absolute value (presumed zero if absent)." + + CORRECTED TEXT: + + "R-P: RTP Padding bit. If R-PT = 1, R-P is the absolute value of + the RTP padding bit and this value updates context(R-P). If + R-PT = 0, context(R-P) is updated to zero." + +6.5. RTP eXtension bit (X) in dynamic part + + RFC 3095-Section 5.7.7.6 defines the properties of the RTP header + flags and fields in the RTP part of the dynamic chain of IR and IR- + DYN packets. However, it is unclear how the X bit is updated in the + context. + + INCOMPLETE RFC 3095 TEXT (RFC 3095-Section 5.7.7.6): + + "X: Copy of X bit from RTP header (presumed 0 if RX = 0)" + + CORRECTED TEXT: + + "X: X bit from RTP header. If RX = 1, X is the X bit from the RTP + header and this value updates context(X). If RX = 0, + context(X) is updated to zero." + +7. Context management and CID/context Reuse + +7.1. Persistence of Decompressor Contexts + + As part of the negotiated channel parameters, compressor and + decompressor have, through the MAX_CID parameter, agreed on the + highest context identification (CID) number to be used. By agreeing + on MAX_CID, the decompressor also agrees to provide memory resources + to host at least MAX_CID+1 contexts, and an established context with + a CID within this negotiated space MUST be kept by the decompressor + until either the CID gets reused, or the channel is taken down or + renegotiated. + +7.2. CID/Context Reuse + + As part of the channel negotiation, the maximal number of active + contexts supported is negotiated between the compressor and the + decompressor through the MAX_CID parameter. The value of MAX_CID can + differ significantly from one link application to another, as well as + the load in terms of the number of packet streams to compress. The + lifetime of a ROHC channel can also vary, from almost permanent to + + + +Jonsson, et al. Standards Track [Page 21] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + + rather short-lived. However, in general, it is not expected that + resources will be allocated for more contexts than what can + reasonably be expected to be active concurrently over the link. As a + consequence hereof, context identifiers (CIDs) and context memory are + resources that will have to be reused by the compressor as part of + what can be considered normal operation. + + How context resources are reused is left unspecified in RFC 3095 [1] + and subsequent 3095-based ROHC specifications. This document does + not intend to change that, i.e., ROHC resource management is still + considered an implementation detail. However, reusing a CID and its + allocated memory is not always as simple as initiating a context with + a previously unused CID. Because some profiles can be operating in + various modes where packet formats vary depending on current mode, + care has to be taken to ensure that the old context data will be + completely and safely overwritten, eliminating the risk of undesired + side effects from interactions between old and new context data. + This document therefore points out some important core aspects to + consider when implementing resource management in ROHC compressors + and decompressors. + + On a high level, CID/context reuse can be of two kinds, either reuse + for a new context based on the same profile as the old context, or + for a new context based on a different profile. These cases are + discussed separately in the following two sub-sections. + +7.2.1. Reusing a CID/Context with the Same Profile + + For multi-mode profiles, such as those defined in RFC 3095 [1], mode + transitions are performed using a decompressor-initiated handshake + procedure, as defined in RFC 3095-Section 5.6. When a CID/context is + reused for a new context based on the same profile as the old + context, the current mode of operation SHOULD be inherited from the + old to the new context. Specifically, the compressor SHOULD continue + to operate using the mode of operation of the old context also with + the new context. The reason for this is that there is no reliable + way for the compressor to inform the decompressor that a CID/context + reuse is happening. The decompressor can thus not be expected to + clear the context memory for the CID (see Section 6.3), and there is + no way to trigger a safe mode switching (which requires the + decompressor-initiated handshake procedure). + + The rule of mode inheritance applies also when the + CONTEXT_REINITIALIZATION signal (RFC 3095-Section 6.3.1) is used to + reinitiate an entire context. + + + + + + +Jonsson, et al. Standards Track [Page 22] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + +7.2.2. Reusing a CID/Context with a Different Profile + + When a CID is reused for a new context based on a different profile + than the old context, both the compressor and the decompressor MUST + start operation with that context in the initial mode of the profile + (if it is a multi-mode profile). This applies both to IR-initiated + new contexts and profile downgrades with IR-DYN (e.g., the profile + 0x0001 -> profile 0x0002 downgrade in RFC 3095-Section 5.11.1). + + Type 0 and type 1 packets have different formats in U/O- and R-mode, + and these R-mode packets have no CRC. When initiating a new context + on a reused R-mode CID, there is a risk that the decompressor will + misinterpret compressed packets if the initiating IR packets are + lost. + + A CID for a context currently operating in R-mode SHOULD therefore + not be reused for a new context based on a different profile than the + old context. A compressor doing otherwise should minimize the risk + for misinterpretation of R-0/R-1 by, e.g., not using packets of types + beginning with 00 or 10 before it is highly confident that the new + context has successfully been initiated at the decompressor. + +8. Other Protocol Clarifications + +8.1. Meaning of NBO + + In IPv4 dynamic part (RFC 3095-Section 5.7.7.4), if the 'NBO' bit is + set, it means that network byte order is used. + +8.2. IP-ID + + According to RFC 3095-Section 5.7, IP-ID means the compressed value + of the IPv4 header's 'Identification' field. Compressed packets + contain this compressed value (IP-ID), while IR packets with dynamic + chain and IR-DYN packets transmit the original, uncompressed + Identification field value. The IP-ID field always represents the + Identification value of the innermost IPv4 header whose corresponding + RND flag is not 1. + + If RND or RND2 is set to 1, the corresponding IP-ID(s) is (are) sent + as 16-bit uncompressed Identification value(s) at the end of the + compressed base header, according to the IP-ID description (see the + beginning of RFC 3095-Section 5.7). When there is no compressed IP- + ID, i.e., for IPv6 or when all IP Identification information is sent + as is (as indicated by RND/RND2 being set to 1), the decompressor + ignores IP-ID bits sent within compressed base headers. + + + + + +Jonsson, et al. Standards Track [Page 23] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + + When RND=RND2=0, IP-ID is compressed, i.e., expressed as an SN offset + and byte-swapped if NBO=0. This is the case also when 16 bits of + IP-ID is sent in Extension 3. + + When RND=0 but no IP-ID bits are sent in the compressed header, the + SN offset for IP-ID stays unchanged, meaning that Offset_m equals + Offset_ref, as described in Section 4.5.5. This is further expressed + in a slightly different way (with the same meaning) in Section 5.7, + where it is said that "default-slope(IP-ID offset) = 0", meaning, if + no bits are sent for IP-ID, its SN offset slope defaults to 0. + +8.3. Extension-3 in UOR-2* Packets + + Some flags of the IP header in the extension (e.g., NBO or RND) may + change the interpretation of fields in UOR-2* packets. In such + cases, when a flag changes in Extension 3, a decompressor MUST re- + parse the UOR-2* packet. + +8.4. Multiple Occurrences of the M Bit + + The RTP header part of Extension 3, as defined by RFC 3095-Section + 5.7.5, includes a one-bit field for the RTP Marker bit. This field + is also present in all compressed base header formats except for UO- + 1-ID; meaning, there may be two occurrences of the field within one + single compressed header. In such cases, the two M fields must have + the same value. + + FORMAL ADDITION TO RFC 3095: + + "When there are two occurrences of the M field in a compressed + header (both in the compressed base header and in the RTP part of + Extension 3), the compressor MUST set both these occurrences of + the M field to the same value. + + At the decompressor, if the two M field values of such a packet + are not identical, the packet MUST be discarded." + +8.5. Multiple SN options in one feedback packet + + The length of the sequence number field in the original ESP [12] + header is 32 bits. The format of the SN feedback option (RFC 3095- + Section 5.7.6.6) allows for 8 additional SN bits to the 12 SN bits of + the FEEDBACK-2 format (RFC 3095-Section 5.7.6.1). One single SN + feedback option is thus not enough for the decompressor to send back + all the 32 bits of the ESP sequence number in a feedback packet, + unless it uses multiple SN options in one feedback packet. + + + + + +Jonsson, et al. Standards Track [Page 24] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + + RFC 3095-Section 5.7.6.1 declares that a FEEDBACK-2 packet can + contain a variable number of feedback options, and the options can + appear in any order. + + When processing multiple SN options in one feedback packet, the SN + would be given by concatenating the fields. + +8.6. Multiple CRC Options in One Feedback Packet + + Although it is not useful to have more than one single CRC option in + a feedback packet, having multiple CRC options is still allowed. If + multiple CRC options are included, all such CRC options MUST be + identical, as they will be calculated over the same header; the + compressor MUST otherwise discard the feedback packet. + +8.7. Responding to Lost Feedback Links + + Although this is neither desirable or expected, it may happen that a + link used to carry feedback between two associated instances becomes + unavailable. If the compressor can be notified of such an event, the + compressor SHOULD restart compression for each flow that is operating + in R-mode. When restarting compression, the compressor SHOULD use a + different CID for each flow being restarted; this is useful to avoid + the possibility of misinterpreting the type of the compressed header + for the packet type identifiers that are common to both U/O-mode and + R-mode, when the flow is restarted in U-mode (see also Section 7.2). + + Generally, feedback links are not expected to disappear once present, + but it should be noted that this might be the case for certain link + technologies. + +8.8. UOR-2 in Profile 0x0002 (UDP) and Profile 0x0003 (ESP) + + One single new format is defined for UOR-2 in profile 0x0002 and + profile 0x0003, which replaces all three (UOR-2, UOR-2-ID, UOR-2-TS) + formats from profile 0x0001. The same UOR-2 format is thus used + independent of whether or not there are IP headers with a + corresponding RND=1. This also applies to the IP profile [4] and the + IP/UDP-Lite profile [5]. + +8.9. Sequence Number LSB's in IP Extension Headers + + In RFC 3095-Section 5.8.5, formats are defined for compression of IP + extension header fields. These include compressed sequence number + fields, and these fields contain the "LSB of sequence number". These + sequence numbers are not "LSB-encoded" as, e.g., the RTP sequence + number, but are the LSB's of the uncompressed fields. + + + + +Jonsson, et al. Standards Track [Page 25] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + +8.10. Expecting UOR-2 ACKs in O-Mode + + Usage of UOR-2 ACKs in O-mode, as discussed in RFC 3095-Section + 5.4.1.1.2, is optional. A decompressor can also send ACKs for + purposes other than to acknowledge the UOR-2, without having to + continue sending ACKs for all UOR-2. Similarly, a compressor + implementation can ignore UOR-2s ACKs for the purpose of adapting the + optimistic approach strategies. + + It is thus NOT RECOMMENDED to use the optional ACK mechanism in O- + mode, either in compressor or in decompressor implementations. + + Using an incorrect expectation on UOR-2 ACKs as a basis for + compressor behavior will significantly degrade the compression + performance. This is because UOR-2 ACKs can be sent from a + decompressor for other purposes than to acknowledge the UOR-2 packet, + e.g., to send feedback such as clock resolution, or to initiate a + mode transition. If an implementation does use the optional + acknowledgment algorithm described in Section 5.4.1.1.2, it must make + sure to set the k_3 and n_3 parameters to much larger values than 1 + to ensure that the compressor performance is not degraded due to the + problem described above. + +8.11. Context Repairs, TS_STRIDE and TIME_STRIDE + + The 7-bit CRC used to verify the outcome of the decompression attempt + covers the original uncompressed header. The CRC verification thus + excludes TS_STRIDE and TIME_STRIDE, as these fields are not part of + the original uncompressed header. + + The UOR-2 packet type can be used to update the value of the + TS_STRIDE and/or the TIME_STRIDE, with the Extension 3. However, + these fields are not used for decompression of the RTP TS field for + this packet type and their respective value is thus not verified, + either implicitly or explicitly. + + When the compressor receives a negative acknowledgement, it thus + cannot determine whether the failure may be caused by an unsuccessful + update to the TS_STRIDE and/or the TIME_STRIDE field(s), for which a + previous header that last attempted to update their value had + previously been acknowledged. + + FORMAL ADDITION TO RFC 3095: + + "When the compressor receives a NACK and uses the UOR-2 header + type to repair the decompressor context, it SHOULD include fields + that update the value of both the TS_STRIDE and the TIME_STRIDE + whose value it has updated at least once since the establishment + + + +Jonsson, et al. Standards Track [Page 26] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + + of that context, i.e., since the CID was first associated with + its current profile. + + When the compressor receives a static-NACK, it MUST include in + the IR header fields for both the TS_STRIDE and the TIME_STRIDE + whose value it has updated at least once since the establishment + of that context, i.e., since the CID was first associated with + its current profile." + +9. ROHC Negotiation + + RFC 3095-Section 4.1 states that the link layer must provide means to + negotiate, e.g., the channel parameters listed in RFC 3095-Section + 5.1.1. One of these parameters is the PROFILES parameter, which is a + set of non-negative integers where each integer indicates a profile + supported by the decompressor. + + Each profile is identified by a 16-bit value, where the 8 LSB bits + indicate the actual profile, and the 8 MSB bits indicate the variant + of that profile (see RFC 3095-Section 8). In the ROHC headers sent + over the link, the profile used is identified only with the 8 LSB + bits, which means that the compressor and decompressor must have + agreed on which variant to use for each profile. + + The negotiation protocol must thus be able to communicate to the + compressor the set of profiles supported by the decompressor. When + multiple variants of the same profile are available, the negotiation + protocol must provide the means for the decompressor to know which + variant will be used by the compressor. This basically means that + the PROFILES set after negotiation MUST NOT include more than one + variant of a profile. + +10. PROFILES Sub-option in ROHC-over-PPP + + The logical union of sub-options for IPCP and IPV6CP negotiations, as + specified by ROHC over PPP [2], cannot be used for the PROFILES + suboption, as the whole union would then have to be considered within + each of the two IPCP negotiations to avoid getting an ambiguous + profile set. An implementation of RFC 3241 MUST therefore ensure + that the same profile set is negotiated for both IPv4 and IPv6 + (IPCP/IPV6CP). + +11. Constant IP-ID Encoding in IP-only and UPD-Lite Profiles + + In the ROHC IP-only profile, Section 3.3 of RFC 3843 [4], a mechanism + for encoding of a constant Identification value in IPv4 (constant + IP-ID) is defined. This mechanism is also used by the ROHC UDP-Lite + profiles, RFC 4019 [5]. + + + +Jonsson, et al. Standards Track [Page 27] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + + The "Constant IP-ID" mechanism applies to both the inner and outer IP + header, when present, meaning that there will be both a SID and a + SID2 context value. + +12. Security Considerations + + This document provides a number of corrections and clarifications to + [1], but it does not make any changes with regard to the security + aspects of the protocol. As a consequence, the security + considerations of [1] apply without additions. + +13. Acknowledgments + + The authors would like to thank Vicknesan Ayadurai, Carsten Bormann, + Mikael Degermark, Zhigang Liu, Abigail Surtees, Mark West, Tommy + Lundemo, Alan Kennington, Remi Pelland, Lajos Zaccomer, Endre Szalai, + Mark Kalmanczhelyi, and Arpad Szakacs for their contributions and + comments. Thanks also to the committed document reviewers, Carl + Knutsson and Biplab Sarkar, who reviewed the document during working + group last-call. + +14. References + +14.1. Normative 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] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC + 3241, April 2002. + + [3] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July + 1994. + + [4] Jonsson, L-E. and G. Pelletier, "RObust Header Compression + (ROHC): A Compression Profile for IP", RFC 3843, June 2004. + + [5] Pelletier, G., "RObust Header Compression (ROHC): Profiles for + User Datagram Protocol (UDP) Lite", RFC 4019, April 2005. + + [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + + + +Jonsson, et al. Standards Track [Page 28] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + +14.2. Informative References + + [7] Jonsson, L-E., Pelletier, G., and K. Sandlund, "RObust Header + Compression (ROHC): A Link-Layer Assisted Profile for + IP/UDP/RTP", RFC 4362, January 2006. + + [8] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. + + [9] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) + Specification", RFC 2460, December 1998. + + [10] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August + 1980. + + [11] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, + "RTP: A Transport Protocol for Real-Time Applications", STD 64, + RFC 3550, July 2003. + + [12] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, + December 2005. + + [13] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its + Use With IPsec", RFC 2410, November 1998. + + [14] Kent, S., "IP Authentication Header", RFC 4302, December 2005. + + [15] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, + October 1996. + + [16] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, + "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. + + [17] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC + 2890, September 2000. + + + + + + + + + + + + + + + + + +Jonsson, et al. Standards Track [Page 29] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + +Appendix A. Sample CRC Algorithm + + #!/usr/bin/perl -w + use strict; + #================================= + # + # ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02 + # + # This little demo shows the four types of CRCs in use in RFC 3095, + # the specification for robust header compression. Type your data in + # hexadecimal form and then press Control+D. + # + #--------------------------------- + # + # utility + # + sub dump_bytes($) { + my $x = shift; + my $i; + for ($i = 0; $i < length($x); ) { + printf("%02x ", ord(substr($x, $i, 1))); + printf("\n") if (++$i % 16 == 0); + } + printf("\n") if ($i % 16 != 0); + } + + #--------------------------------- + # + # The CRC calculation algorithm. + # + sub do_crc($$$) { + my $nbits = shift; + my $poly = shift; + my $string = shift; + + my $crc = ($nbits == 32 ? 0xffffffff : (1 << $nbits) - 1); + for (my $i = 0; $i < length($string); ++$i) { + my $byte = ord(substr($string, $i, 1)); + for( my $b = 0; $b < 8; $b++ ) { + if (($crc & 1) ^ ($byte & 1)) { + $crc >>= 1; + $crc ^= $poly; + } else { + $crc >>= 1; + } + $byte >>= 1; + } + } + + + +Jonsson, et al. Standards Track [Page 30] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + + printf "%2d bits, ", $nbits; + printf "CRC: %02x\n", $crc; + } + + #--------------------------------- + # + # Test harness + # + $/ = undef; + $_ = <>; # read until EOF + my $string = ""; # extract all that looks hex: + s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg; + dump_bytes($string); + + #--------------------------------- + # + # 32-bit segmentation CRC + # Note that the text implies that this is complemented like for PPP + # (this differs from 8-, 7-, and 3-bit CRCs) + # + # C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 + + # x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32 + # + do_crc(32, 0xedb88320, $string); + + #--------------------------------- + # + # 8-bit IR/IR-DYN CRC + # + # C(x) = x^0 + x^1 + x^2 + x^8 + # + do_crc(8, 0xe0, $string); + + #--------------------------------- + # + # 7-bit FO/SO CRC + # + # C(x) = x^0 + x^1 + x^2 + x^3 + x^6 + x^7 + # + do_crc(7, 0x79, $string); + + #--------------------------------- + # + # 3-bit FO/SO CRC + # + # C(x) = x^0 + x^1 + x^3 + # + do_crc(3, 0x6, $string); + + + +Jonsson, et al. Standards Track [Page 31] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + +Authors' Addresses + + Lars-Erik Jonsson + Optand 737 + SE-831 92 Ostersund, Sweden + Phone: +46 70 365 20 58 + EMail: lars-erik@lejonsson.com + + Kristofer Sandlund + Ericsson AB + Box 920 + SE-971 28 Lulea, Sweden + Phone: +46 8 404 41 58 + EMail: kristofer.sandlund@ericsson.com + + Ghyslain Pelletier + Ericsson AB + Box 920 + SE-971 28 Lulea, Sweden + Phone: +46 8 404 29 43 + EMail: ghyslain.pelletier@ericsson.com + + Peter Kremer + Conformance and Software Test Laboratory + Ericsson Hungary + H-1300 Bp. 3., P.O. Box 107, HUNGARY + Phone: +36 1 437 7033 + EMail: peter.kremer@ericsson.com + + + + + + + + + + + + + + + + + + + + + + + +Jonsson, et al. Standards Track [Page 32] + +RFC 4815 Corrections and Clarifications to RFC 3095 February 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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, THE IETF TRUST 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 currently provided by the + Internet Society. + + + + + + + +Jonsson, et al. Standards Track [Page 33] + |