idnits 2.17.1 draft-ietf-rohc-rtp-impl-guide-22.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1497. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1468. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1481. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The abstract seems to indicate that this document updates RFC3095, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 6, 2006) is 6378 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0-9a-fA-F' on line 1421 -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '9') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 1889 (ref. '11') (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. '12') (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. '14') (Obsoleted by RFC 4302, RFC 4305) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L-E. Jonsson 3 INTERNET-DRAFT K. Sandlund 4 TO UPDATE: RFC 3095, 3241, 3843, 4019, 4362 G. Pelletier 5 Expires: May 2007 P. Kremer 6 Ericsson 7 November 6, 2006 9 RObust Header Compression (ROHC): 10 Corrections and Clarifications to RFC 3095 11 13 Status of this memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This document is a submission of the IETF ROHC WG. Comments should be 36 directed to the ROHC WG mailing list, rohc@ietf.org. 38 Abstract 40 RFC 3095 defines the RObust Header Compression (ROHC) framework and 41 profiles for IP (Internet Protocol), UDP (User Datagram Protocol), 42 RTP (Real-Time Transport Protocol), and ESP (Encapsulated Security 43 Payload). Some parts of the specification are unclear or contain 44 errors that may lead to misinterpretations that may impair 45 interoperability between different implementations. This document 46 provides corrections, additions and clarifications to RFC 3095; this 47 document thus updates RFC 3095. In addition, other clarifications 48 related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) and 49 RFC 4109 (ROHC UDP-Lite profiles) are also provided. 51 Table of Contents 53 1. Introduction and terminology.....................................3 54 2. CRC calculation and coverage.....................................4 55 2.1. CRC calculation.............................................4 56 2.2. Padding octet and CRC calculations..........................4 57 2.3. CRC coverage in CRC feedback options........................4 58 2.4. CRC coverage of the ESP NULL header.........................5 59 3. Mode transition..................................................5 60 3.1. Feedback during mode transition to U- and O-mode............5 61 3.1.1. Mode transition procedures allowing sparse feedback....5 62 3.1.2. Transition from Reliable to Optimistic mode............6 63 3.1.3. Transition to Unidirectional mode......................7 64 3.2. Feedback during mode transition.............................7 65 3.3. Packet decoding during mode transition......................8 66 4. Timestamp encoding...............................................8 67 4.1. Encoding used for compressed TS bits........................8 68 4.2. (De)compression of TS without transmitted TS bits...........8 69 4.3. Interpretation intervals for TS encoding...................10 70 4.4. Scaled RTP timestamp encoding..............................10 71 4.4.1. TS_STRIDE for scaled timestamp encoding...............10 72 4.4.2. TS wraparound with scaled timestamp encoding..........11 73 4.4.3. Algorithm for scaled timestamp encoding...............11 74 4.5. Recalculating TS_OFFSET....................................12 75 4.6. TS_STRIDE and the Tsc flag in Extension 3..................12 76 4.7. Using timer-based compression..............................13 77 5. List compression................................................14 78 5.1. CSRC list items in RTP dynamic chain.......................14 79 5.2. Multiple occurrences of the CC field.......................14 80 5.3. Bit masks in list compression..............................14 81 5.4. Headers compressed with list compression...................15 82 5.5. ESP NULL header list compression...........................15 83 5.6. Translation tables and indexes for IP extension headers....15 84 5.7. Reference list.............................................16 85 5.8. Compression of AH and GRE sequence numbers.................16 86 6. Updating properties.............................................17 87 6.1. Implicit updates...........................................17 88 6.2. Updating properties of UO-1*...............................18 89 6.3. Context updating properties for IR packets.................18 90 6.4. RTP padding field (R-P) in extension 3.....................18 91 6.5. RTP eXtension bit (X) in dynamic part......................19 92 7. Context management and CID/context re-use.......................19 93 7.1. Persistence of decompressor contexts.......................19 94 7.2. CID/context re-use.........................................19 95 7.2.1. Re-using a CID/context with the same profile..........20 96 7.2.2. Re-using a CID/context with a different profile.......20 97 8. Other protocol clarifications...................................21 98 8.1. Meaning of NBO.............................................21 99 8.2. IP-ID......................................................21 100 8.3. Extension-3 in UOR-2* packets..............................22 101 8.4. Multiple occurrences of the M bit..........................22 102 8.5. Multiple SN options in one feedback packet.................22 103 8.6. Multiple CRC options in one feedback packet................22 104 8.7. Responding to lost feedback links..........................23 105 8.8. UOR-2 in profile 0x0002 (UDP) and profile 0x0003 (ESP).....23 106 8.9. Sequence number LSB's in IP extension headers..............23 107 8.10. Expecting UOR-2 ACKs in O-mode............................23 108 8.11. Context repairs, TS_STRIDE and TIME_STRIDE................24 109 9. ROHC negotiation................................................24 110 10. PROFILES suboption in ROHC-over-PPP............................25 111 11. Constant IP-ID encoding in IP-only and UPD-Lite profiles.......25 112 12. Security considerations........................................25 113 13. IANA considerations............................................25 114 14. Acknowledgment.................................................25 115 15. References.....................................................26 116 15.1. Normative References......................................26 117 15.2. Informative References....................................26 118 16. Authors' Addresses.............................................27 119 Appendix A - Sample CRC algorithm..................................28 121 1. Introduction and terminology 123 RFC 3095 [1] defines the RObust Header Compression (ROHC) framework 124 and profiles for IP (Internet Protocol) [8][9], UDP (User Datagram 125 Protocol) [10], RTP (Real-Time Transport Protocol) [11], and ESP 126 (Encapsulated Security Payload) [12]. During implementation and 127 interoperability testing of RFC 3095 some ambiguities and common 128 misinterpretations have been identified, as well as a few errors. 130 This document summarizes identified issues and provides corrections 131 needed for implementations of RFC 3095 to interoperate, i.e. it 132 constitutes an update to RFC 3095. This document also provides other 133 clarifications related to common misinterpretations of the 134 specification. References to RFC 3095 should therefore also include 135 this document. 137 In addition, some clarifications and corrections are also provided 138 for RFC 3241 (ROHC over PPP) [2], RFC 3843 (ROHC IP-only profile) 139 [4], and RFC 4019 (ROHC UDP-Lite profiles) [5], which are thus also 140 updated by this document. Furthermore, RFC 4362 (ROHC Link-Layer 141 Assisted Profile) [7] is implicitly updated by this document, since 142 also RFC 4362 is based on RFC 3095. 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [6]. 148 When a section of this document makes formal corrections, additions 149 or invalidations to text in RFC 3095, this is clearly summarized. The 150 text from RFC 3095 that is being addressed is given and labeled 151 "INCOMPLETE", "INCORRECT" or "INCORRECT AND INVALIDATED", followed by 152 the correct text labeled "CORRECTED", where applicable. When text is 153 added that does not simply correct text in previous specifications, 154 it is given with the label "FORMAL ADDITION". 156 In this document, a reference to a section in RFC 3095 [1] is written 157 as a prefixed section reference, RFC3095-
. 159 2. CRC calculation and coverage 161 2.1. CRC calculation 163 Section RFC3095-5.9 defines polynomials for 3, 7 and 8-bit CRCs, but 164 it does not specify what algorithm is used. The 3, 7 and 8-bit CRCs 165 are calculated using the CRC algorithm defined in [3]. 167 A Perl implementation of the algorithm can be found in Appendix A of 168 this document. 170 2.2. Padding octet and CRC calculations 172 Section RFC3095-5.9.1 is incomplete, as it does not mention how to 173 handle the padding octet in CRC calculations for IR and IR-DYN 174 packets. Padding isn't meant to be a meaningful part of a packet and 175 is not included in the CRC calculation. As a result, the CRC does not 176 cover the Add-CID octet for CID 0, either. 178 INCOMPLETE RFC 3095 TEXT (section RFC3095-5.9.1): 180 "The CRC in the IR and IR-DYN packet is calculated over the entire 181 IR or IR-DYN packet, excluding Payload and including CID or any 182 Add-CID octet." 184 CORRECTED TEXT: 186 "The CRC in the IR and IR-DYN packet is calculated over the entire 187 IR or IR-DYN packet, excluding Payload, Padding and including CID 188 or any Add-CID octet, except for the add-CID octet for CID 0." 190 2.3. CRC coverage in CRC feedback options 192 Section RFC3095-5.7.6.3 is incomplete, as it does not mention how the 193 "size" field is handled when calculating the 8-bit CRC used in the 194 CRC feedback option. Since the "size" field is an extension of the 195 "code" field, it must be treated in the same way. 197 INCOMPLETE RFC 3095 TEXT (section RFC3095-5.7.6.3): 199 "The CRC option contains an 8-bit CRC computed over the entire 200 feedback payload, without the packet type and code octet, but 201 including any CID fields, using the polynomial of section 5.9.1." 203 CORRECTED TEXT: 205 "The CRC option contains an 8-bit CRC computed over the entire 206 feedback payload including any CID fields but excluding the 207 packet type, the 'Size' field and the 'Code' octet, using the 208 polynomial of section 5.9.1." 210 2.4. CRC coverage of the ESP NULL header 212 Section RFC3095-5.8.7 gives the CRC coverage of the ESP NULL [13] 213 header as "Entire ESP header". This must be interpreted as including 214 only the initial part of the header (i.e. SPI and Sequence number), 215 and not the trailer part at the end of the payload. Therefore, the 216 ESP NULL header has the same CRC coverage as the ESP header used in 217 the ESP profile (section RFC3095-5.7.7.7). 219 3. Mode transition 221 3.1. Feedback during mode transition to U- and O-mode 223 Section RFC3095-5.6.1 states that during mode transitions, while the 224 D_TRANS parameter is I, the decompressor send feedback for each 225 received packet. This restrictive behavior prevents a decompressor 226 from using a sparse feedback algorithm during mode transitions. 228 To reduce transmission overhead and computational complexity 229 (including CRC calculation) associated with feedback packets sent for 230 each decompressed packet during mode transition, a decompressor MAY 231 be implemented with slightly modified mode transition procedures 232 compared to those defined in [1], as described in this section. 234 These enhanced procedures should be considered only as a possible 235 improvement to a decompressor implementation, since interoperability 236 is not affected in any way. A decompressor implemented according to 237 the optimized procedures will interoperate with an RFC3095 238 compressor, as well as a decompressor implemented according to the 239 procedures described in RFC3095. 241 3.1.1. Mode transition procedures allowing sparse feedback 243 The purpose of these enhanced transition procedures is to allow the 244 decompressor to sparsely send feedback for packets decompressed 245 during the second half of the transition procedure, i.e. after an 246 appropriate IR/IR-DYN/UOR-2 packet has been received from the 247 compressor. This is achieved by allowing the decompressor transition 248 parameter (D_TRANS) to be set to P (Pending) at that stage, as shown 249 in the transition diagrams of sections 3.1.2 and 3.1.3 below. 251 This enhanced transition, where feedback need not be sent for every 252 decompressed packet, does however introduce some considerations in 253 case feedback messages would be lost. Specifically, there is a risk 254 for a deadlock situation when a transition from R-mode is performed, 255 if no feedback message successfully reaches the compressor the 256 transition is never completed. For transition between U-mode and O- 257 mode, there is also a small risk for reduced compression efficiency. 259 To avoid this, the decompressor MUST continue to send feedback at 260 least periodically, also when in Pending transition state. This is 261 equivalent to enhancing the definition of the D_TRANS parameter in 262 section RFC3095-5.6.1, to include the definition of a Pending state: 264 - D_TRANS: 265 Possible values for the D_TRANS parameter are (I)NITIATED, 266 (P)ENDING and (D)ONE. D_TRANS MUST be initialized to D, and a mode 267 transition can be initiated only when D_TRANS is D. While D_TRANS 268 is I, the decompressor sends a NACK or ACK carrying a CRC option 269 for each packet received. When D_TRANS is set to P, the 270 decompressor do not have to send a NACK or ACK for each packet 271 received, but it MUST continue to send feedback with some 272 periodicity, and all feedback packets sent MUST include the CRC 273 option. This ensures that all mode transitions will be completed 274 also in case of feedback losses. 276 The modifications affect transitions to Optimistic and Unidirectional 277 modes of operation, i.e. the transitions described in sections 278 RFC3095-5.6.5 and RFC3095-5.6.6, and make those transition diagrams 279 more consistent with the diagram describing the transition to R-mode. 281 3.1.2. Transition from Reliable to Optimistic mode 283 The enhanced procedure for transition from Reliable to Optimistic 284 mode is shown below: 286 Compressor Decompressor 287 ---------------------------------------------- 288 | | 289 | ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I 290 | +-<-<-<-<-<-<-<-+ | 291 C_TRANS = P |-<-<-<-+ | 292 C_MODE = O | | 293 |->->->-+ IR/IR-DYN/UOR-2(SN,O) | 294 | +->->->->->->->-+ | 295 |->-.. +->->->-| D_TRANS = P 296 |->-.. | D_MODE = O 297 | ACK(SN,O) +-<-<-<-| 298 | +-<-<-<-<-<-<-<-+ | 299 C_TRANS = D |-<-<-<-+ | 300 | | 301 |->->->-+ UO-0, UO-1* | 302 | +->->->->->->->-+ | 303 | +->->->-| D_TRANS = D 304 | | 306 3.1.3. Transition to Unidirectional mode 308 The enhanced procedure for transition to Unidirectional mode is shown 309 on the following figure: 311 Compressor Decompressor 312 ---------------------------------------------- 313 | | 314 | ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I 315 | +-<-<-<-<-<-<-<-+ | 316 C_TRANS = P |-<-<-<-+ | 317 C_MODE = U | | 318 |->->->-+ IR/IR-DYN/UOR-2(SN,U) | 319 | +->->->->->->->-+ | 320 |->-.. +->->->-| D_TRANS = P 321 |->-.. | 322 | ACK(SN,U) +-<-<-<-| 323 | +-<-<-<-<-<-<-<-+ | 324 C_TRANS = D |-<-<-<-+ | 325 | | 326 |->->->-+ UO-0, UO-1* | 327 | +->->->->->->->-+ | 328 | +->->->-| D_TRANS = D 329 | | D_MODE= U 331 3.2. Feedback during mode transition 333 Section RFC3095-5.6.1 states that feedback is always used during mode 334 transitions. However, the text then continues by making concrete 335 applications of the rule in an inconsistent way, making it unclear 336 when CRCs are used. Further, the text does not define how the 337 compressor should act during mode transitions based on feedback not 338 protected by CRCs, i.e. whether to carry out mode transition actions 339 or not. The proper behavior from the compressor is to perform any 340 action related to mode transitions only when the feedback is 341 protected by the CRC option. 343 INCOMPLETE RFC 3095 TEXT (section RFC3095-5.6.1): 345 "As a safeguard against residual errors, all feedback sent during 346 a mode transition MUST be protected by a CRC, i.e., the CRC 347 option MUST be used." 349 CORRECTED TEXT: 351 "As a safeguard against residual errors, all feedback sent by the 352 decompressor during a mode transition MUST be protected by a CRC, 353 i.e., the CRC option MUST be used. The compressor MUST ignore 354 feedback information related to mode transition if the feedback 355 is not protected by the CRC option." 357 One more related issue that requires clarifications comes from the 358 following text at the end of section RFC3095-5.6.1: 360 "While D_TRANS is I, the decompressor sends a NACK or ACK carrying 361 a CRC option for each received packet." 363 However, Section RFC3095-5.5.2.2 already stated that for R-mode, 364 feedback is never sent for packets that do not update the context, 365 i.e. for packets that do not carry a CRC such as R-0 and R-1*. 367 This means that when D_TRANS=I during mode transition, a decompressor 368 operating in R-mode sends an acknowledgement for each packet it 369 receives and MUST use the sequence number that corresponds to the 370 packet that last updated the context, i.e. the decompressor MUST NOT 371 use the sequence number of the R-0 or the R-1* packet." 373 3.3. Packet decoding during mode transition 375 The purpose of a mode transition is to ensure that the compressor and 376 the decompressor coherently move from one mode of operation to 377 another using a three-way handshake. At one point during the mode 378 transition, the decompressor acknowledges the reception of one (or 379 more) IR, IR-DYN or UOR-2 packet(s) that have mode bits set to the 380 new mode. Packets of type 0 or 1 that are received up to this point 381 are decompressed using the old mode, while afterwards they are 382 decompressed using the new mode. If the enhanced transition 383 procedures described in section 3.1 are used, the setting of the 384 D_TRANS parameter to P represents this breakpoint. The successful 385 decompression of a packet of type 0 or type 1 completes the mode 386 transition. 388 4. Timestamp encoding 390 4.1. Encoding used for compressed TS bits 392 RTP Timestamp values (TS) are always encoded using W-LSB encoding, 393 both when sent scaled and when sent unscaled. When no TS bits are 394 transmitted in a compressed packet, TS is always scaled. If a 395 compressed packet carries an extension 3 and field(Tsc)=0, the 396 compressed packet must thus always carry unscaled TS bits. For TS 397 values sent in Extension 3, W-LSB encoded values are sent using the 398 self-describing variable-length format (section RFC3095-4.5.6), and 399 this applies to both scaled and unscaled values. 401 4.2. (De)compression of TS without transmitted TS bits 403 When ROHC RTP operates using its most efficient packet types, apart 404 from packet type identification and the error detection CRC, only RTP 405 sequence number (SN) bits are transmitted in RTP compressed headers. 406 All other fields are then omitted either because they are unchanged 407 or because they can be reconstructed through a function from the SN 408 (i.e. by combining the transmitted SN bits with state information 409 from the context). Fields that can be inferred from the SN are the IP 410 Identification (IP-ID) and the RTP Timestamp (TS). 412 IP-ID compression and decompression, both with and without 413 transmitted IP-ID bits in the compressed header, are well defined in 414 section RFC3095-4.5.5 (see section 8.2). For the TS field, however, 415 RFC 3095 only defines how to decompress based on actual TS bits in 416 the compressed header, either scaled or unscaled, but not how to 417 infer the TS from the SN when there are no TS bits present in the 418 compressed header. 420 When no TS bits are received in the compressed header, the scaled TS 421 value is reconstructed assuming a linear extrapolation from the SN, 422 i.e. delta_TS = delta_SN * default-slope, where delta_SN and delta_TS 423 are both signed integers. Section RFC3095-5.7 defines the potential 424 values for default-slope. 426 INCOMPLETE RFC 3095 TEXT (section RFC3095-5.7): 428 "If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before 429 compression (see section 4.5.3), and default-slope(TS) = 1. 431 If value(Tsc) = 0, the Timestamp value is compressed as-is, and 432 default-slope(TS) = value(TS_STRIDE)." 434 CORRECTED TEXT: 436 "When a compressed header with no TS bits is received, the scaled 437 TS value is reconstructed assuming a linear extrapolation from 438 the SN, i.e. delta_TS = delta_SN * default-slope(TS). 440 If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before 441 compression (see section 4.5.3), and default-slope(TS) = 1. 443 If value(Tsc) = 0, the Timestamp value is compressed as-is, and 444 default-slope(TS) = value(TS_STRIDE). If a packet with no TS bits 445 is received with Tsc=0, the decompressor MUST discard the 446 packet." 448 INCORRECT AND INVALIDATED RFC 3095 TEXT (section RFC3095-5.5.1.2): 450 "For example, in a typical case where the string pattern has the 451 form of non-SN-field = SN * slope + offset, one ACK is enough if 452 the slope has been previously established by the decompressor 453 (i.e., only the new offset needs to be synchronized). Otherwise, 454 two ACKs are required since the decompressor needs two headers to 455 learn both the new slope and the new offset." 457 Consequently, there is no other slope value than the default-slope, 458 as defined in section RFC3095-5.7. 460 4.3. Interpretation intervals for TS encoding 462 Section RFC3095-4.5.4 defines the interpretation interval, p, for 463 timer-based compression of the RTP timestamp. However, Section 464 RFC3095-5.7 defines a different interpretation interval, which is 465 defined as the interpretation interval to use for all TS values. It 466 is thus unclear which p-value to use, at least for timer-based 467 compression. 469 The way this should be interpreted is that the p-value differs 470 depending on whether timer-based compression is enabled or not. 472 For timer-based compression (TIME_STRIDE set to a non-zero value), 473 the interpretation interval is: 474 p = 2^(k-1) - 1 (as per section RFC3095-4.5.4) 475 Otherwise, the interpretation interval is: 476 p = 2^(k-2) - 1 (as per section RFC3095-5.7) 478 4.4. Scaled RTP timestamp encoding 480 This section redefines the algorithm for scaled RTP timestamp 481 encoding, defined as a 5-step procedure in section RFC3095-4.5.3. Two 482 formal errors have been corrected, as described in subsections 4.4.1 483 and 4.4.2 below, and the whole algorithm has been reworked to be more 484 concise and use well-defined terminology. The resulting text can be 485 found in 4.4.3 below. 487 4.4.1. TS_STRIDE for scaled timestamp encoding 489 RFC 3095 defines the timestamp stride (TS_STRIDE) as the expected 490 increase in the timestamp value between two RTP packets with 491 consecutive sequence numbers. TS_STRIDE is set by the compressor and 492 explicitly communicated to the decompressor, and it is used as the 493 scaling factor for scaled TS encoding. 495 The relation between TS and TS_SCALED, given by the following 496 equality in section RFC3095-4.5.3, defines the mathematical meaning 497 of TS_STRIDE: 499 TS = TS_SCALED * TS_STRIDE + TS_OFFSET 501 TS_SCALED is incompletely written as TS / TS_STRIDE in the 502 compression step following the above core equality. This formula is 503 incorrect both because it excludes TS_OFFSET and because it would 504 prevent a TS_STRIDE value of 0, which is an alternative not excluded 505 by the definition or by the core equality above. If "/" were a 506 generally unambiguously defined operation meaning "the integral part 507 of the result from dividing X by Y", the absence of TS_OFFSET could 508 be explained, but the formula would still lack a proper output for 509 TS_STRIDE equal to 0. The formula of "2. Compression" is thus valid 510 only with the following requirements: 512 a) "/" means "the integral part of the result from dividing X by Y" 513 b) TS_STRIDE>0 (TS is never sent scaled when TS_STRIDE=0) 515 4.4.2. TS wraparound with scaled timestamp encoding 517 Section RFC3095-4.5.3 states in point 4 and 5 that the compressor is 518 not required to initialize TS_OFFSET at wraparound, but that it is 519 required to increase the number of bits sent for the scaled TS value 520 when there is a TS wraparound. The decompressor is also required to 521 detect and cope with TS wraparound, including updating TS_OFFSET. 523 This method is not interoperable and not robust. The gain is also 524 insignificant, as TS wraparound happens very seldom. Therefore, the 525 compressor should reinitialize TS_OFFSET upon TS wraparound, by 526 sending unscaled TS. 528 4.4.3. Algorithm for scaled timestamp encoding 530 INCORRECT RFC 3095 TEXT (section RFC3095-4.5.3): 532 "1. Initialization: The compressor sends to the decompressor the 533 value of TS_STRIDE and the absolute value of one or several TS 534 fields. The latter are used by the decompressor to initialize 535 TS_OFFSET to (absolute value) modulo TS_STRIDE. Note that 536 TS_OFFSET is the same regardless of which absolute value is 537 used, as long as the unscaled TS value does not wrap around; 538 see 4) below. 540 2. Compression: After initialization, the compressor no longer 541 compresses the original TS values. Instead, it compresses the 542 downscaled values: TS_SCALED = TS / TS_STRIDE. The 543 compression method could be either W-LSB encoding or the 544 timer-based encoding described in the next section. 546 3. Decompression: When receiving the compressed value of 547 TS_SCALED, the decompressor first derives the value of the 548 original TS_SCALED. The original RTP TS is then calculated as 549 TS = TS_SCALED * TS_STRIDE + TS_OFFSET. 551 4. Offset at wraparound: Wraparound of the unscaled 32-bit TS 552 will invalidate the current value of TS_OFFSET used in the 553 equation above. For example, let us assume TS_STRIDE = 160 = 554 0xA0 and the current TS = 0xFFFFFFF0. TS_OFFSET is then 0x50 555 = 80. Then if the next RTP TS = 0x00000130 (i.e., the 556 increment is 160 * 2 = 320), the new TS_OFFSET should be 557 0x00000130 modulo 0xA0 = 0x90 = 144. The compressor is not 558 required to re-initialize TS_OFFSET at wraparound. Instead, 559 the decompressor MUST detect wraparound of the unscaled TS 560 (which is trivial) and update TS_OFFSET to 561 TS_OFFSET = (Wrapped around unscaled TS) modulo TS_STRIDE" 563 CORRECTED TEXT: 565 "1. Initialization and updating of RTP TS scaling function: 566 The compressor sends to the decompressor the value of 567 TS_STRIDE along with an unscaled TS. These are both needed by 568 the decompressor to initialize TS_OFFSET as hdr(TS) modulo 569 field(TS_STRIDE). Note that TS_OFFSET is the same for any TS 570 as long as TS_STRIDE does not change and as long as the 571 unscaled TS value does not wrap around; see 4) below. 573 2. Compression: After initialization, the compressor no longer 574 compresses the unscaled TS values. Instead, it compresses the 575 scaled values. The compression method can be either W-LSB 576 encoding or timer-based encoding. 578 3. Decompression: When receiving a (compressed) TS_SCALED, the 579 field is first decompressed, and the unscaled RTP TS is then 580 calculated as TS = TS_SCALED * TS_STRIDE + TS_OFFSET. 582 4. Offset at wraparound: If the value of TS_STRIDE is not equal 583 to a power of two, wraparound of the unscaled 32-bit TS will 584 change the value of TS_OFFSET. When this happens, the 585 compressor SHOULD reinitialize TS_OFFSET by sending unscaled 586 TS, as in 1 above." 588 INCORRECT AND INVALIDATED RFC 3095 TEXT (section RFC3095-4.5.3): 590 The entire point 5, i.e. the entire text starting from "5. 591 Interpretation interval at wraparound ...", down to and including 592 the block of text that starts with "Let a be the number of LSBs" 593 and that ends with "...interpretation interval is b." is incorrect 594 and is thus invalid. 596 4.5. Recalculating TS_OFFSET 598 TS can be sent unscaled if the TS value change does not match the 599 established TS_STRIDE, but the TS_STRIDE might still stay unchanged. 600 To ensure correct decompression of subsequent packets, the 601 decompressor MUST therefore always recalculate TS_OFFSET (RTP TS 602 modulo TS_STRIDE) when a packet with an unscaled TS value is 603 received. 605 4.6. TS_STRIDE and the Tsc flag in Extension 3 607 The Tsc flag in Extension 3 indicates whether TS is scaled or not. 608 The value of the Tsc flag thus applies to all TS bits, also if there 609 are no TS bits in the extension itself. When TS is scaled, it is 610 always scaled using context(TS_STRIDE). The legend for Extension 3 in 611 section RFC3095-5.7.5 incorrectly states that value(TS_STRIDE) is 612 used for scaled TS, which is incorrect. 614 If TS_STRIDE is present in Extension 3, as indicated by the Tss flag 615 being set, the compressed header SHOULD carry unscaled TS bits, i.e. 616 the Tsc flag SHOULD NOT be set when Tss is set since an unscaled TS 617 is needed together with TS_STRIDE to recalculate the TS_OFFSET. If 618 TS_STRIDE is included in a compressed header with scaled TS, the 619 decompressor must ignore and discard field(TS_STRIDE). 621 INCORRECT RFC 3095 TEXT (section RFC3095-5.7.5): 623 "Tsc: Tsc = 0 indicates that TS is not scaled; 624 Tsc = 1 indicates that TS is scaled according to section 625 4.5.3, using value(TS_STRIDE). 626 Context(Tsc) is always 1. If scaling is not desired, the 627 compressor will establish TS_STRIDE = 1." 629 CORRECTED TEXT: 631 "Tsc: Tsc = 0 indicates that TS is not scaled; 632 Tsc = 1 indicates that TS is scaled according to section 633 4.5.3, using context(TS_STRIDE). 635 Context(Tsc) is always 1. If scaling is not desired, the 636 compressor will establish TS_STRIDE = 1. 638 If field(Tsc) = 1, and if TSS = 1 (meaning that TS_STRIDE is 639 present in the extension), field(TS_STRIDE) MUST be ignored 640 and discarded." 642 When the compressor re-establishes a new value for TS_STRIDE using 643 Extension-3, it should send unscaled TS bits together with TS_STRIDE. 645 4.7. Using timer-based compression 647 Timer-based compression of the RTP timestamp, as described in section 648 RFC3095-4.5.4, may be used to reduce the number of transmitted 649 timestamp bits (bytes) needed when the timestamp can not be inferred 650 from the SN. Timer-based compression is only used for decompression 651 of compressed headers that contains a TS field, otherwise when no 652 timestamp bits are present the timestamp is linearly inferred from 653 the SN (see section 4.2 of this document). 655 Whether to use timer-based compression or not is controlled by the 656 TIME_STRIDE control field, which can be set either by an IR, an IR- 657 DYN, or by a compressed packet with extension 3. Before timer-based 658 compression can be used, the decompressor has to inform the 659 compressor (on a per-channel basis) about its clock resolution by 660 sending a CLOCK feedback option for any CID on the channel. The 661 compressor can then initiate timer-based compression by sending (on a 662 per-context basis) a non-zero TIME_STRIDE to the decompressor. When 663 the compressor is confident that the decompressor has received the 664 TIME_STRIDE value, it can switch to timer-based compression. 666 5. List compression 668 5.1. CSRC list items in RTP dynamic chain 670 Section RFC3095-5.7.7.6 defines the static and dynamic parts of the 671 RTP header. This section indicates a 'Generic CSRC list' field in the 672 dynamic chain, which has a variable length (see section RFC3095- 673 5.8.6). This field is always at least one octet in size, even if the 674 list is empty (as opposed to the CSRC list in the uncompressed RTP 675 header, which is not present when the RTP CC field is set to 0). 677 5.2. Multiple occurrences of the CC field 679 The static and the dynamic parts of the RTP header are defined in 680 section RFC3095-5.7.7.6. In the dynamic part, a CC field indicates 681 the number of CSRC items present in the 'Generic CSRC list'. Another 682 CC field also appears within the 'Generic CSRC list' (section 683 RFC3095-5.8.6.1), because Encoding Type 0 is always used in the 684 dynamic chain. Both CC fields have the same meaning: the value of the 685 CC field determines the number of XI items in the CSRC list for 686 Encoding Type 0, and it is not used otherwise. Therefore, the 687 following applies: 689 FORMAL ADDITION TO RFC 3095: 691 "The first octet in the dynamic part of the RTP header contains a 692 CC field, as defined in section 5.7.7.6. A second occurrence 693 appears in the 'Generic CSRC list', which is also in the dynamic 694 part of the RTP header, where Encoding Type 0 is used according 695 to the format defined in RFC3095-5.8.6.1. 697 The compressor MUST set both occurrences of the CC field to the 698 same value. 700 The decompressor MUST use the value of the CC field from the 701 Encoding Type 0 within the Generic CRSC list, and it MUST thus 702 ignore the first occurrence of the CC field." 704 5.3. Bit masks in list compression 706 The insertion and/or removal schemes, described in sections RFC3095- 707 5.8.6.2 - 5.8.6.4, use bit masks to indicates insertion or removal 708 positions within the reference list. The size of the bit mask can be 709 7-bit or 15-bit. 711 The compressor MAY use a 7-bit mask, even if the reference list has 712 more than 7 items, provided that changes to the list are only applied 713 to items within the first 7 items of the reference list, leaving 714 items with an index not covered by the 7-bit mask unchanged. 716 The decompressor MUST NOT modify items with an index not covered by 717 the 7-bit mask, when a 7-bit mask is received for a reference list 718 that contains more than 7 items. 720 5.4. Headers compressed with list compression 722 In section RFC3095-5.8, it is stated that headers which can be part 723 of extension header chains "include" AH [14], ESP NULL [13], minimal 724 encapsulation (MINE) [15], GRE [16][17], and IPv6 [9] extensions. 725 This list of headers which can be compressed is correct, but the word 726 "include" should not be there, since only the header types listed can 727 actually be handled. It should further be noted that for the Minimal 728 Encapsulation (MINE) header, there is no explicit discussion of how 729 to compress it, as the header is either sent uncompressed or fully 730 compressed away. 732 5.5. ESP NULL header list compression 734 Due to the offset of the fields in the trailer part of the ESP 735 header, a compressor MUST NOT compress packets containing more than 736 one NULL ESP [13] header, unless the second-outermost header is 737 treated as a regular ESP [12] header and the packets are compressed 738 using profile 0x0003. 740 5.6. Translation tables and indexes for IP extension headers 742 Section RFC3095-5.8.4 describes how list indexes are associated to 743 list items and how table lists are built for IP extension headers. 744 The text incorrectly states that one index per type is used, since 745 the same type can appear several times with different content in one 746 single chain. 748 In IP extension header list compression, an index is associated with 749 each individual extension header of an extension header chain. When 750 there are multiple non-identical occurrences of the same extension 751 type (Protocol Number) within a header chain, each MUST be given its 752 own index. 754 In the case where there are multiple identical occurrences of the 755 same extension type, the compressor can associate them to the same 756 index. When the value of an item whose index occurs more than once in 757 the list is updated, the compressor MUST send the value for each 758 occurrence of that index in the list. 760 When content of extension headers changes, an implementation can 761 choose to either use a different index, or update the existing one. 762 Some extensions can be compressed away even when some fields change, 763 as those changes can be conveyed to the decompressor implicitly (e.g. 764 sequence numbers in extension headers that can be inferred from the 765 RTP SN) or explicitly (e.g. as part of the 'IP extension header(s)' 766 field in extension 3). 768 When there is more than one IP header, there is more than one list of 769 extension headers, and a translation table is maintained for each 770 list independently of one another. 772 5.7. Reference list 774 A list compressed using encoding type 1 (insertion), type 2 (removal) 775 or type 3 (removal/insertion) uses a coding scheme that is based on 776 the use of a reference list in the context (identified as ref_id). 778 While it could seem a fair choice to send a type 1 list when ref_id 779 is an empty list, there is no gain in doing so with respect to using 780 a type 0 list. Sending a type 2 list when ref_id is an empty list 781 would lead to a failure, while sending a type 3 list has very little 782 meaning. All these alternatives could be seen as possible, based on 783 how list compression is specified in RFC 3095. 785 If these alternatives were allowed, a decompressor would become 786 required to maintain a sliding window of ref_id lists in R-mode, even 787 for the case where no items are sent in the compressed list, and this 788 is not a desirable requirement. Using list encoding type 1, type 2, 789 and type 3 is therefore only allowed for non-empty reference lists. 791 FORMAL ADDITION TO RFC 3095: 793 "Regardless of the operating mode, for list encoding of type 1, 794 type 2, and type 3 lists, ref_id MUST refer to a non-empty list." 796 5.8. Compression of AH and GRE sequence numbers 798 Section RFC3095-5.8.4.2 and section RFC3095-5.8.4.4 describes how to 799 compress the Authentication Header (AH) [14] and the Generic Routing 800 Encapsulation (GRE) [16][17] header. Both these sections present a 801 possibility to omit the AH/GRE sequence number in the compressed 802 header, under certain circumstances. However, the specific conditions 803 for omitting the AH/GRE sequence number, as well as the concrete 804 compression and decompression procedures to apply, are not clearly 805 defined to guarantee robustness and facilitate interoperable 806 implementation. 808 Proper rules are provided for the ESP case, i.e.: 810 "Sequence Number: Not sent when the offset from the sequence 811 number of the compressed header is constant, when the compressor 812 has confidence that the decompressor has established the correct 813 offset. When the offset is not constant, the sequence number may 814 be compressed by sending LSBs" 816 The same logic applies to the AH/GRE sequence numbers. 818 INCORRECT RFC 3095 TEXT (section RFC3095-5.8.4.2): 820 "If the sequence number in the AH linearly increases as the RTP 821 Sequence Number increases, and the compressor is confident that 822 the decompressor has obtained the pattern, the sequence number in 823 AH need not be sent. The decompressor applies linear 824 extrapolation to reconstruct the sequence number in the AH." 826 CORRECTED TEXT: 828 "The AH sequence number can be omitted from the compressed header 829 when the offset from the sequence number (SN) of the compressed 830 header is constant, when the compressor has confidence that 831 the decompressor has established the correct offset." 833 INCORRECT RFC 3095 TEXT (section RFC3095-5.8.4.4): 835 "If the sequence number in the GRE header linearly increases as 836 the RTP Sequence Number increases and the compressor is confident 837 that the decompressor has received the pattern, the sequence 838 number in GRE need not be sent. The decompressor applies linear 839 extrapolation to reconstruct the sequence number in the GRE 840 header." 842 CORRECTED TEXT: 844 "The GRE sequence number can be omitted from the compressed header 845 when the offset from the sequence number (SN) of the compressed 846 header is constant, when the compressor has confidence that the 847 decompressor has established the correct offset." 849 6. Updating properties 851 6.1. Implicit updates 853 A context updating packet that contains compressed sequence number 854 information may also carry information about other fields; in such 855 cases, these fields are updated according to the content of the 856 packet. The updating packet also implicitly updates inferred fields 857 (e.g. RTP timestamp) according to the current mode and the 858 appropriate mapping function of the updated and the inferred fields. 860 An updating packet thus updates the reference values of all header 861 fields, either explicitly or implicitly, except for the UO-1-ID 862 packet (see section 6.2 of this document). In UO-mode, all packets 863 are updating packets, while in R-mode all packets with a CRC are 864 updating packets. 866 For example, a UO-0 packet contains the compressed RTP sequence 867 number (SN). Such a packet also implicitly updates RTP timestamp, 868 IPv4 ID, and sequence numbers of IP extension headers. 870 6.2. Updating properties of UO-1* 872 Section RFC3095-5.7.3 states that the values provided in extensions 873 carried by a UO-1-ID packet do not update the context, except for SN, 874 TS, or IP-ID fields. However, section RFC3095-5.8.1 correctly states 875 that the translation table in the context is updated whenever an 876 (Index, item) pair is received, something that is contradicted by the 877 statement in RFC3095-5.7.3 because the UO-1-ID packet can carry 878 extension 3 with (Index, item) pair items within the 'Compressed CSRC 879 list' field. In addition to this contradiction, the text does not 880 mention what to do with the other sequence numbers inferred from the 881 SN, which are also to be implicitly updated. The updating properties 882 of UO-1* as stated by section RFC3095-5.7.3 are thus incomplete. 884 INCOMPLETE RFC 3095 TEXT (section RFC3095-5.7.3): 886 "Values provided in extensions, except those in other SN, TS, 887 or IP-ID fields, do not update the context." 889 CORRECTED TEXT: 891 "UO-1-ID packets only updates TS, SN, IP-ID, and sequence 892 numbers of IP extension headers. Other values 893 provided in extensions do not update the context. 895 The decompressor MUST update its translation table whenever an 896 (Index, item) pair is received, as per Section RFC3095-5.8.1, 897 and this rule applies also to UO-1-ID packets." 899 6.3. Context updating properties for IR packets 901 IR packets do not clear the whole context, but update all fields 902 carried in the IR header. Similarly, an IR without a dynamic chain 903 simply updates the static part of the context, while the rest of the 904 context is left unchanged. 906 A consequence of this is that fields that are not updated by the IR 907 packet, e.g. the translation tables for list compression, MUST NOT be 908 invalidated by the decompressor when it assumes context damage. 910 6.4. RTP padding field (R-P) in extension 3 912 Section RFC3095-5.7.5 defines the properties of RTP header flags and 913 fields in extension 3. These get updated when the rtp flag of the 914 extension 3 is set, i.e. when rtp = 1, otherwise they are not 915 updated. However, it is unclear how extension 3 updates the R-P bit 916 in the context. 918 INCOMPLETE RFC 3095 TEXT (section RFC3095-5.7.5): 920 "R-P: RTP Padding bit, absolute value (presumed zero if absent)." 922 CORRECTED TEXT: 924 "R-P: RTP Padding bit. If R-PT = 1, R-P is the absolute value of 925 the RTP padding bit and this value updates context(R-P). If 926 R-PT = 0, context(R-P) is updated to zero." 928 6.5. RTP eXtension bit (X) in dynamic part 930 Section RFC3095-5.7.7.6 defines the properties of the RTP header 931 flags and fields in the RTP part of the dynamic chain of IR and IR- 932 DYN packets. However, it is unclear how the X bit is updated in the 933 context. 935 INCOMPLETE RFC 3095 TEXT (section RFC3095-5.7.7.6): 937 "X: Copy of X bit from RTP header (presumed 0 if RX = 0)" 939 CORRECTED TEXT: 941 "X: X bit from RTP header. If RX = 1, X is the X bit from the RTP 942 header and this value updates context(X). If RX = 0, 943 context(X) is updated to zero." 945 7. Context management and CID/context re-use 947 7.1. Persistence of decompressor contexts 949 As part of the negotiated channel parameters, compressor and 950 decompressor have through the MAX_CID parameter agreed on the highest 951 context identification (CID) number to be used. By agreeing on 952 MAX_CID, the decompressor also agrees to provide memory resources to 953 host at least MAX_CID+1 contexts, and an established context with a 954 CID within this negotiated space MUST be kept by the decompressor 955 until either the CID gets re-used, or the channel is taken down or 956 re-negotiated. 958 7.2. CID/context re-use 960 As part of the channel negotiation, the maximal number of active 961 contexts supported is negotiated between the compressor and the 962 decompressor through the MAX_CID parameter. The value of MAX_CID can 963 differ significantly from one link application to another, as well as 964 the load in terms of the number of packet streams to compress. The 965 lifetime of a ROHC channel can also vary, from almost permanent to 966 rather short-lived. However, in general it is not expected that 967 resources will be allocated for more contexts than what can 968 reasonably be expected to be active concurrently over the link. As a 969 consequence hereof, context identifiers (CIDs) and context memory are 970 resources that will have to be re-used by the compressor as part of 971 what can be considered normal operation. 973 How context resources are re-used is left unspecified in RFC 3095 [1] 974 and subsequent 3095-based ROHC specifications. This document does not 975 intends to change that, i.e. ROHC resource management is still 976 considered an implementation detail. However, re-using a CID and its 977 allocated memory is not always as simple as initiating a context with 978 a previously unused CID. Because some profiles can be operating in 979 various modes where packet formats vary depending on current mode, 980 care has to be taken to ensure that the old context data will be 981 completely and safely overwritten, eliminating the risk of undesired 982 side effects from interactions between old and new context data. This 983 document therefore points out some important core aspects to consider 984 when implementing resource management in ROHC compressors and 985 decompressors. 987 On a high level, CID/context re-use can be of two kinds, either re- 988 use for a new context based on the same profile as the old context, 989 or for a new context based on a different profile. These cases, are 990 discussed separately in the following two subsections. 992 7.2.1. Re-using a CID/context with the same profile 994 For multi-mode profiles, such as those defined in RFC 3095 [1], mode 995 transitions are performed using a decompressor-initiated handshake 996 procedure, as defined in section RFC3095-5.6. When a CID/context is 997 re-used for a new context based on the same profile as the old 998 context, the current mode of operation SHOULD be inherited from the 999 old to the new context. Specifically, the compressor SHOULD continue 1000 to operate using the mode of operation of the old context also with 1001 the new context. The reason for this is that there is no reliable way 1002 for the compressor to inform the decompressor that a CID/context re- 1003 use is happening. The decompressor can thus not be expected to clear 1004 the context memory for the CID (see section 6.3), and there is no way 1005 to trigger a safe mode switching (which requires the decompressor- 1006 initiated handshake procedure). 1008 The rule of mode inheritance applies also when the 1009 CONTEXT_REINITIALIZATION signal (section RFC3095-6.3.1) is used to 1010 reinitiate an entire context. 1012 7.2.2. Re-using a CID/context with a different profile 1014 When a CID is re-used for a new context based on a different profile 1015 than the old context, both the compressor and the decompressor MUST 1016 start operation with that context in the initial mode of the profile 1017 (if it is a multi-mode profile). This applies both to IR-initiated 1018 new contexts and profile downgrades with IR-DYN (e.g. the profile 1019 0x0001 -> profile 0x0002 downgrade in section RFC3095-5.11.1). 1021 Type 0 and type 1 packets have different formats in U/O- and R-mode, 1022 and these R-mode packets have no CRC. When initiating a new context 1023 on a re-used R-mode CID, there is a risk that the decompressor will 1024 misinterpret compressed packets, if the initiating IR packets are 1025 lost. 1027 A CID for a context currently operating in R-mode SHOULD therefore 1028 not be re-used for a new context based on a different profile than 1029 the old context. A compressor doing otherwise should minimize the 1030 risk for misinterpretation of R-0/R-1 by e.g. not using packets of 1031 types beginning with 00 or 10 before it is highly confident that the 1032 new context has successfully been initiated at the decompressor. 1034 8. Other protocol clarifications 1036 8.1. Meaning of NBO 1038 In IPv4 dynamic part (section RFC3095-5.7.7.4), if the 'NBO' bit is 1039 set, it means that network byte order is used. 1041 8.2. IP-ID 1043 According to section RFC3095-5.7, IP-ID means the compressed value of 1044 the IPv4 header's 'Identification' field. Compressed packets contain 1045 this compressed value (IP-ID), while IR packets with dynamic chain 1046 and IR-DYN packets transmit the original, uncompressed Identification 1047 field value. The IP-ID field always represents the Identification 1048 value of the innermost IPv4 header whose corresponding RND flag is 1049 not 1. 1051 If RND or RND2 is set to 1, the corresponding IP-ID(s) is(are) sent 1052 as 16-bit uncompressed Identification value(s) at the end of the 1053 compressed base header, according to the IP-ID description (see the 1054 beginning of section RFC3095-5.7). When there is no compressed IP-ID, 1055 i.e. for IPv6 or when all IP Identification information is sent as-is 1056 (as indicated by RND/RND2 being set to 1), the decompressor ignores 1057 IP-ID bits sent within compressed base headers. 1059 When RND=RND2=0, IP-ID is compressed, i.e. expressed as an SN offset 1060 and byte-swapped if NBO=0. This is the case also when 16 bits of IP- 1061 ID is sent in extension 3. 1063 When RND=0 but no IP-ID bits are sent in the compressed header, the 1064 SN offset for IP-ID stays unchanged, meaning that Offset_m equals 1065 Offset_ref, as described in Section 4.5.5. This is further expressed 1066 in a slightly different way (with the same meaning) in Section 5.7, 1067 where it is said that "default-slope(IP-ID offset) = 0", meaning that 1068 if no bits are sent for IP-ID, its SN offset slope defaults to 0. 1070 8.3. Extension-3 in UOR-2* packets 1072 Some flags of the IP header in the extension (e.g. NBO or RND) may 1073 change the interpretation of fields in UOR-2* packets. In such cases, 1074 when a flag changes in Extension-3, a decompressor MUST re-parse the 1075 UOR-2* packet. 1077 8.4. Multiple occurrences of the M bit 1079 The RTP header part of Extension 3, as defined by section RFC3095- 1080 5.7.5, includes a one-bit field for the RTP Marker bit. This field is 1081 also present in all compressed base header formats except for UO-1- 1082 ID, meaning there may be two occurrences of the field within one 1083 single compressed header. In such cases, the two M fields must have 1084 the same value. 1086 FORMAL ADDITION TO RFC 3095: 1088 "When there are two occurrences of the M field in a compressed 1089 header (both in the compressed base header and in the RTP part of 1090 Extension 3), the compressor MUST set both these occurrences of 1091 the M field to the same value. 1093 At the decompressor, if the two M field values of such a packet 1094 are not identical, the packet MUST be discarded." 1096 8.5. Multiple SN options in one feedback packet 1098 The length of the sequence number field in the original ESP [12] 1099 header is 32 bits. The format of the SN feedback option (section 1100 RFC3095-5.7.6.6) allows for 8 additional SN bits to the 12 SN bits of 1101 the FEEDBACK-2 format (section RFC3095-5.7.6.1). One single SN 1102 feedback option is thus not enough for the decompressor to send back 1103 all the 32 bits of the ESP sequence number in a feedback packet, 1104 unless it uses multiple SN options in one feedback packet. Section 1105 RFC3095-5.7.6.1 declares that a FEEDABCK-2 packet can contain 1106 variable number of feedback options and the options can appear in any 1107 order. 1109 When processing multiple SN options in one feedback packet, the SN 1110 would be given by concatenating the fields. 1112 8.6. Multiple CRC options in one feedback packet 1114 Although it is not useful to have more than one single CRC option in 1115 a feedback packet, having multiple CRC options is still allowed. If 1116 multiple CRC options are included, all such CRC options MUST be 1117 identical, as they will be calculated over the same header, the 1118 compressor MUST otherwise discard the feedback packet. 1120 8.7. Responding to lost feedback links 1122 Although this is neither desirable or expected, it may happen that a 1123 link used to carry feedback between two associated instances becomes 1124 unavailable. If the compressor can be notified of such event, the 1125 compressor SHOULD restart compression for each flow that is operating 1126 in R-mode. When restarting compression, the compressor SHOULD use a 1127 different CID for each flow being restarted; this is useful to avoid 1128 that packet types for which both U/O-mode and R-mode share the same 1129 type identifier gets misinterpreted when restarting the flow in U- 1130 mode (see also section 7.2). 1132 Generally, feedback links are not expected to disappear when once 1133 present, but it should be noted that this might be the case for 1134 certain link technologies. 1136 8.8. UOR-2 in profile 0x0002 (UDP) and profile 0x0003 (ESP) 1138 One single new format is defined for UOR-2 in profile 0x0002 and 1139 profile 0x0003, which replaces all three (UOR-2, UOR-2-ID, UOR-2-TS) 1140 formats from profile 0x0001. The same UOR-2 format is thus used 1141 independent of whether there are IP headers with a corresponding 1142 RND=1 or not. This also applies to the IP profile [4] and the IP/UDP- 1143 Lite profile [5]. 1145 8.9. Sequence number LSB's in IP extension headers 1147 In section RFC3095-5.8.5, formats are defined for compression of IP 1148 extension header fields. These include compressed sequence number 1149 fields, and these fields contain "LSB of sequence number". These 1150 sequence numbers are not "LSB-encoded" as e.g. the RTP sequence 1151 number, but are the LSB's of the uncompressed fields. 1153 8.10. Expecting UOR-2 ACKs in O-mode 1155 Usage of UOR-2 ACKs in O-mode, as discussed in section RFC3095- 1156 5.4.1.1.2, is optional. A decompressor can also send ACKs for 1157 purposes other than to acknowledge the UOR-2, without having to 1158 continue sending ACKs for all UOR-2. Similarly, a compressor 1159 implementation can ignore UOR-2 ACKs for the purpose of adapting the 1160 optimistic approach strategies. 1162 It is thus NOT RECOMMENDED to use of the optional ACK mechanism in 1163 O-mode, neither in compressor nor in decompressor implementations. 1165 Using an incorrect expectation on UOR-2 ACKs as a basis for 1166 compressor behavior will significantly degrade the compression 1167 performance. This is because UOR-2 ACKs can be sent from a 1168 decompressor for other purposes than to acknowledge the UOR-2 packet, 1169 e.g. to send feedback such as clock resolution, or to initiate a mode 1170 transition. If an implementation does use the optional acknowledgment 1171 algorithm described in Section 5.4.1.1.2, it must make sure to set 1172 the k_3 and n_3 parameters to much larger values than one to ensure 1173 that the compressor performance is not degraded due to the problem 1174 described above. 1176 8.11. Context repairs, TS_STRIDE and TIME_STRIDE 1178 The 7-bit CRC used to verify the outcome of the decompression attempt 1179 covers the original uncompressed header. The CRC verification thus 1180 excludes TS_STRIDE and TIME_STRIDE, as these fields are not part of 1181 the original uncompressed header. 1183 The UOR-2 packet type can be used to update the value of the 1184 TS_STRIDE and/or the TIME_STRIDE, with the extension 3. However, 1185 these fields are not used for decompression of the RTP TS field for 1186 this packet type and their respective value is thus not verified, 1187 either implicitly or explicitly. 1189 When the compressor receives a negative acknowledgement, it can thus 1190 not determine if the failure may be caused by an unsuccessful update 1191 to the TS_STRIDE and/or the TIME_STRIDE field(s), for which a 1192 previous header that last attempted to update their value had 1193 previously been acknowledged. 1195 FORMAL ADDITION TO RFC 3095: 1197 "When the compressor receives a NACK and uses the UOR-2 header 1198 type to repair the decompressor context, it SHOULD include fields 1199 that update the value of both the TS_STRIDE and the TIME_STRIDE 1200 whose value it has updated at least once since the establishment 1201 of that context, i.e. since the CID was first associated with its 1202 current profile. 1204 When the compressor receives a static-NACK, it MUST include in 1205 the IR header fields for both the TS_STRIDE and the TIME_STRIDE 1206 whose value it has updated at least once since the establishment 1207 of that context, i.e. since the CID was first associated with its 1208 current profile." 1210 9. ROHC negotiation 1212 Section RFC3095-4.1 states that the link layer must provide means to 1213 negotiate e.g. the channel parameters listed in section RFC3095- 1214 5.1.1. One of these parameters is the PROFILES parameter, which is a 1215 set of non-negative integers where each integer indicates a profile 1216 supported by the decompressor. 1218 Each profile is identified by a 16-bit value, where the 8 LSB bits 1219 indicate the actual profile, and the 8 MSB bits indicate the variant 1220 of that profile (see chapter RFC3095-8). In the ROHC headers sent 1221 over the link, the profile used is identified only with the 8 LSB 1222 bits, which means that the compressor and decompressor must have 1223 agreed on which variant to use for each profile. 1225 The negotiation protocol must thus be able to communicate to the 1226 compressor the set of profiles supported by the decompressor, and 1227 when multiple variants of the same profile are available, also 1228 provide means for the decompressor to know which variant will be used 1229 by the compressor. This basically means that the PROFILES set after 1230 negotiation MUST NOT include more than one variant of a profile. 1232 10. PROFILES suboption in ROHC-over-PPP 1234 The logical union of suboptions for IPCP and IPV6CP negotiations, as 1235 specified by ROHC over PPP [2], can not be used for the PROFILES 1236 suboption, as the whole union would then have to be considered within 1237 each of the two IPCP negotiations, to avoid getting an ambiguous 1238 profile set. An implementation of RFC 3241 MUST therefore ensure the 1239 same profile set is negotiated for both IPv4 and IPv6 (IPCP/IPV6CP). 1241 11. Constant IP-ID encoding in IP-only and UPD-Lite profiles 1243 In the ROHC IP-only profile, section 3.3 of RFC 3843 [4], a mechanism 1244 for encoding of a constant Identification value in IPv4 (constant IP- 1245 ID) is defined. This mechanism is also used by the ROHC UDP-Lite 1246 profiles, RFC 4019 [5]. 1248 The "Constant IP-ID" mechanism applies to both the inner and the 1249 outer IP header, when present, meaning that there will be both a SID 1250 and a SID2 context value. 1252 12. Security considerations 1254 This document provides a number of corrections and clarifications to 1255 [1], but it does not make any changes with regards to the security 1256 aspects of the protocol. As a consequence, the security 1257 considerations of [1] apply without additions. 1259 13. IANA considerations 1261 This document does not require any IANA actions. 1263 14. Acknowledgment 1265 The authors would like to thank Vicknesan Ayadurai, Carsten Bormann, 1266 Mikael Degermark, Zhigang Liu, Abigail Surtees, Mark West, Tommy 1267 Lundemo, Alan Kennington, Remi Pelland, Lajos Zaccomer, Endre Szalai, 1268 Mark Kalmanczhelyi, and Arpad Szakacs for their contributions and 1269 comments. Thanks also to the committed document reviewers, Carl 1270 Knutsson and Biplab Sarkar, who reviewed the document during working 1271 group last-call. 1273 15. References 1275 15.1. Normative References 1277 [1] C. Bormann, et al., "RObust Header Compression (ROHC): Framework 1278 and four profiles: RTP, UDP, ESP, and uncompressed", 1279 RFC 3095, July 2001. 1281 [2] C. Bormann, "Robust Header Compression (ROHC) over PPP", 1282 RFC 3241, April 2002. 1284 [3] W. Simpson, "PPP in HDLC-like Framing", RFC 1662, July 1994. 1286 [4] L-E. Jonsson & G. Pelletier, "RObust Header Compression (ROHC): 1287 A Compression Profile for IP", RFC 3843, June 2004. 1289 [5] G. Pelletier, "RObust Header Compression (ROHC): Profiles for 1290 User Datagram Protocol (UDP) Lite", RFC 4019, April 2005. 1292 [6] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1293 Levels", BCP 14, RFC 2119, March 1997. 1295 15.2. Informative References 1297 [7] L-E. Jonsson, G. Pelletier & K. Sandlund, "RObust Header 1298 Compression (ROHC): A Link-Layer Assisted Profile for 1299 IP/UDP/RTP", RFC 4362, June 2004. 1301 [8] J. Postel, "Internet Protocol", STD 5, RFC 791, September 1981. 1303 [9] S. Deering & R. Hinden, "Internet Protocol, Version 6 (IPv6) 1304 Specification", RFC 2460, December 1998. 1306 [10] J. Postel, "User Datagram Protocol", STD 6, RFC 768, August 1307 1980. 1309 [11] H. Schulzrinne, S. Casner, R. Frederick & V. Jacobson, "RTP: A 1310 Transport Protocol for Real-Time Applications", RFC 1889, 1311 January 1996. 1313 [12] S. Kent & R. Atkinson, "IP Encapsulating Security Payload", RFC 1314 2406, November 1998. 1316 [13] R. Glenn & S. Kent, "The NULL Encryption Algorithm and Its Use 1317 With IPsec", RFC 2410, November 1998. 1319 [14] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 1320 November 1998. 1322 [15] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 1323 October 1996. 1325 [16] D. Farinacci, T. Li, S. Hanks, D. Meyer & P. Traina, "Generic 1326 Routing Encapsulation (GRE)", RFC 2784, March 2000. 1328 [17] G. Dommety, "Key and Sequence Number Extensions to GRE", RFC 1329 2890, August 2000. 1331 16. Authors' Addresses 1333 Lars-Erik Jonsson 1334 Ericsson AB 1335 Box 920 1336 SE-971 28 Lulea, Sweden 1337 Phone: +46 8 404 29 61 1338 EMail: lars-erik.jonsson@ericsson.com 1340 Kristofer Sandlund 1341 Ericsson AB 1342 Box 920 1343 SE-971 28 Lulea, Sweden 1344 Phone: +46 8 404 41 58 1345 EMail: kristofer.sandlund@ericsson.com 1347 Ghyslain Pelletier 1348 Ericsson AB 1349 Box 920 1350 SE-971 28 Lulea, Sweden 1351 Phone: +46 8 404 29 43 1352 EMail: ghyslain.pelletier@ericsson.com 1354 Peter Kremer 1355 Conformance and Software Test Laboratory 1356 Ericsson Hungary 1357 H-1300 Bp. 3., P.O. Box 107, HUNGARY 1358 Phone: +36 1 437 7033 1359 EMail: peter.kremer@ericsson.com 1361 Appendix A - Sample CRC algorithm 1363 #!/usr/bin/perl -w 1364 use strict; 1365 #================================= 1366 # 1367 # ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02 1368 # 1369 # This little demo shows the four types of CRC in use in RFC 3095, 1370 # the specification for robust header compression. Type your data in 1371 # hexadecimal form and then press Control+D. 1372 # 1373 #--------------------------------- 1374 # 1375 # utility 1376 # 1377 sub dump_bytes($) { 1378 my $x = shift; 1379 my $i; 1380 for ($i = 0; $i < length($x); ) { 1381 printf("%02x ", ord(substr($x, $i, 1))); 1382 printf("\n") if (++$i % 16 == 0); 1383 } 1384 printf("\n") if ($i % 16 != 0); 1385 } 1387 #--------------------------------- 1388 # 1389 # The CRC calculation algorithm. 1390 # 1391 sub do_crc($$$) { 1392 my $nbits = shift; 1393 my $poly = shift; 1394 my $string = shift; 1396 my $crc = ($nbits == 32 ? 0xffffffff : (1 << $nbits) - 1); 1397 for (my $i = 0; $i < length($string); ++$i) { 1398 my $byte = ord(substr($string, $i, 1)); 1399 for( my $b = 0; $b < 8; $b++ ) { 1400 if (($crc & 1) ^ ($byte & 1)) { 1401 $crc >>= 1; 1402 $crc ^= $poly; 1403 } else { 1404 $crc >>= 1; 1405 } 1406 $byte >>= 1; 1407 } 1408 } 1409 printf "%2d bits, ", $nbits; 1410 printf "CRC: %02x\n", $crc; 1412 } 1414 #--------------------------------- 1415 # 1416 # Test harness 1417 # 1418 $/ = undef; 1419 $_ = <>; # read until EOF 1420 my $string = ""; # extract all that looks hex: 1421 s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg; 1422 dump_bytes($string); 1424 #--------------------------------- 1425 # 1426 # 32-bit segmentation CRC 1427 # Note that the text implies this is complemented like for PPP 1428 # (this differs from 8, 7, and 3-bit CRC) 1429 # 1430 # C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 + 1431 # x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32 1432 # 1433 do_crc(32, 0xedb88320, $string); 1435 #--------------------------------- 1436 # 1437 # 8-bit IR/IR-DYN CRC 1438 # 1439 # C(x) = x^0 + x^1 + x^2 + x^8 1440 # 1441 do_crc(8, 0xe0, $string); 1443 #--------------------------------- 1444 # 1445 # 7-bit FO/SO CRC 1446 # 1447 # C(x) = x^0 + x^1 + x^2 + x^3 + x^6 + x^7 1448 # 1449 do_crc(7, 0x79, $string); 1451 #--------------------------------- 1452 # 1453 # 3-bit FO/SO CRC 1454 # 1455 # C(x) = x^0 + x^1 + x^3 1456 # 1457 do_crc(3, 0x6, $string); 1459 Intellectual Property Statement 1461 The IETF takes no position regarding the validity or scope of any 1462 Intellectual Property Rights or other rights that might be claimed to 1463 pertain to the implementation or use of the technology described in 1464 this document or the extent to which any license under such rights 1465 might or might not be available; nor does it represent that it has 1466 made any independent effort to identify any such rights. Information 1467 on the procedures with respect to rights in RFC documents can be 1468 found in BCP 78 and BCP 79. 1470 Copies of IPR disclosures made to the IETF Secretariat and any 1471 assurances of licenses to be made available, or the result of an 1472 attempt made to obtain a general license or permission for the use of 1473 such proprietary rights by implementers or users of this 1474 specification can be obtained from the IETF on-line IPR repository at 1475 http://www.ietf.org/ipr. 1477 The IETF invites any interested party to bring to its attention any 1478 copyrights, patents or patent applications, or other proprietary 1479 rights that may cover technology that may be required to implement 1480 this standard. Please address the information to the IETF at ietf- 1481 ipr@ietf.org. 1483 Copyright Statement 1485 Copyright (C) The Internet Society (2006). This document is subject 1486 to the rights, licenses and restrictions contained in BCP 78, and 1487 except as set forth therein, the authors retain all their rights. 1489 Disclaimer of Validity 1491 This document and the information contained herein are provided on an 1492 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1493 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1494 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1495 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1496 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1497 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1499 This Internet-Draft expires May 6, 2007.