idnits 2.17.1 draft-ietf-rohc-rfc3242bis-01.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1026. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 997. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1004. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1010. ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (September 9, 2005) is 6801 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'VTC2000' is mentioned on line 140, but not defined == Missing Reference: 'MOMUC01' is mentioned on line 152, but not defined -- Looks like a reference, but probably isn't: '2' on line 466 -- Looks like a reference, but probably isn't: '11111001' on line 883 ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 1889 (ref. 'RTP') (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 3242 (ref. 'LLA') (Obsoleted by RFC 4362) -- Obsolete informational reference (is this intentional?): RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 11 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 G. Pelletier 4 Expires: March 2006 K. Sandlund 5 Ericsson 6 September 9, 2005 8 RObust Header Compression (ROHC): 9 A Link-Layer Assisted Profile for IP/UDP/RTP 10 12 Status of this memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This document is a submission of the IETF ROHC WG. Comments should be 35 directed to the ROHC WG mailing list, rohc@ietf.org. 37 Abstract 39 This document defines a ROHC (Robust Header Compression) profile for 40 compression of IP/UDP/RTP (Internet Protocol/User Datagram 41 Protocol/Real-Time Transport Protocol) packets, utilizing 42 functionality provided by the lower layers to increase compression 43 efficiency by completely eliminating the header for most packets 44 during optimal operation. The profile is built as an extension to 45 the ROHC RTP profile. It defines additional mechanisms needed in 46 ROHC, states requirements on the assisting layer to guarantee 47 transparency, and specifies general logic for compression and 48 decompression making use of this header-free packet. This document 49 is a replacement for RFC 3242, which it obsoletes. 51 Table of Contents 53 1. Introduction.....................................................2 54 1.1. Differences from RFC 3242...................................4 55 2. Terminology......................................................5 56 3. Overview of the Link-Layer Assisted Profile......................6 57 3.1. Providing Packet Type Identification........................6 58 3.2. Replacing the Sequence Number...............................7 59 3.3. CRC Replacement.............................................7 60 3.4. Applicability of This Profile...............................8 61 4. Additions and Exceptions Compared to ROHC RTP....................8 62 4.1. Additional Packet Types.....................................8 63 4.1.1. No-Header Packet (NHP).................................8 64 4.1.2. Context Synchronization Packet (CSP)...................9 65 4.1.3. Context Check Packet (CCP)............................10 66 4.2. Interfaces Towards the Assisting Layer.....................11 67 4.2.1. Interface, Compressor to Assisting Layer..............12 68 4.2.2. Interface, Assisting Layer to Decompressor............13 69 4.3. Optimistic Approach Agreement..............................13 70 4.4. Fast Context Initialization, IR Redefinition...............14 71 4.5. Feedback Option, CV-REQUEST................................14 72 4.6. Periodic Context Verification..............................15 73 4.7. Use of Context Identifier..................................15 74 5. Implementation Issues...........................................15 75 5.1. Implementation Parameters and Signals......................15 76 5.1.1. Implementation Parameters at the Compressor...........16 77 5.1.2. Implementation Parameters at the Decompressor.........17 78 5.2. Implementation over Various Link Technologies..............18 79 6. IANA Considerations.............................................18 80 7. Security Consideration..........................................18 81 8. Acknowledgments.................................................18 82 9. References......................................................19 83 9.1. Normative References.......................................19 84 9.2. Informative References.....................................19 86 1. Introduction 88 Header compression is a technique used to compress and transparently 89 decompress the header information of a packet on a per-hop basis, 90 utilizing redundancy within individual packets and between 91 consecutive packets within a packet stream. Over the years, several 92 protocols [VJHC, IPHC] have been developed to compress the network 93 and transport protocol headers [IPv4, IPv6, UDP, TCP], and these 94 schemes have been successful in improving efficiency over many wired 95 bottleneck links, such as modem connections over telephone networks. 96 In addition to IP, UDP, and TCP compression, an additional 97 compression scheme called Compressed RTP [CRTP] has been developed to 98 further improve compression efficiency for the case of real-time 99 traffic using the Real-Time Transport Protocol [RTP]. 101 The schemes mentioned above have all been designed taking into 102 account normal assumptions about link characteristics, which 103 traditionally have been based on wired links only. However, with an 104 increasing number of wireless links in the Internet paths, these 105 assumptions are no longer generally valid. In wireless environments, 106 especially wide coverage cellular environments, relatively high error 107 rates are tolerated in order to allow efficient usage of the radio 108 resources. For real-time traffic, which is more sensitive to delays 109 than to errors, such operating conditions will be norm over, for 110 example, 3rd generation cellular links, and header compression must 111 therefore tolerate packet loss. However, with the previously 112 mentioned schemes, especially for real-time traffic compressed by 113 CRTP, high error rates have been shown to significantly degrade 114 header compression performance [CRTPC]. This problem was the driving 115 force behind the creation of the RObust Header Compression (ROHC) WG 116 in the IETF. 118 The ROHC WG has developed a header compression framework on top of 119 which profiles can be defined for different protocol sets, or for 120 different compression strategies. Due to the limited packet loss 121 robustness of CRTP, and the demands of the cellular industry for an 122 efficient way of transporting voice over IP over wireless, the main 123 focus of ROHC has so far been on compression of IP/UDP/RTP headers, 124 which are generous in size, especially compared to the payloads often 125 carried by packets with such headers. 127 ROHC RTP has become a very efficient, robust and capable compression 128 scheme, able to compress the headers down to a total size of one 129 octet only. Also, transparency is guaranteed to an extremely great 130 extent even when residual bit errors are present in compressed 131 headers delivered to the decompressor. The requirements for RTP 132 compression [RTP-REQ], defined by the WG before and during the 133 development process, have thus been fulfilled. 135 As mentioned above, the 3rd generation cellular systems, where IP 136 will be used end-to-end, have been one of the driving forces behind 137 ROHC RTP, and the scheme has been designed to also suit new cellular 138 air interfaces, such as WCDMA, making it possible to run even speech 139 services with spectrum efficiency insignificantly lower than for 140 existing one-service circuit switched solutions [VTC2000]. However, 141 other air interfaces such as those based on GSM and IS-95 will also 142 be used in all-IP networks, with further implications for the header 143 compression issue. These older air interfaces are less flexible, 144 with radio bearers optimized for specific payload sizes. This means 145 that not even a single octet of header can be added without using the 146 next higher fixed packet size supported by the link, something which 147 is obviously very costly. For the already deployed speech vocoders, 148 the spectrum efficiency over these links will thus be low compared to 149 existing circuit switched solutions. To achieve high spectrum 150 efficiency overall with any application, more flexible air interfaces 151 must be deployed, and then the ROHC RTP scheme will perform 152 excellently, as shown for WCDMA [MOMUC01]. However, for deployment 153 reasons, it is however important to also provide a suitable header 154 compression strategy for already existing vocoders and air 155 interfaces, such as for GERAN and for CDMA2000, with minimal effects 156 on spectral efficiency. 158 This document describes a link-layer assisted ROHC RTP profile, 159 originally defined by [LLA], extending ROHC RTP (profile 0x0001) 160 [ROHC], and compliant with the ROHC 0-byte requirements [0B-REQ]. 161 The purpose of this profile is to provide a header-free packet format 162 that, for a certain application behavior, can replace a majority of 163 the 1-octet header ROHC RTP packets during normal U/O-mode operation, 164 while still being fully transparent and complying with all the 165 requirements of ROHC RTP [RTP-REQ]. For other applications, 166 compression will be carried out as with normal ROHC RTP. 168 To completely eliminate the compressed header, all functionality 169 normally provided by the 1-octet header has to be provided by other 170 means, typically by utilizing functionality provided by the lower 171 layers and sacrificing efficiency for less frequently occurring 172 larger compressed headers. The latter is not a contradiction since 173 the argument for eliminating the last octet for most packets is not 174 overall efficiency in general. It is important to remember that the 175 purpose of this profile is to provide efficient matching of existing 176 applications to existing link technologies, not efficiency in 177 general. The additional complexity introduced by this profile, 178 although minimized by a tight integration with already existing ROHC 179 functionality, implies that it should therefore only be used to 180 optimize performance of specific applications over specific links. 182 When implementing this profile over various link technologies, care 183 must be taken to guarantee that all the functionality needed is 184 provided by ROHC and the lower layers together. Therefore, 185 additional documents should specify how to incorporate this profile 186 on top of various link technologies. 188 The profile defined by this document was originally specified by RFC 189 3242 [LLA], but to address one technical flaw and clarify one 190 implementation issue, this document has been issued to replace RFC 191 3242, which becomes obsolete. 193 1.1. Differences from RFC 3242 195 This section briefly summarizes the differences in this document from 196 RFC 3242. Acronyms and terminology can be found in section 2. 198 The format of the CSP packet, as defined in [LLA], was identified as 199 non-interoperable when carrying a RHP header with a 3-bit or 7-bit 200 CRC. This problem occurs due to the payload having been dropped by 201 the compressor, while the decompressor is supposed to use the payload 202 length to infer certain fields in the uncompressed header. These 203 fields are the IPv4 total length, the IPv6 payload length, the UDP 204 length and the IPv4 header checksum field (all INFERRED fields in 205 [ROHC]). To correct this flaw, the CSP packet must carry information 206 about the payload length of the RHP packet. Therefore the length of 207 the RTP payload has been included in the CSP packet. 209 This document also clarifies an unclear referencing in RFC 3242, 210 where section 4.1.3 of [LLA] states that upon CRC failure, the 211 actions of [ROHC] section 5.3.2.2.3 MUST be taken. That section 212 specifies that detection of SN wraparound and local repair must be 213 performed, while neither of these steps apply when the failing packet 214 is a CCP. Therefore, upon CRC failure, actions to be taken are the 215 ones specified in section 5.3.2.2.3, but steps a-d only. 217 2. Terminology 219 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 220 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 221 document are to be interpreted as described in RFC 2119. 223 CCP Context Check Packet 224 CRC Cyclic Redundancy Check 225 CSP Context Synchronization Packet 226 LLA Link Layer Assisted ROHC RTP profile 227 NHP No Header Packet 228 ROHC RObust Header Compression 229 RHP ROHC Header Packet (a non-NHP packet, i.e., RRP, CSP or CCP) 230 RRP ROHC RTP Packet as defined in [ROHC, profile 0x0001] 232 Assisting layer 234 "Assisting layer" refers to any entity implementing the interface 235 to ROHC (section 4.2). It may, for example, refer to a sub-layer 236 used to adapt the ROHC implementation and the physical link layer. 237 This layer is assumed to have knowledge of the physical layer 238 synchronization. 240 Compressing side 242 "Compressing side" refers to the combination of the header 243 compressor, operating with the LLA profile, and its associated 244 assisting layer. 246 Lower layers 248 "Lower layers" in this document refers to entities located below 249 ROHC in the protocol stack, including the assisting layer. 251 ROHC RTP 253 "ROHC RTP" refers to the IP/UDP/RTP profile as defined in [ROHC]. 255 3. Overview of the Link-Layer Assisted Profile 257 The ROHC IP/UDP/RTP profile defined in [LLA] and updated by this 258 document, profile 0x0005 (hex), is designed to be used over channels 259 that have been optimized for specific payload sizes and therefore 260 cannot efficiently accommodate header information when transmitted 261 together with payloads corresponding to these optimal sizes. 263 The LLA profile extends, and thus also inherits all functionality 264 from, the ROCH RTP profile by defining some additional functionality 265 and an interface from the ROHC component towards an assisting lower 266 layer. 268 +---------------------------------------+ 269 | | 270 The LLA | ROHC RTP, | 271 profile | Profile #1 +-----------------+ 272 | | LLA Additions | 273 +---------------------+-----------------+ 275 By imposing additional requirements on the lower layers compared to 276 [ROHC], it is possible to infer the information needed to maintain 277 robust and transparent header compression even though the headers are 278 completely eliminated during most of the operation time. 280 Basically, what this profile does is to replace the smallest and most 281 frequent ROHC U/O-mode headers with a no-header format, for which the 282 header functionality must be provided by other means. 284 Smallest header in Smallest header in 285 ROHC RTP (profile #1) LLA (profile #5) 286 +--+--+--+--+--+--+--+--+ ++ 287 | 1 octet | -----> || No Header 288 +--+--+--+--+--+--+--+--+ ++ 289 | 290 | Header field functionality 291 +-------------------> provided by other means 293 The fields present in the ROHC RTP headers for U/O-mode PT0 are the 294 packet type identifier, the sequence number and the CRC. The 295 subsequent sections elaborate more on how the functionality of these 296 fields is replaced for NHP. 298 3.1. Providing Packet Type Identification 300 All ROHC headers carry a packet type identifier, indicating to the 301 decompressor how the header should be interpreted. This is a 302 function that must be provided by some means in 0-byte header 303 compression. ROHC RTP packets with compressed headers will be 304 possible to distinguish thanks to the packet type identifier, but a 305 mechanism is needed to separate packets with a header from packets 306 without a header. This function MUST therefore be provided by the 307 assisting layer in one way or another. 309 3.2. Replacing the Sequence Number 311 From the sending application, the RTP sequence number is increased by 312 one for each packet sent. The purpose of the sequence number is to 313 cope with packet reordering and packet loss. If reordering or loss 314 has occurred before the transmission point, if needed the compressing 315 side can easily avoid problems by not allowing the use of a header- 316 free packet. 318 However, at the transmission point, loss or reordering that may occur 319 over the link can not be anticipated and covered for. Therefore, for 320 NHP the assisting layer MUST guarantee in-order delivery over the 321 link (already assumed by [ROHC]) and at the receiving side it MUST 322 provide an indication for each packet loss over the link. This is 323 basically the same principle as the VJ header compression [VJHC] 324 relies on. 326 Note that guaranteeing in-order delivery and packet loss indication 327 over the link not only makes it possible to infer the sequence number 328 information, but also supersedes the main function of the CRC, which 329 normally takes care of errors due to long link losses and bit errors 330 in the compressed sequence number. 332 3.3. CRC Replacement 334 All context updating RRP packets carry a CRC calculated over the 335 uncompressed header. The CRC is used by the decompressor to verify 336 that the updated context is correct. This verification serves three 337 purposes in U/O-mode: 339 1) Detection of longer losses than can be covered by the sequence 340 number LSBs 341 2) Protection against failures caused by residual bit errors in 342 compressed headers 343 3) Protection against faulty implementations and other causes of 344 error 346 Since this profile defines an NHP packet without this CRC, care must 347 be taken to fulfill these purposes by other means, when an NHP is 348 used as a replacement for a context updating packet. Detection of 349 long losses (1) is already covered since the assisting layer MUST 350 provide indication of all packet losses. Furthermore, the NHP packet 351 has one important advantage over RHP packets in that residual bit 352 errors (2) cannot damage a header that is not even sent. 354 It is thus reasonable to assume that compression and decompression 355 transparency can be assured with high confidence even without a CRC 356 in header-free packets. However, to provide additional protection 357 against damage propagation due to undetected residual bit errors in 358 context updating packets (2) or other unexpected errors (3), periodic 359 context verifications SHOULD be performed (see section 4.6). 361 3.4. Applicability of This Profile 363 The LLA profile can be used with any link technology capable of 364 providing the required functionality described in previous sections. 365 Whether LLA or ROHC RTP should be implemented thus depends on the 366 characteristics of the link itself. For most RTP packet streams, LLA 367 will work exactly as ROHC RTP, while it will be more efficient for 368 packet streams with certain characteristics. LLA will never be less 369 efficient than ROHC RTP. 371 Note as well that LLA, like all other ROHC profiles, is fully 372 transparent to any packet stream reaching the compressor. LLA does 373 not make any assumptions about the packet stream but will perform 374 optimally for packet streams with certain characteristics, e.g., 375 synchronized streams exactly timed with the assisting link over which 376 the LLA profile is implemented. 378 The LLA profile is obviously not applicable if the UDP checksum (2 379 bytes) is enabled, which is always the case for IPv6/UDP. For 380 IPv4/UDP, the sender may choose to disable the UDP checksum. 382 4. Additions and Exceptions Compared to ROHC RTP 384 4.1. Additional Packet Types 386 The LLA profile defines three new packet types to be used in addition 387 to the RRP packet types defined by [ROHC]. The following sections 388 describe these packet types and their purpose in detail. 390 4.1.1. No-Header Packet (NHP) 392 A No-Header Packet (NHP), i.e., a packet consisting only of a 393 payload, is defined and MAY be used when only sequencing must be 394 conveyed, i.e., when all header fields are either unchanged or follow 395 the currently established change pattern. In addition, there are 396 some considerations for the use of the NHP (see 4.3, 4.5 and 4.6). An 397 LLA compressor is not allowed to deliver NHP packets when operating 398 in R-mode. 400 The assisting layer MAY send the NHP for RTP SN = X only if an NHP 401 was delivered by the LLA compressor AND the assisting layer can 402 guarantee that the decompressor will infer the proper sequencing for 403 this NHP. This guarantee is based on the confidence that the 404 decompressor 406 a) has the means to infer proper sequencing for the packet 407 corresponding to SN = X-1, AND 409 b) has either received a loss indication or the packet itself for the 410 packet corresponding to SN = X-1. 412 Updating properties: NHP packets update context (RTP Sequence 413 Number). 415 4.1.2. Context Synchronization Packet (CSP) 417 The case where the packet stream overruns the channel bandwidth may 418 lead to data being discarded, which may result in decompressor 419 context invalidation. It might therefore be beneficial to send a 420 packet with only the header information and discard the payload. This 421 would be helpful to maintain synchronization of the decompressor 422 context, while efficiently using the available bandwidth. 424 This case can be handled with the Context Synchronization Packet 425 (CSP), which has the following format: 427 0 1 2 3 4 5 6 7 428 +---+---+---+---+---+---+---+---+ 429 | 1 1 1 1 1 0 1 0 | Packet type identifier 430 +===+===+===+===+===+===+===+===+ 431 / RTP Payload Length / 2 octets 432 +---+---+---+---+---+---+---+---+ 433 : ROHC header without padding : 434 : see [ROHC, section 5.7] : 435 +---+---+---+---+---+---+---+---+ 437 RTP Payload Length: This field is the length of the payload carried 438 inside the RTP header, stored in network byte 439 order. I.e. this field will be set by the 440 compressor to (UDP length - size of the UDP 441 header - size of the RTP header including CSRC 442 identifiers). 444 Updating properties: CSP maintains the updating properties of the 445 ROHC header it carries. 447 The CSP is defined by one of the unused packet type identifiers from 448 ROHC RTP, carried in the one-octet base header. As for any ROHC 449 packet, except the NHP, the packet may begin with ROHC padding and/or 450 feedback. It may also carry context identification after the packet 451 type identifier. It is possible to have two CID fields present, one 452 after the packet type ID and one within the encapsulated ROHC header. 453 If a decompressor receives a CSP with two non-equal CID values 454 included, the packet MUST be discarded. ROHC segmentation may also 455 be applied to the CSP. 457 In the CSP packet the payload has been dropped by the compressor. 458 However, the decompressor is supposed to use the payload length to 459 infer certain fields in the uncompressed header (the IPv4 total 460 length, the IPv6 payload length, the UDP length and the IPv4 header 461 checksum field). When dropping the payload, the CSP packet needs to 462 contain information about the payload length carried in the RHP 463 packet. Therefore the length of the RTP payload is carried in the 464 CSP packet. When the decompressor receives a CSP packet, it can use 465 the RTP payload length field to calculate the value of fields 466 classified as INFERRED in [2], when attempting to verify a 3- or 7- 467 bit CRC carried in the RHP header enclosed in the CSP. 469 Note that when the decompressor has received and processed a CSP, the 470 packet (including any possible data following the CSP encapsulated 471 compressed header) MUST be discarded. 473 4.1.3. Context Check Packet (CCP) 475 A Context Check Packet (CCP), which does not carry any payload but 476 only an optional CRC value in addition to the packet type identifier, 477 is defined. 479 The purpose of the CCP is to provide a useful packet that MAY be sent 480 by a synchronized physical link layer in the case where data must be 481 sent at fixed intervals, even if no compressed packet is available. 482 Whether the CCP is sent over the link and delivered to the 483 decompressor is decided by the assisting layer. The CCP has the 484 following format: 486 0 1 2 3 4 5 6 7 487 +---+---+---+---+---+---+---+---+ 488 | 1 1 1 1 1 0 1 1 | Packet type identifier 489 +===+===+===+===+===+===+===+===+ 490 | C | CRC | 491 +---+---+---+---+---+---+---+---+ 493 C: C = 0 indicates that the CRC field is not used; 494 C = 1 indicates that a valid CRC is present. 496 Updating properties: CCP packets do not update context. 498 The CCP is defined by one of the unused packet type identifiers from 499 ROHC RTP, carried in the first octet of the base header. The first 500 bit of the second octet, the C bit, indicates whether the CRC field 501 is used or not. If C=1, the CRC field MUST be set to the 7-bits CRC 502 calculated over the original uncompressed header defined in [ROHC 503 section 5.9.2]. As for any ROHC packet, except NHP, the packet MAY 504 begin with ROHC padding and/or carry context identification. 506 The use of the CRC field to perform decompressor context verification 507 is optional and is therefore a compressor implementation issue. 508 However, a CCP MUST always be made available to the assisting layer. 510 If the assisting layer receives CCPs with the C-bit set (C=1) from 511 the compressor, it MUST use the last CCP received if a CCP is to be 512 sent, i.e., the CCP corresponding to the last non-CCP packet sent 513 (NHP, RRP or CSP). An assisting layer MAY use the CCP for other 514 purposes, such as signaling a packet loss before the link. 516 The decompressor is REQUIRED to handle a CCP received with the C bit 517 set (C=1), indicating a valid CRC field, and perform context 518 verification. The received CRC MUST then be applied to the last 519 decompressed packet, unless a packet loss indication was previously 520 received. Upon CRC failure, actions MUST be taken as specified in 521 [ROHC, section 5.3.2.2.3, steps a-d only]. A CCP received with C=0 522 MUST be ignored by the decompressor. The decompressor is not allowed 523 to make any further interpretation of the CCP. 525 When using the 7-bit CRC in the CCP packet to verify the context, the 526 decompressor needs to have access to the entire uncompressed header 527 of the latest packet decompressed. Some implementations of [ROHC] 528 might not save the values of INFERRED fields. An implementation of 529 ROHC LLA MUST save these fields in the decompressor context to be 530 able to successfully verify CCP packets. 532 The use of CCP by an assisting layer is optional and depends on the 533 characteristics of the actual link. Whether it is used or not MUST 534 therefore be specified in link layer implementation specifications 535 for this profile. 537 4.2. Interfaces Towards the Assisting Layer 539 This profile relies on the lower layers to provide the necessary 540 functionality to allow NHP packets to be sent. This interaction 541 between LLA and the assisting layer is defined as interfaces between 542 the LLA compressor/decompressor and the LLA applicable link 543 technology. 545 | | 546 + + 547 +-------------------------+ +-------------------------+ 548 | ROHC RTP HC | | ROHC RTP HD | 549 +-------------------------+ +-------------------------+ 550 | LLA profile | | LLA profile | 551 +=========================+ +=========================+ 552 | Interface | | Interface | 553 | ROHC to assisting layer | | Assisting layer to ROHC | 554 +=========================+ +=========================+ 555 | Applicable | | Applicable | 556 | link technology | | link technology | 557 +=========================+ +=========================+ 558 | | 559 +------>---- CHANNEL ---->-----+ 561 The figure above shows the various levels, as defined in [ROHC] and 562 this document, constituting a complete implementation of the LLA 563 profile. The figure also underlines the need for additional 564 documents to specify how to implement these interfaces for a link 565 technology for which this profile is relevant. 567 This section defines the information to be exchanged between the LLA 568 compressor and the assisting layer for this profile to operate 569 properly. While it does define semantics, it does not specify how 570 these interfaces are to be implemented. 572 4.2.1. Interface, Compressor to Assisting Layer 574 This section defines the interface semantics between the compressor 575 and the assisting layer, providing rules for packet delivery from the 576 compressor. 578 The interface defines the following parameters: RRP, RRP segmentation 579 flag, CSP, CSP segmentation flag, NHP, and RTP Sequence Number. All 580 parameters, except the NHP, MUST always be delivered to the assisting 581 layer. This leads to two possible delivery scenarios: 583 a. RRP, CSP, CCP, NHP and RTP Sequence Number are delivered, along 584 with the corresponding segmentation flags set accordingly. 586 This corresponds to the case when the compressor allows sending of 587 an NHP packet, with or without segmentation being applied to the 588 corresponding RRP/CSP packets. 590 Recall that delivery of an NHP packet occurs when the ROHC RTP 591 compressor would have used a ROHC UO-0. 593 b. RRP, CSP, CCP and RTP Sequence Number are delivered, along with 594 the corresponding segmentation flags set accordingly. 596 This corresponds to the case when the compressor does not allow 597 sending of an NHP packet. Segmentation might be applied to the 598 corresponding RRP and CSP packets. 600 Segmentation may be applied independently to an RRP or a CSP packet 601 if its size exceeds the largest value provided in the PREFERRED 602 PACKET_SIZES list and if the LARGE_PACKET_ALLOWED parameter is set to 603 false. The segmentation flags are explicitly stated in the interface 604 definition to emphasize that the RRP and the CSP may be delivered by 605 the compressor as segmented packets. 607 The RTP SN MUST be delivered for each packet by the compressor to 608 allow the assisting layer to maintain the necessary sequencing 609 information. 611 4.2.2. Interface, Assisting Layer to Decompressor 613 Here the interface semantics between the assisting layer and the 614 decompressor are defined, providing simple rules for the delivery of 615 received packets to the decompressor. The decompressor needs a way 616 to distinguish NHP packets from RHP packets. Also, when receiving 617 packets without a header, the decompressor needs a way to infer the 618 sequencing information to keep synchronization between the received 619 payload and the sequence information of the decompressed headers. To 620 achieve this, the decompressor MUST receive the following from the 621 assisting layer: 623 - an indication for each packet loss over the link between the 624 compressing and decompressing sides for CID=0 625 - the received packet together with an indication whether the packet 626 received is an NHP or not 628 Note that the context is updated from a packet loss indication. 630 4.3. Optimistic Approach Agreement 632 ROHC defines an optimistic approach for updates to reduce the header 633 overhead. This approach is fully exploited in the Optimistic and 634 Unidirectional modes of operation. Due to the presence of a CRC in 635 all compressed headers, the optimistic approach is defined as a 636 compressor issue only because the decompressor will always be able to 637 detect an invalid context through the CRC verification. 639 However, no CRC is present in the NHP packet defined by the LLA 640 profile. Therefore the loss of an RHP packet updating the context 641 may not always be detected. To avoid this problem, the compressing 642 and decompressing sides must agree on the principles for the 643 optimistic approach, and the agreed principles MUST be enforced not 644 only by the compressor but also by the transmitting assisting layer. 645 If, for example, three consecutive updates are sent to convey a 646 header field change, the decompressor must know this and invalidate 647 the context in case of three or more consecutive physical packet 648 losses. Note that the mechanism used to enforce the optimistic 649 approach must be reinitialized if a new field change needs to be 650 conveyed while the compressing side is already sending packets to 651 convey non-linear context updates. 653 An LLA decompressor MUST use the optimistic approach knowledge to 654 detect possible context loss events. If context loss is suspected it 655 MUST invalidate the context and not forward any packets before the 656 context has been synchronized. 658 It is REQUIRED that all documents, describing how the LLA profile is 659 implemented over a certain link technology, define how the optimistic 660 approach is agreed between the compressing side and the decompressing 661 side. It could be handled with a fixed principle, negotiation at 662 startup, or by other means, but the method must be unambiguously 663 defined. 665 4.4. Fast Context Initialization, IR Redefinition 667 As initial IR packets might overrun the channel bandwidth and 668 significantly delay decompressor context establishment, it might be 669 beneficial to initially discard the payload. This allows state 670 transitions and higher compression efficiency to be achieved with 671 minimal delay. 673 To serve this purpose, the D-bit from the basic structure of the ROHC 674 RTP IR packet [ROHC section 5.7.7.1] is redefined for the LLA 675 profile. For D=0 (no dynamic chain), the meaning of the D-bit is 676 extended to indicate that the payload has been discarded when 677 assembling the IR packet. All other fields keep their meanings as 678 defined for ROHC RTP. 680 The resulting structure, using small CIDs and CID=0, becomes: 682 0 1 2 3 4 5 6 7 683 +---+---+---+---+---+---+---+---+ 684 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | D | 685 +---+---+---+---+---+---+---+---+ 686 | Profile | 1 octet 687 +---+---+---+---+---+---+---+---+ 688 | CRC | 1 octet 689 +---+---+---+---+---+---+---+---+ 690 | Static | variable length 691 | chain | 692 - - - - - - - - - - - - - - - - 693 | Dynamic | not present if D = 0 694 | chain | present if D = 1, variable length 695 - - - - - - - - - - - - - - - - 696 | Payload | not present if D = 0 697 | | present if D = 1, variable length 698 - - - - - - - - - - - - - - - - 700 D: D = 0 indicates that the dynamic chain is not present 701 and the payload has been discarded. 703 After an IR packet with D=0 has been processed by the decompressor, 704 the packet MUST be discarded. 706 4.5. Feedback Option, CV-REQUEST 708 The CV-REQUEST option MAY be used by the decompressor to request an 709 RRP or CSP for context verification. This option should be used if 710 only NHP have been received for a long time and the context therefore 711 has not been verified recently. 713 +---+---+---+---+---+---+---+---+ 714 | Opt Type = 8 | Opt Len = 0 | 715 +---+---+---+---+---+---+---+---+ 717 If the compressor receives a feedback packet with this option, the 718 next packet compressed SHOULD NOT be delivered to the assisting layer 719 as an NHP. 721 4.6. Periodic Context Verification 723 As described in section 3.3, transparency is expected to be 724 guaranteed by the functionality provided by the lower layers. This 725 ROHC profile would therefore be at least as reliable as the older 726 header compression schemes [VJHC, IPHC, CRTP], which do not make use 727 of a header compression CRC. However, since ROHC RTP normally is 728 extremely safe to use from a transparency point of view, it would be 729 desirable to be able to achieve this with LLA also. 731 To provide an additional guarantee for transparency and also catch 732 unexpected errors, such as errors due to faulty implementations, it 733 is RECOMMENDED to periodically send context updating packets, even 734 when the compressor logic allows NHP packets to be used. 736 4.7. Use of Context Identifier 738 Since an NHP cannot carry a context identifier (CID), there is a 739 restriction on how this profile may be used, related to context 740 identification. Independent of which CID size has been negotiated, 741 NHP packets can only be used for CID=0. If the decompressor receives 742 an NHP packet, it can only belong to CID=0. 744 Note that if multiple packet streams are handled by a compressor 745 operating using LLA, the assisting layer must in case of physical 746 packet loss be able to tell for which CID the loss occurred, or at 747 least it MUST be able to tell if packets with CID=0 (packet stream 748 with NHPs) have been lost. 750 5. Implementation Issues 752 This document specifies mechanisms for the protocol and leaves 753 details on the use of these mechanisms to the implementers. The 754 present chapter aims to provide guidelines, ideas and suggestions for 755 implementation of LLA. 757 5.1. Implementation Parameters and Signals 759 As described in [ROHC, section 6.3], implementations use parameters 760 to set up configuration information and to stipulate how a ROHC 761 implementation is to operate. The following parameters are 762 additions, useful to LLA, to the parameter set defined for ROHC RTP 763 implementations. Note that if the PREFERRED_PACKET_SIZES parameters 764 defined here are used, they obsolete all PACKET_SIZE and PAYLOAD_SIZE 765 parameters of ROHC RTP. 767 5.1.1. Implementation Parameters at the Compressor 769 ALWAYS_PAD -- value: boolean 771 This parameter may be set by an external entity to specify to the 772 compressor that every RHP packet MUST be padded with a minimum of 773 one octet ROHC padding. 775 The assisting layer MUST provide a packet type identification. If 776 no field is available for this purpose from the protocol at the 777 link layer, then a leading sequence may be used to distinguish RHP 778 packets from NHP packets. Although the use of a leading sequence 779 is obviously not efficient, since it sacrifices efficiency for RHP 780 packets, the efficiency loss should be insignificant because the 781 leading sequence applies only to packets with headers in order to 782 favor the use of packets without headers. If a leading sequence 783 is desired for RHP identification, the lower layer MAY use ROHC 784 padding for the leading sequence by setting the ALWAYS_PAD 785 parameter. Note that in such cases, possible collisions of the 786 padding with the NHP payload must be avoided. 788 By default, this parameter is set to FALSE. 790 PREFERRED_PACKET_SIZES -- list of: 791 SIZE -- value: integer (octets) 792 RESTRICTED_TYPE -- values: [NHP_ONLY, RHP_ONLY, NO_RESTRICTION] 794 This parameter set governs which packet sizes are preferred by the 795 assisting layer. If this parameter set is used, all RHP packets 796 MUST be padded to fit the smallest possible preferred size. If 797 the size of the unpadded packet (or, in the case of ALWAYS_PAD 798 being set, the packet with minimal one octet padding) is larger 799 than the maximal preferred packet size, the compressor has two 800 options. Either, it may deliver this larger packet with an 801 arbitrary size, or it may split the packet into several segments 802 using ROHC segmentation and pad each segment to one of the 803 preferred sizes. Which method to use depends on the value of the 804 LARGE_PACKETS_ALLOWED parameter below. 806 NHP packets can be delivered to the lower layer only if the 807 payload size is part of the preferred packet size set. 808 Furthermore, if RESTRICTED_TYPE is set to one of NHP_ONLY or 809 RHP_ONLY for any of the preferred packet sizes, that size is 810 allowed only for packets of the specified type. 812 By default, no preferred packet sizes are specified. When sizes 813 are specified, the default value for RESTRICTED_TYPE is 814 NO_RESTRICTION. 816 LARGE_PACKETS_ALLOWED -- value: boolean 818 This parameter may be set by an external entity to specify how to 819 handle packets that do not fit any of the preferred packet sizes 820 specified. If it is set to TRUE, the compressor MUST deliver the 821 larger packet as-is and MUST NOT use segmentation. If it is set 822 to FALSE, the ROHC segmentation scheme MUST be used to split the 823 packet into two or more segments, and each segment MUST further be 824 padded to fit one of the preferred packet sizes. 826 By default, this parameter is set to TRUE, which means that 827 segmentation is disabled. 829 VERIFICATION_PERIOD -- value: integer 831 This parameter may be set by an external entity to specify to the 832 compressor the minimum frequency with which a packet validating 833 the context must be sent. This tells the compressor that a packet 834 containing a CRC field MUST be sent at least once every N packets, 835 where N=VERIFICATION_PERIOD (see section 4.6). 837 By default, this parameter is set to 0, which indicates that 838 periodical verifications are disabled. 840 5.1.2. Implementation Parameters at the Decompressor 842 NHP_PACKET -- value: boolean 844 This parameter informs the decompressor that the packet being 845 delivered is an NHP packet. The decompressor MUST accept this 846 packet type indicator from the lower layer. An assisting layer 847 MUST set this indicator to true for every NHP packet delivered, 848 and to false for any other packet. 850 PHYSICAL_PACKET_LOSS -- signal 852 This signal indicates to the decompressor that a packet has been 853 lost on the link between the compressing and the decompressing 854 sides, due to a physical link error. The signal is given once for 855 each packet that was lost, and a decompressor must increase the 856 sequence number accordingly when this signal is received. 858 PRE_LINK_PACKET_LOSS -- signal 860 This signal tells the decompressor to increase the sequence number 861 due to a gap in the sequencing, not related to a physical link 862 error. A receiving assisting layer may for example use this 863 signal to indicate to the decompressor that a packet was lost 864 before the compressor, or that a packet was discarded by the 865 transmitting assisting layer. 867 5.2. Implementation over Various Link Technologies 869 This document provides the semantics and requirements of the 870 interface needed from the ROHC compressor and decompressor towards 871 the assisting layer to perform link-layer assisted header 872 compression. 874 However, this document does not provide any link layer specific 875 operational information, except for some implementation suggestions. 876 Further details about how this profile is to be implemented over 877 various link technologies must be described in other documents, where 878 specific characteristics of each link layer can be taken into account 879 to provide optimal usage of this profile. 881 These specifications MAY use a packet type bit pattern unused by this 882 profile to implement signaling on the lower layer. The pattern 883 available to lower layer implementations is [11111001]. 885 6. IANA Considerations 887 ROHC profile identifier 0x0005 has been reserved by the IANA for the 888 IP/UDP/RTP profile defined in this document. 890 7. Security Consideration 892 The security considerations of ROHC RTP [ROHC section 7] apply also 893 to this document with one addition: in the case of a denial-of- 894 service attack scenario where an intruder injects bogus CCP packets 895 onto the link using random CRC values, the CRC check will fail for 896 incorrect reasons at the decompressor side. This would obviously 897 greatly reduce the advantages of ROHC and any extra efficiency 898 provided by this profile due to unnecessary context invalidation, 899 feedback messages and refresh packets. However, the same remarks 900 related to the presence of such an intruder apply. 902 8. Acknowledgments 904 The authors would like to thank Lila Madour, Ulises Olvera-Hernandez 905 and Francis Lupien for input regarding the typical links in which LLA 906 can be applied. Thanks also to Mikael Degermark for fruitful 907 discussions that led to improvements of this profile, and to Zhigang 908 Liu for many valuable comments. 910 9. References 912 9.1. Normative References 914 [ROHC] Bormann, C., et al., "RObust Header Compression (ROHC): 915 Framework and four profiles: RTP, UDP, ESP, and 916 uncompressed", RFC 3095, July 2001. 918 [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, 919 September 1981. 921 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 922 (IPv6) Specification", RFC 2460, December 1998. 924 [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 925 August 1980. 927 [RTP] Schulzrinne, H., Casner S., Frederick, R. and V. 928 Jacobson, "RTP: A Transport Protocol for Real-Time 929 Applications", RFC 1889, January 1996. 931 9.2. Informative References 933 [LLA] Jonsson, L-E. and G. Pelletier, "RObust Header 934 Compression (ROHC): A Link-Layer Assisted Profile for 935 IP/UDP/RTP", RFC 3242, April 2002. 937 [TCP] Postel, P., "Transmission Control Protocol", STD 7, RFC 938 793, September 1981. 940 [RTP-REQ] Degermark, M., "Requirements for IP/UDP/RTP Header 941 Compression", RFC 3096, July 2001. 943 [0B-REQ] Jonsson, L-E., "RObust Header Compression (ROHC): 944 Requirements and Assumptions for 0-byte IP/UDP/RTP 945 Compression", RFC 3243, April 2002. 947 [VJHC] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed 948 Serial Links", RFC 1144, February 1990. 950 [IPHC] Degermark, M., Nordgren, B. and S. Pink, "IP Header 951 Compression", RFC 2507, February 1999. 953 [CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 954 Headers for Low-Speed Serial Links", RFC 2508, February 955 1999. 957 [CRTPC] Degermark, M., Hannu, H., Jonsson, L-E. and K. Svanbro, 958 "Evaluation of CRTP Performance over Cellular Radio 959 Networks", IEEE Personal Communications Magazine, Volume 960 7, number 4, pp. 20-25, August 2000. 962 Authors' Addresses 964 Lars-Erik Jonsson 965 Ericsson AB 966 Box 920 967 SE-971 28 Lulea, Sweden 968 Phone: +46 8 404 29 61 969 Fax: +46 920 996 21 970 EMail: lars-erik.jonsson@ericsson.com 972 Ghyslain Pelletier 973 Ericsson AB 974 Box 920 975 SE-971 28 Lulea, Sweden 976 Phone: +46 8 404 29 43 977 Fax: +46 920 996 21 978 EMail: ghyslain.pelletier@ericsson.com 980 Kristofer Sandlund 981 Ericsson AB 982 Box 920 983 SE-971 28 Lulea, Sweden 984 Phone: +46 8 404 41 58 985 Fax: +46 920 996 21 986 EMail: kristofer.sandlund@ericsson.com 988 Intellectual Property Statement 990 The IETF takes no position regarding the validity or scope of any 991 Intellectual Property Rights or other rights that might be claimed to 992 pertain to the implementation or use of the technology described in 993 this document or the extent to which any license under such rights 994 might or might not be available; nor does it represent that it has 995 made any independent effort to identify any such rights. Information 996 on the procedures with respect to rights in RFC documents can be 997 found in BCP 78 and BCP 79. 999 Copies of IPR disclosures made to the IETF Secretariat and any 1000 assurances of licenses to be made available, or the result of an 1001 attempt made to obtain a general license or permission for the use of 1002 such proprietary rights by implementers or users of this 1003 specification can be obtained from the IETF on-line IPR repository at 1004 http://www.ietf.org/ipr. 1006 The IETF invites any interested party to bring to its attention any 1007 copyrights, patents or patent applications, or other proprietary 1008 rights that may cover technology that may be required to implement 1009 this standard. Please address the information to the IETF at ietf- 1010 ipr@ietf.org. 1012 Copyright Statement 1014 Copyright (C) The Internet Society (2005). This document is subject 1015 to the rights, licenses and restrictions contained in BCP 78, and 1016 except as set forth therein, the authors retain all their rights. 1018 Disclaimer of Validity 1020 This document and the information contained herein are provided on an 1021 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1022 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1023 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1024 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1025 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1026 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1028 This Internet-Draft expires March 9, 2006.