idnits 2.17.1 draft-ietf-rohc-rfc3095bis-framework-04.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1821. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1792. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1799. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1805. ** 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 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3978, Section 5.1 boilerplate, a section with a similar start was also found: By submitting this Internet-Draft, each author accepts the provisions of Section 3 of BCP 78. == 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 (November 29, 2006) is 6320 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: 'RFC-ed' on line 1561 -- Looks like a reference, but probably isn't: '0-9a-fA-F' on line 1745 -- Duplicate reference: RFC3095, mentioned in '6', was also mentioned in '3'. -- Duplicate reference: RFC3095, mentioned in '8', was also mentioned in '6'. -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '11') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '14') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '22') (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 15 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: May 2007 K. Sandlund 5 Ericsson 6 November 29, 2006 8 The RObust Header Compression (ROHC) Framework 9 11 Status of this memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 By submitting this Internet-Draft, each author accepts the provisions 19 of Section 3 of BCP 78. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Abstract 38 The RObust Header Compression (ROHC) protocol provides an efficient, 39 flexible and future-proof header compression concept. It is designed 40 to operate efficiently and robustly over various link technologies 41 with different characteristics. 43 The ROHC framework, along with a set of compression profiles, was 44 initially defined in RFC 3095. To improve and simplify the ROHC 45 specifications, this document explicitly defines the ROHC framework 46 separately, and thus replaces the framework specification of RFC 47 3095. 49 Table of Contents 51 1. Introduction.....................................................3 52 2. Terminology......................................................4 53 2.1. Acronyms....................................................4 54 2.2. ROHC Terminology............................................4 55 3. Background (Informative).........................................6 56 3.1. Header Compression Fundamentals.............................7 57 3.2. A Short History of Header Compression.......................7 58 4. Overview of Robust Header Compression (ROHC) (Informative).......8 59 4.1. General Principles..........................................8 60 4.2. Compression Efficiency, Robustness and Transparency.........9 61 4.3. Developing the ROHC Protocol...............................10 62 4.4. Operational Characteristics of the ROHC Channel............11 63 4.5. Compression and Master Sequence Number (MSN)...............12 64 4.6. Static and Dynamic Parts of a Context......................13 65 5. The ROHC Framework (Normative)..................................13 66 5.1. The ROHC Channel...........................................13 67 5.1.1. Contexts and Context Identifiers......................13 68 5.1.2. Per-Channel Parameters................................14 69 5.1.3. Persistence of decompressor contexts..................15 70 5.2. ROHC Packets and Packet Types..............................15 71 5.2.1. General Format of ROHC Packets........................16 72 5.2.1.1. Format of the Padding Octet......................16 73 5.2.1.2. Format of the Add-CID Octet......................17 74 5.2.1.3. General Format of Header.........................17 75 5.2.2. Initialization and Refresh (IR) Packet Types..........18 76 5.2.2.1. ROHC IR Packet Type..............................18 77 5.2.2.2. ROHC IR-DYN Packet Type..........................19 78 5.2.3. ROHC Initial Decompressor Processing..................19 79 5.2.4. ROHC Feedback.........................................21 80 5.2.4.1. ROHC Feedback Format.............................21 81 5.2.5. ROHC Segmentation.....................................23 82 5.2.5.1. Segmentation Usage Considerations................23 83 5.2.5.2. Segmentation Protocol............................24 84 5.3. General Encoding Methods...................................25 85 5.3.1. Header Compression CRCs, Coverage and Polynomials.....25 86 5.3.1.1. 8-bit CRCs in IR and IR-DYN Headers..............25 87 5.3.1.2. 3-bit CRC in Compressed Headers..................25 88 5.3.1.3. 7-bit CRC in Compressed Headers..................26 89 5.3.1.4. 32-bit Segmentation CRC..........................26 90 5.3.2. Self-describing Variable-length Values................27 91 5.4. ROHC UNCOMPRESSED -- No Compression (Profile 0x0000)......27 92 5.4.1. IR Packet.............................................28 93 5.4.2. Normal Packet.........................................28 94 5.4.3. Decompressor Operation................................29 95 5.4.4. Feedback..............................................30 96 6. Overview of a ROHC Profile (Informative)........................30 97 7. Security Considerations.........................................31 98 8. IANA Considerations.............................................31 99 9. Acknowledgments.................................................32 100 10. References.....................................................32 101 10.1. Normative References......................................32 102 10.2. Informative References....................................33 103 11. Authors' Addresses.............................................34 104 Appendix A - CRC Algorithm.........................................35 106 1. Introduction 108 For many types of networks, reducing the deployment and operational 109 costs by improving the usage of the bandwidth resources is of vital 110 importance. Header compression over a link is possible because some 111 of the information carried within the header of a packet becomes 112 compressible between packets belonging to the same flow. 114 For links where the overhead of the IP header(s) is problematic, the 115 total size of the header may be significant. Applications carrying 116 data carried within RTP [13] will then, in addition to link layer 117 framing, have an IPv4 [10] header (20 octets), a UDP [12] header (8 118 octets), and an RTP header (12 octets) for a total of 40 octets. With 119 IPv6 [11], the IPv6 header is 40 octets for a total of 60 octets. 120 Applications transferring data using TCP [14] will have 20 octets for 121 the transport header, for a total size of 40 octets for IPv4 and 60 122 octets for IPv6. 124 The relative gain for specific flows (or applications) depends on the 125 size of the payload used in each packet. For applications such as 126 Voice-over-IP, where the size of the payload containing coded speech 127 can be as small as 15-20 octets, this gain will be quite significant. 128 Similarly, relative gains for TCP flows carrying large payloads (such 129 as file transfers) will be less than for flows carrying smaller 130 payloads (such as application signaling, e.g. session initiation). 132 As more and more wireless link technologies are being deployed to 133 carry IP traffic, care must be taken to address the specific 134 characteristics of these technologies within the header compression 135 algorithms. Legacy header compression schemes, such as those defined 136 in [16] and [17], have been shown to perform inadequately over links 137 where both the lossy behavior and the round-trip times are non- 138 negligible, such as those observed for example in wireless links and 139 IP tunnels. 141 In addition, a header compression scheme should handle the often non- 142 trivial residual errors, i.e. where the lower layer may pass a packet 143 that contains undetected bit errors to the decompressor. It should 144 also handle loss and reordering before the compression point, as well 145 as on the link between the compression and decompression points [7]. 147 The RObust Header Compression (ROHC) protocol provides an efficient, 148 flexible and future-proof header compression concept. It is designed 149 to operate efficiently and robustly over various link technologies 150 with different characteristics. 152 RFC 3095 [3] defines the ROHC framework along with an initial set of 153 compression profiles. To improve and simplify the specification, the 154 framework and the profiles parts have been split into separate 155 documents. This document explicitly defines the ROHC framework, and 156 thus replaces the framework specification of RFC 3095. 158 2. Terminology 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in [1]. 164 2.1. Acronyms 166 This section lists most acronyms used for reference. 168 ACK Acknowledgment. 169 CID Context Identifier. 170 CO Compressed packet format. 171 CRC Cyclic Redundancy Check. 172 IR Initialization and Refresh. 173 IR-DYN Initialization and Refresh, Dynamic part. 174 LSB Least Significant Bit(s). 175 MRRU Maximum Reconstructed Reception Unit. 176 MSB Most Significant Bit(s). 177 MSN Master Sequence Number. 178 NACK Negative Acknowledgment. 179 ROHC RObust Header Compression. 181 2.2. ROHC Terminology 183 Context 185 The context of the compressor is the state it uses to compress a 186 header. The context of the decompressor is the state it uses to 187 decompress a header. Either of these or the two in combination 188 are usually referred to as "context", when it is clear which is 189 intended. The context contains relevant information from previous 190 headers in the packet flow, such as static fields and possible 191 reference values for compression and decompression. Moreover, 192 additional information describing the packet flow is also part 193 of the context, for example information about the change behavior 194 of fields (e.g. the IP Identifier behavior, or the typical inter- 195 packet increase in sequence numbers and timestamps). 197 Context damage 199 When the context of the decompressor is not consistent with the 200 context of the compressor, decompression may fail to reproduce the 201 original header. This situation can occur when the context of the 202 decompressor has not been initialized properly or when packets 203 have been lost or damaged between compressor and decompressor. 205 Packets which cannot be decompressed due to inconsistent contexts 206 are said to be lost due to context damage. Packets that are 207 decompressed but contain errors due to inconsistent contexts are 208 said to be damaged due to context damage. 210 Context repair mechanism 212 Context repair mechanisms are used to resynchronize the contexts, 213 an important task since context damage causes loss propagation. 214 Examples of such mechanisms are NACK-based mechanisms, and the 215 periodic refreshes of important context information, usually 216 done in unidirectional operation. There are also mechanisms that 217 can reduce the context inconsistency probability, for example 218 repetition of the same type of information in multiple packets, 219 and CRCs that protect context-updating information. 221 CRC-8 validation 223 The CRC-8 validation refers to the validation of the integrity 224 against bit error(s) in a received IR and IR-DYN header, using the 225 8-bit CRC included in the IR/IR-DYN header. 227 CRC verification 229 The CRC verification refers to the verification of the result of a 230 decompression attempt, using the 3-bit CRC or 7-bit CRC included 231 in the header of a compressed packet format. 233 Damage propagation 235 Delivery of incorrect decompressed headers due to context damage, 236 i.e. due to errors in (i.e., loss of or damage to) previous 237 header(s) or feedback. 239 Error detection 241 Detection of errors by lower layers. If error detection is not 242 perfect, there will be residual errors. 244 Error propagation 246 Damage propagation or loss propagation. 248 ROHC profile 250 A ROHC profile is a compression protocol, which specifies how to 251 compress specific header combinations. A ROHC profile may be 252 tailored to handle a specific set of link characteristics, e.g. 254 loss characteristics, reordering between compression points, etc. 255 ROHC profiles provide the details of the header compression 256 framework defined in this document, and each compression profile 257 is associated with a unique ROHC profile identifier [21]. When 258 setting up a ROHC channel, the set of profiles supported by both 259 endpoints of the channel is negotiated, and when initializing new 260 contexts, a profile identifier from this negotiated set is used to 261 associate each compression context with one specific profile. 263 Link 265 A physical transmission path that constitutes a single IP hop. 267 Loss propagation 269 Loss of headers, due to errors in (i.e., loss of or damage to) 270 previous header(s) or feedback. 272 Packet flow 274 A sequence of packets where the field values and change patterns 275 of field values are such that the headers can be compressed using 276 the same context. 278 Residual error 280 Errors introduced during transmission and not detected by lower- 281 layer error detection schemes. 283 ROHC channel 285 A logical unidirectional point-to-point channel carrying ROHC 286 packets from one compressor to one decompressor, optionally 287 carrying ROHC feedback information on the behalf of another 288 compressor-decompressor pair operating on a separate ROHC channel 289 in the opposite direction. See also [5]. 291 This document also makes use of the conceptual terminology defined by 292 "ROHC Terminology and Channel Mapping Examples", RFC 3759 [5]. 294 3. Background (Informative) 296 This chapter provides a background to the subject of header 297 compression. The fundamental ideas are described together with a 298 discussion about the history of header compression schemes. The 299 motivations driving the development of the various schemes are 300 discussed, and their drawbacks identified, thereby providing the 301 foundations for the design of the ROHC framework and profiles [3]. 303 3.1. Header Compression Fundamentals 305 Header compression is possible because there is significant 306 redundancy between header fields; within the headers of a single 307 packet, but in particular between consecutive packets belonging to 308 the same flow. On the path end-to-end, the entire header information 309 is necessary for all packets in the flow, but over a single link some 310 of this information becomes redundant and can be reduced, as long as 311 it is transparently recovered at the receiving end of the link. The 312 header size can be reduced by first sending field information that is 313 expected to remain static for (at least most of) the lifetime of the 314 packet flow. Further compression is achieved for the fields carrying 315 information changing more dynamically by using compression methods 316 tailored to their respective assumed change behavior. 318 To achieve compression and decompression, some necessary information 319 from past packets is maintained in a context. The compressor and the 320 decompressor update their respective contexts upon certain, not 321 necessarily synchronized, events. Impairment events may lead to 322 inconsistencies in the decompressor context (i.e. context damage), 323 which in turn may cause incorrect decompression. A robust header 324 compression scheme needs mechanisms to minimize the possibility of 325 context damage, in combination with mechanisms for context repair. 327 3.2. A Short History of Header Compression 329 The first header compression scheme, CTCP [15], was introduced by Van 330 Jacobson. CTCP, also often referred to as VJ compression, compresses 331 the 40 octets of the TCP/IP header down to 4 octets. CTCP uses delta 332 encoding for sequentially changing fields. The CTCP compressor 333 detects transport-level retransmissions and sends a header that 334 updates the entire context when they occur. This repair mechanism 335 does not require any explicit signaling between compressor and 336 decompressor. 338 A general IP header compression scheme, IP header compression [16], 339 improves somewhat on CTCP. IPHC can compress arbitrary IP, TCP, and 340 UDP headers. When compressing non-TCP headers, IPHC does not use 341 delta encoding and is robust. The repair mechanism of CTCP is 342 augmented with negative acknowledgments, called CONTEXT_STATE 343 messages, which speeds up the repair. This context repair mechanism 344 is thus limited by the round-trip time of the link. IPHC does not 345 compress RTP headers. 347 CRTP [17] is an RTP extension to IPHC. CRTP compresses the 40 octets 348 of IPv4/UDP/RTP headers to a minimum of 2 octets when the UDP 349 Checksum is not enabled. If the UDP Checksum is enabled, the minimum 350 CRTP header is 4 octets. 352 On lossy links with long round-trip times, CRTP does not perform well 353 [20]. Each packet lost over the link causes decompression of several 354 subsequent packets to fail, because the context becomes invalidated 355 during at least one link round-trip time from the lost packet. 356 Unfortunately, the large headers that CRTP sends when updating the 357 context waste additional bandwidth. 359 CRTP uses a local repair mechanism known as TWICE, which was 360 introduced by IPHC. TWICE derives its name from the observation that 361 when the flow of compressed packets is regular, the correct guess 362 when one packet is lost between the compression points is to apply 363 the update in the current packet twice. While TWICE improves CRTP 364 performance significantly, [20] also found that even with TWICE, CRTP 365 doubled the number of lost packets. 367 An enhanced variant of CRTP, called eCRTP [19], means to improve the 368 robustness of CRTP in the presence of reordering and packet losses, 369 while keeping the protocol almost unchanged from CRTP. As a result, 370 eCRTP does provide better means to implement some degree of 371 robustness, albeit at the expense of additional overhead leading to a 372 reduction in compression efficiency in comparison to CRTP. 374 4. Overview of Robust Header Compression (ROHC) (Informative) 376 4.1. General Principles 378 As mentioned earlier, header compression is possible per link due to 379 the fact that there is much redundancy between header field values 380 within packets, and especially between consecutive packets belonging 381 to the same flow. To utilize these properties for header compression, 382 there are a few essential steps to consider. 384 The first step consists in identifying and grouping packets together 385 into different "flows", so that packet-to-packet redundancy is 386 maximized in order to improve the compression ratio. Grouping packets 387 into flows is usually based on source and destination host (IP) 388 addresses, transport protocol type (e.g. UDP or TCP), process (port) 389 numbers and potentially additional unique application identifiers, 390 such as the SSRC in RTP [13]. The compressor and the decompressor 391 each establish a context for the packet flow, and identify the 392 context with a CID included in each compressed header. 394 The second step is to understand the change patterns of the various 395 header fields. On a high level, header fields fall into one of the 396 following classes: 398 INFERRED These fields contain values that can be inferred from 399 other fields or external sources, for example the size 400 of the frame carrying the packet can often be derived 401 from the link layer protocol, and thus does not have 402 to be transmitted by the compression scheme. 404 STATIC Fields classified as STATIC are assumed to be constant 405 throughout the lifetime of the packet flow. The value 406 of each field is thus only communicated initially. 408 STATIC-DEF Fields classified as STATIC-DEF are used to define a 409 packet flow, as discussed above. Packets for which 410 respective values of these fields differ are treated 411 as belonging to different flows. These fields are in 412 general compressed as STATIC fields. 414 STATIC-KNOWN Fields classified as STATIC-KNOWN are expected to have 415 well-known values, and therefore their values do not 416 need to be communicated. 418 CHANGING These fields are expected to vary either randomly, 419 either within a limited value set or range, or in some 420 other manner. CHANGING fields are usually handled in 421 more sophisticated ways, based on a more detailed 422 classification of their expected change patterns. 424 Finally, the last step is to choose the encoding method(s) that will 425 be applied onto different fields, based on the classification. The 426 encoding methods, in combination with the identified field behavior, 427 provide the input to the design of the compressed header formats. The 428 analysis of the probability distribution of the identified change 429 patterns then provide the means to optimize the packet formats, where 430 the most frequently occurring change patterns for a field should be 431 encoded within the most efficient format(s). 433 However, compression efficiency has to be traded against two other 434 properties: the robustness of the encoding to losses and errors 435 between the compressor and the decompressor, and the ability to 436 detect and cope with errors in the decompression process. 438 4.2. Compression Efficiency, Robustness and Transparency 440 The performance of a header compression protocol can be described 441 with three parameters: its compression efficiency, its robustness and 442 its compression transparency. 444 Compression efficiency 446 The compression efficiency is determined by how much the average 447 header size is reduced by applying the compression protocol. 449 Robustness 451 A robust protocol tolerates packet losses, residual bit errors, and 452 out-of-order delivery on the link over which header compression 453 takes place, without losing additional packets or introducing 454 additional errors in decompressed headers. 456 Compression transparency 458 The compression transparency is a measure of the extent to which 459 the scheme maintains the semantics of the original headers. If all 460 decompressed headers are bitwise identical to the corresponding 461 original headers, the scheme is transparent. 463 4.3. Developing the ROHC Protocol 465 The challenge in developing a header compression protocol is to 466 conciliate compression efficiency and robustness, while maintaining 467 transparency, as increasing robustness will always come at the 468 expense of a lower compression efficiency, and vice-versa. The scheme 469 should also be flexible enough in its design to minimize the impacts 470 from the varying round-trip times and loss patterns of links where 471 header compression will be used. 473 To achieve this, the header compression scheme must provide 474 facilities for the decompressor to verify decompression and detect 475 potential context damage, as well as context recovery mechanisms such 476 as feedback. Header compression schemes prior to the ones developed 477 by the RObust Header Compression (ROHC) WG were not designed with the 478 above high-level objectives in mind. 480 The ROHC WG has developed header compression solutions to meet the 481 needs of today's and future link technologies. While special 482 attention has been put towards meeting the more stringent 483 requirements stemming out from the characteristics of wireless links, 484 the results are equally applicable to many other link technologies. 486 RFC 3095 [3], "RObust Header Compression (ROHC): Framework and four 487 profiles: RTP, UDP, ESP, and uncompressed", was published 2001, as 488 the first output of the ROHC WG. ROHC is a general and extendable 489 framework for header compression, on top of which profiles can be 490 defined for compression of different protocols headers. RFC 3095 491 introduced a number of new compression techniques, and was successful 492 at living up to the requirements placed on it, as described in [18]. 494 Interoperability testing of RFC 3095 confirms the capabilities of 495 ROHC to meet its purposes, but feedback from implementers has also 496 indicated that the protocol specification is complex and sometimes 497 obscure. Most importantly, a clear distinction between framework and 498 profiles is not obvious in [3], which also makes development of 499 additional profiles troublesome. This document therefore aims at 500 explicitly specifying the ROHC framework, while a companion document 501 [8] specifies revised versions of the compression profiles of RFC 502 3095. 504 4.4. Operational Characteristics of the ROHC Channel 506 Robust header compression can be used over many type of link 507 technologies. The ROHC framework provides flexibility for profiles to 508 address a wide range of applications, and this section lists some of 509 the operational characteristics of the ROHC channel (see also [5]). 511 Multiplexing over a single logical channel 513 The ROHC channel provides a mechanism to identify a context within 514 the general ROHC packet format. The Context Identifier (CID) makes 515 it possible for a logical channel that supports ROHC to transport 516 multiple header-compressed flows, while still making it possible 517 for a channel to be dedicated to one single packet flow without 518 any CID overhead. More specifically, ROHC uses a distinct context 519 identifier space per logical channel, and the context identifier 520 can be omitted for one of the flows over the ROHC channel when 521 configured to use a small CID space. 523 Establishment of channel parameters 525 A link layer defining support for the ROHC channel must provide 526 the means to establish header compression channel parameters (see 527 section 5.1). This can be achieved either through a negotiation 528 mechanism, static provisioning or some out-of-band signaling. 530 Packet type identification 532 The ROHC channel defines a packet type identifier space, and puts 533 restrictions with respect to the use of a number of identifiers 534 that are common for all ROHC profiles. Identifiers that have no 535 restrictions, i.e. identifiers that are not defined by this 536 document, are available to each profile. The identifier is part 537 of each compressed header, and this makes it possible for the link 538 that supports the ROHC channel to allocate one single link layer 539 payload type for ROHC. 541 Out-of-order delivery between compression endpoints 543 Each profile defines its own level of robustness, including 544 tolerance to reordering of packets before but especially between 545 compression endpoints, if any. 547 For profiles specified in [3], the channel between compressor and 548 decompressor is required to maintain in-order delivery of the 549 packets, i.e. the definition of these profiles assumes that the 550 decompressor always receives packets in the same order as the 551 compressor sent them. The impacts of reordering on the performance 552 of these profiles is described in [7]. Reordering before the 553 compression point, however, is handled, i.e. these profiles make 554 no assumption that the compressor will receive packets in-order. 556 For the ROHCv2 profiles specified in [8], their definition assume 557 that the decompressor can receive packets out-of-order, i.e. not 558 in the same order as the compressor sent them. Reordering before 559 the compression point is also dealt with. 561 Duplication of packets 563 The link supporting the ROHC channel is required to not duplicate 564 packets (duplication before the compression point, however, is 565 dealt with, i.e., there is no assumption that the compressor will 566 receive only one copy of each packet). 568 Framing 570 The link layer must provide framing that makes it possible to 571 distinguish frame boundaries and individual frames. 573 Error detection/protection 575 ROHC profiles should be designed to cope with residual errors in 576 the headers delivered to the decompressor. CRCs are used to detect 577 decompression failures and to prevent or reduce damage 578 propagation. However, it is recommended that lower layers deploy 579 error detection for ROHC headers and to not deliver ROHC headers 580 with high residual error rates. 582 4.5. Compression and Master Sequence Number (MSN) 584 Compression of header fields is based on the establishment of a 585 function to a sequence number, called the Master Sequence Number 586 (MSN). This function describes the change pattern of the field with 587 respect to a change in the MSN. 589 Change patterns include e.g. fields that increase monotonically or by 590 a small value, but also fields that seldom change as well as fields 591 that remain unchanging for the entire lifetime of the packet flow, in 592 which case the function to the MSN is equivalent to a constant value. 594 The compressor first establishes functions for each of the header 595 fields, and then reliably communicates the MSN. When the change 596 pattern of the field does not match the established function, i.e., 597 the existing function gives a result that is different from the field 598 in the header being compressed, additional information can be sent to 599 update the parameters of that function. 601 The MSN is defined per profile. It can be either derived directly 602 from one of the fields of the protocol being compressed (e.g. the RTP 603 SN [8]), or it can be created and maintained by the compressor (e.g. 604 the MSN for compression of UDP in profile 0x0102 [8] or the MSN in 605 ROHC-TCP [9]). 607 4.6. Static and Dynamic Parts of a Context 609 A compression context can be conceptually divided into two different 610 parts, the static context and the dynamic context, each based on the 611 properties of the fields that are being compressed. 613 The static part includes the information necessary to compress and 614 decompress the fields whose change behavior is classified as STATIC, 615 STATIC-KNOWN or STATIC-DEF (as described in section 4.1 above). 617 The dynamic part includes the state maintained for all the other 618 fields, i.e. those that are classified as CHANGING. 620 5. The ROHC Framework (Normative) 622 This section normatively defines the parts common to all ROHC 623 profiles, i.e. the framework. The framework specifies the 624 requirements and functionality of the ROHC channel, including how to 625 handle multiple compressed packet flows over the same channel. 627 Finally, this section specifies encoding methods used in the packet 628 formats that are common to all profiles. These encoding methods may 629 be reused within profile specifications for encoding fields in 630 profile-specific parts of a packet format, without requiring their 631 redefinition. 633 5.1. The ROHC Channel 635 5.1.1. Contexts and Context Identifiers 637 Associated with each compressed flow is a context. The context is the 638 state that the compressor and the decompressor maintain in order to 639 correctly compress or decompress the headers of the packet in the 640 flow. Each context is identified using a Context Identifier (CID). 642 A context is considered to be a new context when the CID is 643 associated with a profile for the first time since the creation of 644 the ROHC channel, or when the CID gets associated from the reception 645 of an IR (this does not apply to the IR-DYN) with a different profile 646 than the profile in the context. 648 Context information is conceptually kept in a table. The context 649 table is indexed using the CID, which is sent along with compressed 650 headers and feedback information. 652 The CID space can be either small, which means that CIDs can take the 653 values 0 through 15, or large, which means that CIDs take values 654 between 0 and 2^14 - 1 = 16383. Whether the CID space is large or 655 small MUST be established, possibly by negotiation, before any 656 compressed packet may be sent over the ROHC channel. 658 The CID space is distinct for each channel, i.e., CID 3 over channel 659 A and CID 3 over channel B do not refer to the same context, even if 660 the endpoints of A and B are the same nodes. In particular, CIDs for 661 any pair of ROHC channels are not related (two associated ROHC 662 channels serving as feedback channels for one another do not even 663 need to have CID spaces of the same size). 665 5.1.2. Per-Channel Parameters 667 The ROHC channel is based on a number of parameters that form part of 668 the established channel state and the per-context state. The state of 669 the ROHC channel MUST be established before the first ROHC packet may 670 be sent, which may be achieved using negotiation protocols provided 671 by the link layer (see also [4], which describes an option for 672 negotiation of ROHC parameters for PPP). This section describes some 673 of this channel state information in an abstract way: 675 LARGE_CIDS: Boolean; if false, the short CID representation (0 octets 676 or 1 prefix octet, covering CID 0 to 15) is used; if true, the 677 embedded CID representation (1 or 2 embedded CID octets covering 678 CID 0 to 16383) is used. See also 5.1.1 and 5.2.1.3. 680 MAX_CID: Non-negative integer; highest CID number to be used by the 681 compressor (note that this parameter is not coupled to, but in 682 effect further constrained by, LARGE_CIDS). This value represents 683 an agreement by the decompressor that it can provide sufficient 684 memory resources to host at least MAX_CID+1 contexts; the 685 decompressor MUST maintain established contexts within this space 686 until either the CID gets re-used by the establishment of a new 687 context, or until the channel is taken down. 689 PROFILES: Set of non-negative integers, where each integer indicates 690 a profile supported by both the compressor and the decompressor. A 691 profile is identified by a 16-bit value, where the 8 LSB bits 692 indicate the actual profile, and the 8 MSB bits indicate the 693 variant of that profile. The ROHC compressed header format 694 identifies the profile used with only the 8 LSB bits; this means 695 that if multiple variants of the same profile are available for a 696 ROHC channel, the PROFILES set after negotiation MUST NOT include 697 more than one variant of the same profile. The compressor MUST NOT 698 compress using a profile not in PROFILES. 700 FEEDBACK_FOR: Optional reference to a ROHC channel in the opposite 701 direction between the same compression endpoints. If provided, 702 this parameter indicates which other ROHC channel any feedback 703 sent on this ROHC channel refers to (see [5]). 705 MRRU: Non-negative integer. Maximum reconstructed reception unit. 706 This is the size of the largest reconstructed unit in octets that 707 the decompressor is expected to reassemble from segments (see 708 5.2.5). This size includes the segmentation CRC. If MRRU is 709 negotiated to be 0, segmentation MUST NOT be used on the channel, 710 and received segments MUST be discarded by the decompressor. 712 5.1.3. Persistence of decompressor contexts 714 As part of the negotiated channel parameters, compressor and 715 decompressor have through the MAX_CID parameter agreed on the highest 716 context identification (CID) number to be used. By agreeing on 717 MAX_CID, the decompressor also agrees to provide memory resources to 718 host at least MAX_CID+1 contexts, and an established context with a 719 CID within this negotiated space SHOULD be kept by the decompressor 720 until either the CID gets re-used, or the channel is taken down or 721 re-negotiated. 723 5.2. ROHC Packets and Packet Types 725 This section uses the following convention in the diagrams when 726 representing various ROHC packet types, formats and fields: 728 - colons ":" indicate that the part is optional 729 - slashes "/" indicate variable length 731 The ROHC packet type indication scheme has been designed to provide 732 optional padding, a feedback packet type, an optional Add-CID octet 733 (which include 4 bits of CID), and a simple segmentation and 734 reassembly mechanism. 736 The following packet types are reserved at the ROHC framework level: 738 11100000 : Padding 739 1110nnnn : Add-CID octet (nnnn=CID with values 0x1 through 0xF) 740 11110 : Feedback 741 11111000 : IR-DYN packet 742 1111110 : IR packet 743 1111111 : Segment 745 Other packet types can be defined and used by individual profiles: 747 0 : available (not reserved by ROHC framework) 748 10 : available (not reserved by ROHC framework) 749 110 : available (not reserved by ROHC framework) 750 1111101 : available (not reserved by ROHC framework) 751 11111001 : available (not reserved by ROHC framework) 753 5.2.1. General Format of ROHC Packets 755 A ROHC packet has the following general format: 757 --- --- --- --- --- --- --- --- 758 : Padding : 759 --- --- --- --- --- --- --- --- 760 : Feedback : 761 --- --- --- --- --- --- --- --- 762 : Header : 763 --- --- --- --- --- --- --- --- 764 : Payload : 765 --- --- --- --- --- --- --- --- 767 Padding: Any number (zero or more) of padding octets, where the 768 format of a padding octet is as defined in 5.2.1.1. 770 Feedback: Any number (zero or more) of feedback elements, where the 771 format of a feedback element is as defined in 5.2.4.1. 773 Header: Either a profile-specific CO header (see section 5.2.1.3), an 774 IR or IR-DYN header (see section 5.2.2), or a ROHC Segment (see 775 section 5.2.5). There can be at most one Header in a ROHC packet, 776 but it may also be omitted (if the packet contains Feedback only). 778 Payload: Corresponds to zero or more octets of payload from the 779 uncompressed packet, starting with the first octet in the 780 uncompressed packet after the last header compressible by the 781 current profile. 783 At least one of Feedback or Header MUST be present. 785 5.2.1.1. Format of the Padding Octet 787 Padding octet: 789 0 1 2 3 4 5 6 7 790 +---+---+---+---+---+---+---+---+ 791 | 1 1 1 0 0 0 0 0 | 792 +---+---+---+---+---+---+---+---+ 794 Note: The Padding octet MUST NOT be interpreted as an Add-CID 795 octet for CID 0. 797 5.2.1.2. Format of the Add-CID Octet 799 Add-CID octet: 801 0 1 2 3 4 5 6 7 802 +---+---+---+---+---+---+---+---+ 803 | 1 1 1 0 | CID | 804 +---+---+---+---+---+---+---+---+ 806 CID: 0x1 through 0xF indicates CIDs 1 through 15. 808 Note: The Padding octet looks like an Add-CID octet for CID 0. 810 5.2.1.3. General Format of Header 812 All ROHC packet types have the following general Header format: 814 0 x-1 x 7 815 --- --- --- --- --- --- --- --- 816 : Add-CID octet : if CID 1-15 and small CIDs 817 +--- --- --- --- ---+--- --- ---+ 818 | type indication | body | 1 octet (8-x bits of body) 819 +--- --- --- --- ---+--- --- ---+ 820 : : 821 / 0, 1, or 2 octets of CID / 1 or 2 octets if large CIDs 822 : : 823 +---+---+---+---+---+---+---+---+ 824 / body / variable length 825 +---+---+---+---+---+---+---+---+ 827 type indication: ROHC packet type. 829 body: Interpreted according to the packet type indication and CID 830 information, as defined by individual profiles. 832 Header thus either starts with a packet type indication or has a 833 packet type indication immediately following an Add-CID octet. 835 When the ROHC channel is configured with a small CID space: 837 o If an Add-CID immediately precedes the packet type indication, 838 the packet has the CID of the Add-CID; otherwise it has CID 0. 840 o A small CID with the value 0 is represented using zero bits; 841 therefore a flow associated with CID 0 has no CID overhead in 842 the compressed header. In such case, Header starts with a 843 packet type indication. 845 o A small CID with a value from 1 to 15 is represented using the 846 Add-CID octet as described above. Header starts with the Add- 847 CID octet, followed by a packet type indication. 849 o There is no large CID in the Header. 851 When the ROHC channel is configured with a large CID space: 853 o The large CID is always present and is represented using the 854 encoding scheme of section 5.3.2, limited to two octets. In 855 this case, Header starts with a packet type indication. 857 5.2.2. Initialization and Refresh (IR) Packet Types 859 IR packet types contain a profile identifier, which determines how 860 the rest of the header is to be interpreted. They also associate a 861 profile with a context. The stored profile parameter further 862 determines the syntax and semantics of the packet type identifiers 863 and packet types used with a specific context. 865 The IR and IR-DYN packets always update the context for all context- 866 updating fields carried in the header. They never clear the context, 867 except when initializing a new context (see section 5.1.1), or unless 868 the profile indicated in the Profile field specifies otherwise. 870 5.2.2.1. ROHC IR Packet Type 872 The IR header associates a CID with a profile, and typically also 873 initializes the context. It can typically also refresh all (or parts 874 of) the context. For IR, Header has the following general format: 876 0 1 2 3 4 5 6 7 877 --- --- --- --- --- --- --- --- 878 : Add-CID octet : if CID 1-15 and small CID 879 +---+---+---+---+---+---+---+---+ 880 | 1 1 1 1 1 1 0 | x | IR type octet 881 +---+---+---+---+---+---+---+---+ 882 : : 883 / 0-2 octets of CID / 1 or 2 octets if large CIDs 884 : : 885 +---+---+---+---+---+---+---+---+ 886 | Profile | 1 octet 887 +---+---+---+---+---+---+---+---+ 888 | CRC | 1 octet 889 +---+---+---+---+---+---+---+---+ 890 | | 891 / profile specific information / variable length 892 | | 893 +---+---+---+---+---+---+---+---+ 895 x: Profile specific information. Interpreted according to the 896 profile indicated in the Profile field of the IR header. 898 Profile: The profile associated with the CID. In the IR header, the 899 profile identifier is abbreviated to the 8 least significant bits 900 (see section 5.1.2). 902 CRC: 8-bit CRC (see section 5.3.1.1). 904 Profile specific information: The content of this part of the IR 905 header is defined by the individual profiles. It is interpreted 906 according to the profile indicated in the Profile field. 908 5.2.2.2. ROHC IR-DYN Packet Type 910 In contrast to the IR header, the IR-DYN header can never initialize 911 an non-initialized context. However, it can redefine what profile is 912 associated with a context, if the profile indicated in the IR-DYN 913 header allows this. Thus this packet type is also reserved at the 914 framework level. The IR-DYN header typically also initializes or 915 refreshes parts of a context. For IR-DYN, Header has the following 916 general format: 918 0 1 2 3 4 5 6 7 919 --- --- --- --- --- --- --- --- 920 : Add-CID octet : if CID 1-15 and small CID 921 +---+---+---+---+---+---+---+---+ 922 | 1 1 1 1 1 0 0 0 | IR-DYN type octet 923 +---+---+---+---+---+---+---+---+ 924 : : 925 / 0-2 octets of CID / 1 or 2 octets if large CIDs 926 : : 927 +---+---+---+---+---+---+---+---+ 928 | Profile | 1 octet 929 +---+---+---+---+---+---+---+---+ 930 | CRC | 1 octet 931 +---+---+---+---+---+---+---+---+ 932 | | 933 / profile specific information / variable length 934 | | 935 +---+---+---+---+---+---+---+---+ 937 Profile: The profile associated with the CID. This is abbreviated in 938 the same way as in IR packets. 940 CRC: 8-bit CRC (see section 5.3.1.1). 942 Profile specific information: The content of this part of the IR-DYN 943 header is defined by the individual profiles. It is interpreted 944 according to the profile indicated in the Profile field. 946 5.2.3. ROHC Initial Decompressor Processing 948 Initially, all contexts are in no context state. Thus, all packets 949 referencing an non-initialized context, except packets that have 950 enough information on the static fields, can not be decompressed by 951 the decompressor. 953 When the decompressor receives a packet of type IR, the profile 954 indicated in the IR packet determines how it is to be processed. 956 o If the 8-bit CRC fails to verify the integrity of the Header, 957 the packet MUST NOT be decompressed and delivered to upper 958 layers. If a profile is indicated in the context, the logic of 959 that profile determines what, if any, feedback is to be sent. If 960 no profile is noted in the context, the logic used to determine 961 what, if any, feedback to send is up to the implementation. 962 However, it may be suitable to take no further actions as any 963 part of the IR header covered by the CRC may have caused the 964 failure. 966 When the decompressor receives a packet of type IR-DYN, the profile 967 indicated in the IR-DYN packet determines how it is to be processed. 969 o If the 8-bit CRC fails to verify the integrity of the header, 970 the packet MUST NOT be decompressed and delivered to upper 971 layers. If a profile is indicated in the context, the logic of 972 that profile determines what, if any, feedback is to be sent. If 973 no profile is noted in the context, the logic used to determine 974 what, if any, feedback to send is up to the implementation. 975 However, it may be suitable to take no further actions as any 976 part of the IR-DYN header covered by the CRC may have caused the 977 failure. 979 o If the context has not already been initialized, the packet MUST 980 NOT be decompressed and delivered to upper layers. The logic of 981 the profile indicated in the IR-DYN header (if verified by the 982 8-bit CRC), determines what, if any, feedback is to be sent. 984 If a parsing error occurs for any packet type, the decompressor MUST 985 discard the packet without further processing. For example, a CID 986 field is present in the compressed header when the large CID space is 987 used for the ROHC channel, and the field is coded using the self- 988 describing variable-length encoding of section 5.3.2; if the field 989 starts with 110 or 111, this would generate a parsing error for the 990 decompressor because this field must not be encoded with a size 991 larger than 2 octets. 993 It is RECOMMENDED that profiles disallow the decompressor to make a 994 decompression attempt for packets carrying only a 3-bit CRC after it 995 has invalidated some or the entire dynamic context, until a packet 996 that contains sufficient information on the dynamic fields is 997 received, decompressed and successfully verified by a 7- or an 8-bit 998 CRC. 1000 5.2.4. ROHC Feedback 1002 Feedback carries information from decompressor to compressor. 1003 Feedback can be sent over a ROHC channel that operates in the same 1004 direction as the feedback. 1006 The general ROHC packet format allows transport of feedback using 1007 interspersion or piggybacking (see [5]), or a combination of both, 1008 over a ROHC channel. This is facilitated by the following properties: 1010 Reserved packet type: 1012 A feedback packet type is reserved at the framework level. The 1013 packet type can carry variable-length feedback information. 1015 CID information: 1017 The feedback information sent on a particular channel is passed 1018 to, and interpreted by, the compressor associated with feedback on 1019 that channel. Thus, each feedback element contains CID 1020 information from the channel for which the feedback is sent. The 1021 ROHC feedback scheme thus requires that a channel carries feedback 1022 to at most one compressor. How a compressor is associated with the 1023 feedback for a particular channel is outside the scope of this 1024 specification. See also [5]. 1026 Length information: 1028 The length of a feedback element can be determined by examining 1029 the first few octets of the feedback. This enables piggybacking of 1030 feedback, and also the concatenation of more than one feedback 1031 element in a packet. The length information thus decouples the 1032 decompressor from the associated same-side compressor, as the 1033 decompressor can extract the feedback information from the 1034 compressed header without parsing its content, and hand over the 1035 extracted information. 1037 The association between compressor-decompressor pairs operating in 1038 opposite directions, for the purpose of exchanging piggyback and/or 1039 interspersed feedback, SHOULD be maintained for the lifetime of the 1040 ROHC channel. Otherwise, it is RECOMMENDED that the compressor be 1041 notified if the feedback channel is no longer available: the 1042 compressor SHOULD then restart compression by creating a new context 1043 for each packet flow, and SHOULD use a CID value that was not 1044 previously associated with the profile used to compress the flow. 1046 5.2.4.1. ROHC Feedback Format 1048 ROHC defines three different categories of feedback messages: 1049 acknowledgment (ACK), negative ACK (NACK) and NACK for the entire 1050 context (STATIC-NACK). Other type of information may be defined in 1051 profile-specific feedback information. 1053 ACK : Acknowledges successful decompression of a packet. 1054 Indicates that the decompressor considers its context 1055 to be valid. 1057 NACK : Indicates that the decompressor considers some or all 1058 of the dynamic part of its context invalid. 1060 STATIC-NACK : Indicates that the decompressor considers its entire 1061 static context invalid, or that it has not been 1062 established. 1064 Feedback sent on a ROHC channel consists of one or more concatenated 1065 feedback elements, where each feedback element has the following 1066 format: 1068 0 1 2 3 4 5 6 7 1069 +---+---+---+---+---+---+---+---+ 1070 | 1 1 1 1 0 | Code | feedback type 1071 +---+---+---+---+---+---+---+---+ 1072 : Size : if Code = 0 1073 +---+---+---+---+---+---+---+---+ 1074 : Add-CID octet : if for small CIDs and (CID != 0) 1075 +---+---+---+---+---+---+---+---+ 1076 : : 1077 / large CID (5.3.2 encoding) / 1-2 octets if for large CIDs 1078 : : 1079 +---+---+---+---+---+---+---+---+ 1080 / FEEDBACK data / variable length 1081 +---+---+---+---+---+---+---+---+ 1083 Code: 0 indicates that a Size octet is present. 1084 1-7 indicates the size of the feedback data field, in 1085 octets. 1087 Size: Indicates the size of the feedback data field, in octets. 1089 FEEDBACK data: FEEDBACK-1 or FEEDBACK-2 (see below). 1091 CID information in a feedback element indicates the context for which 1092 feedback is sent. The LARGE_CIDS parameter that controls whether a 1093 large CID is present is taken from the channel state of the receiving 1094 compressor's channel, not from the state of the channel carrying the 1095 feedback. 1097 The large CID field, if present, is encoded according to section 1098 5.3.2, and it MUST NOT be encoded using more than 2 octets. 1100 The FEEDBACK data field can have either of the following two formats: 1102 FEEDBACK-1: 1104 0 1 2 3 4 5 6 7 1105 +---+---+---+---+---+---+---+---+ 1106 | profile specific information | 1 octet 1107 +---+---+---+---+---+---+---+---+ 1109 FEEDBACK-2: 1111 0 1 2 3 4 5 6 7 1112 +---+---+---+---+---+---+---+---+ 1113 |Acktype| | 1114 +---+---+ profile specific / at least 2 octets 1115 / information | 1116 +---+---+---+---+---+---+---+---+ 1118 Acktype: 0 = ACK 1119 1 = NACK 1120 2 = STATIC-NACK 1121 3 is reserved (MUST NOT be used. Otherwise unparseable.) 1123 5.2.5. ROHC Segmentation 1125 ROHC defines a simple segmentation protocol. The compressor may 1126 perform segmentation e.g. to accommodate packets that are larger than 1127 a specific size configured for the channel. 1129 5.2.5.1. Segmentation Usage Considerations 1131 The ROHC segmentation protocol is not particularly efficient. It is 1132 not intended to replace link layer segmentation functions; these 1133 SHOULD be used whenever available and efficient for the task at hand. 1135 The ROHC segmentation protocol has been designed with an assumption 1136 of in-order delivery of packets between the compressor and the 1137 decompressor, using only a CRC for error detection, and no sequence 1138 numbers. If in-order delivery cannot be guaranteed, ROHC segmentation 1139 MUST NOT be used. 1141 The segmentation protocol also assumes all segments of a ROHC packet 1142 corresponding to one context are received without interference from 1143 other ROHC packets over the channel, including any ROHC packet 1144 corresponding to a different context. Based on this assumption, 1145 segments do not carry CID information, and can therefore not be 1146 associated with a specific context until all segments have been 1147 received and the whole unit has been reconstructed. 1149 5.2.5.2. Segmentation Protocol 1151 ROHC segmentation is applied to the combination of the Header and the 1152 Payload fields of the ROHC packet, as defined in section 5.2.1. 1154 Segment format: 1156 0 1 2 3 4 5 6 7 1157 +---+---+---+---+---+---+---+---+ 1158 | 1 1 1 1 1 1 1 | F | segment type 1159 +---+---+---+---+---+---+---+---+ 1160 / Segment / variable length 1161 +---+---+---+---+---+---+---+---+ 1163 F: Final bit. If set, it indicates that this is the last segment of 1164 a reconstructed unit. 1166 Padding and/or Feedback may precede the segment type octet. There is 1167 no per-segment CID, but CID information is of course part of the 1168 reconstructed unit. The reconstructed unit MUST NOT contain padding, 1169 segments or feedback. 1171 When a final segment is received, the decompressor reassembles the 1172 segment carried in this packet and any non-final segments that 1173 immediately preceded it into a single reconstructed unit, in the 1174 order they were received. All segments for one reconstructed unit 1175 have to be received consecutively and in the correct order by the 1176 decompressor. If a non-segment ROHC packet directly follows a non- 1177 final segment, the reassembly of the current reconstructed unit is 1178 aborted and the decompressor MUST discard the non-final segments so 1179 far received on this channel. 1181 Reconstructed unit: 1183 0 1 2 3 4 5 6 7 1184 +---+---+---+---+---+---+---+---+ 1185 / Header / (see section 5.2.1) 1186 +---+---+---+---+---+---+---+---+ 1187 : Payload : (see section 5.2.1) 1188 +---+---+---+---+---+---+---+---+ 1189 / CRC / 4 octets 1190 +---+---+---+---+---+---+---+---+ 1192 CRC: 32-bit CRC computed using the polynomial of section 5.3.1.4. 1194 If the reconstructed unit is 4 octets or less, or if the CRC fails, 1195 or if it is larger than the channel parameter MRRU (see 5.1.2), the 1196 reconstructed unit MUST be discarded by the decompressor. If the CRC 1197 succeeds, the reconstructed unit can be further processed. 1199 5.3. General Encoding Methods 1201 5.3.1. Header Compression CRCs, Coverage and Polynomials 1203 This chapter describes how to calculate the CRCs used by ROHC. For 1204 all CRCs, the algorithm used to calculate the CRC is the same as the 1205 one used in [2], defined in appendix A of this document, with the 1206 polynomials specified in subsequent sections. 1208 5.3.1.1. 8-bit CRCs in IR and IR-DYN Headers 1210 The coverage for the 8-bit CRC in IR and IR-DYN headers is profile- 1211 dependent, but it MUST cover at least the initial part of the header 1212 ending with the profile field, including CID or an Add-CID octet. 1213 Feedback and padding are not part of Header (section 5.2.1) and are 1214 thus not included in the CRC calculation. As a rule of thumb for 1215 profile specifications, any other information which initializes the 1216 decompressor context SHOULD also be covered by a CRC. 1218 More specifically, the 8-bit CRC does not cover only and entirely the 1219 original uncompressed header; therefore it does not provide the means 1220 for the decompressor to verify a decompression attempt, or either the 1221 means to verify the correctness of the entire decompressor context. 1222 However, when successful, it does provide enough robustness for the 1223 decompressor to update its context with the information carried 1224 within the IR or the IR-DYN header. 1226 The CRC polynomial for the 8-bit CRC is: 1228 C(x) = 1 + x + x^2 + x^8 1230 When computing the CRC, the CRC field in the header is set to zero, 1231 and the initial content of the CRC register is set to all 1's. 1233 5.3.1.2. 3-bit CRC in Compressed Headers 1235 The 3-bit CRC in compressed headers is calculated over all octets of 1236 the entire original header, before compression, in the following 1237 manner. 1239 The initial content of the CRC register is set to all 1's. 1241 The polynomial for the 3-bit CRC is: 1243 C(x) = 1 + x + x^3 1245 The purpose of the 3-bit CRC is to provide the means for the 1246 decompressor to verify the outcome of a decompression attempt for 1247 small compressed headers, and to detect context damage based on 1248 aggregated probability over a number of decompression attempts. It is 1249 however too weak to provide enough success guarantees from the 1250 decompression of one single header. Therefore, compressed headers 1251 carrying a 3-bit CRC are normally not suitable to perform context 1252 repairs at the decompressor; hence profiles should refrain from 1253 allowing decompression of such header when some or the entire 1254 decompressor context is assumed invalid. 1256 5.3.1.3. 7-bit CRC in Compressed Headers 1258 The 7-bit CRC in compressed headers is calculated over all octets of 1259 the entire original header, before compression, in the following 1260 manner. 1262 The initial content of the CRC register is set to all 1's. 1264 The polynomial for the 7-bit CRC is: 1266 C(x) = 1 + x + x^2 + x^3 + x^6 + x^7 1268 The purpose of the 7-bit CRC is to provide the means for the 1269 decompressor to verify the outcome of a decompression attempt for a 1270 larger compressed header, and to provide enough protection to 1271 validate a context repair at the decompressor. The 7-bit CRC is 1272 strong enough to assume a repair to be successful from the 1273 decompression of one single header; hence profiles may allow 1274 decompression of a header carrying a 7-bit CRC when some of the 1275 decompressor context is assumed invalid. 1277 5.3.1.4. 32-bit Segmentation CRC 1279 The 32-bit CRC is used by the segmentation scheme to verify the 1280 reconstructed unit, and it is thus calculated over the segmented 1281 unit, i.e. over the Header and the Payload fields of the ROHC packet. 1283 The initial content of the CRC register is set to all 1's. 1285 The polynomial for the 32-bit CRC is: 1287 C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 + 1288 x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32. 1290 The purpose of the 32-bit CRC is to verify the reconstructed unit. 1292 5.3.2. Self-describing Variable-length Values 1294 The values of many fields and compression parameters can vary widely. 1295 To optimize the transfer of such values, a variable number of octets 1296 are used to encode them. The first few bits of the first octet 1297 determine the number of octets used: 1299 First bit is 0: 1 octet. 1300 7 bits transferred. 1301 Up to 127 decimal. 1302 Encoded octets in hexadecimal: 00 to 7F 1304 First bits are 10: 2 octets. 1305 14 bits transferred. 1306 Up to 16 383 decimal. 1307 Encoded octets in hexadecimal: 80 00 to BF FF 1309 First bits are 110: 3 octets. 1310 21 bits transferred. 1311 Up to 2 097 151 decimal. 1312 Encoded octets in hexadecimal: C0 00 00 to DF FF FF 1314 First bits are 111: 4 octets. 1315 29 bits transferred. 1316 Up to 536 870 911 decimal. 1317 Encoded octets in hexadecimal: E0 00 00 00 to FF FF FF FF 1319 5.4. ROHC UNCOMPRESSED -- No Compression (Profile 0x0000) 1321 This section describes the uncompressed ROHC profile. The profile 1322 identifier for this profile is 0x0000. 1324 Profile 0x0000 provides a way to send IP packets without compressing 1325 them. This can be used for any packet for which a compression profile 1326 is not available in the set of profiles supported by the ROHC 1327 channel, or for which compression is not desirable for some reason. 1329 After initialization, the only overhead for sending packets using 1330 Profile 0x0000 is the size of the CID. When uncompressed packets are 1331 frequent, Profile 0x0000 should be associated with a CID with size 1332 zero or one octet. Profile 0x0000 SHOULD be associated with at most 1333 one CID. 1335 5.4.1. IR Packet 1337 The initialization packet (IR packet) for Profile 0x0000 has the 1338 following Header format: 1340 0 1 2 3 4 5 6 7 1341 --- --- --- --- --- --- --- --- 1342 : Add-CID octet : if for small CIDs and (CID != 0) 1343 +---+---+---+---+---+---+---+---+ 1344 | 1 1 1 1 1 1 0 |res| 1345 +---+---+---+---+---+---+---+---+ 1346 : : 1347 / 0-2 octets of CID info / 1-2 octets if for large CIDs 1348 : : 1349 +---+---+---+---+---+---+---+---+ 1350 | Profile = 0x00 | 1 octet 1351 +---+---+---+---+---+---+---+---+ 1352 | CRC | 1 octet 1353 +---+---+---+---+---+---+---+---+ 1355 res: MUST be set to zero; otherwise the decompressor MUST discard the 1356 packet. 1358 Profile: 0x00 1360 CRC: 8-bit CRC, computed using the polynomial of section 1361 5.3.1.1. The CRC covers the first octet of the IR Header 1362 through the Profile octet of the IR Header, i.e., it does not 1363 cover the CRC itself. Neither does it cover any preceding 1364 Padding or Feedback, nor the Payload. 1366 For the IR packet, Payload has the following format: 1368 --- --- --- --- --- --- --- --- 1369 : : (optional) 1370 / IP packet / variable length 1371 : : 1372 --- --- --- --- --- --- --- --- 1374 IP packet: An uncompressed IP packet may be included in the IR 1375 packet. The decompressor determines if the IP packet is 1376 present by considering the length of the IR packet. 1378 5.4.2. Normal Packet 1380 A Normal packet is a normal IP packet plus CID information. For the 1381 Normal Packet, the following format corresponds to Header and Payload 1382 (as defined in section 5.2.1): 1384 0 1 2 3 4 5 6 7 1385 --- --- --- --- --- --- --- --- 1386 : Add-CID octet : if for small CIDs and (CID != 0) 1387 +---+---+---+---+---+---+---+---+ 1388 | first octet of IP packet | 1389 +---+---+---+---+---+---+---+---+ 1390 : : 1391 / 0-2 octets of CID info / 1-2 octets if for large CIDs 1392 : : 1393 +---+---+---+---+---+---+---+---+ 1394 | | 1395 / rest of IP packet / variable length 1396 | | 1397 +---+---+---+---+---+---+---+---+ 1399 Note that the first octet of the IP packet starts with the bit 1400 pattern 0100 (IPv4) or 0110 (IPv6). This does not conflict with any 1401 reserved packet types. 1403 When the channel uses small CIDs, and profile 0x0000 is associated 1404 with a CID > 0, an Add-CID octet precedes the IP packet. When the 1405 channel uses large CIDs, the CID is placed so that it starts at the 1406 second octet of the combined Header/Payload format above. 1408 A Normal Packet may carry Padding and/or Feedback as any other ROHC 1409 packet, preceding the combined Header/Payload. 1411 5.4.3. Decompressor Operation 1413 When an IR packet is received, the decompressor first validates its 1414 header using the 8-bit CRC. 1416 o If the header fails validation, the decompressor MUST NOT deliver 1417 the IP packet to upper layers. 1419 o If the header is successfully validated, the decompressor; 1421 1) initializes the context if it has no valid context for the 1422 given CID already associated to the specified profile, 1424 2) delivers the IP packet to upper layers if present, 1426 3) MAY send an ACK. 1428 When any other packet is received while the decompressor has no 1429 context, it is discarded without further action. 1431 When a Normal packet is received and the decompressor has a valid 1432 context, the IP packet is extracted and delivered to upper layers. 1434 5.4.4. Feedback 1436 The only kind of feedback defined by Profile 0x0000 is ACK, using the 1437 FEEDBACK-1 format of section 5.2.4.1, where the value of the profile- 1438 specific octet in the FEEDBACK-1 is 0 (zero). The FEEDBACK-2 format 1439 is thus not defined for Profile 0x0000. 1441 6. Overview of a ROHC Profile (Informative) 1443 The ROHC protocol consists of a framework part and a profile part. 1444 The framework defines the mechanisms common to all profiles, while 1445 the profile defines the compression algorithm and profile specific 1446 packet formats. 1448 Section 5 specified the details of the ROHC framework. This section 1449 provides an informative overview of the elements that make a profile 1450 specification. The normative specification of individual profiles is 1451 outside the scope of this document. 1453 A ROHC profile defines the elements that build up the compression 1454 protocol. A ROHC profile consists of: 1456 Packet formats: 1458 o Bits-on-the-wire 1460 The profile defines the layout of the bits for profile-specific 1461 packet types that it defines, and for the profile-specific parts 1462 of packet types common to all profiles (e.g. IR and IR-DYN). 1464 o Field encodings 1466 Bits and groups of bits from the packet format layout, referred 1467 to as compressed fields, represents the result of an encoding 1468 method specific for that compressed field within a specific 1469 packet format. The profile defines these encoding methods. 1471 o Updating properties 1473 The profile-specific packet formats may update the state of the 1474 decompressor, and may do so in different ways. The profile 1475 defines how individual profile-specific fields, or entire 1476 profile-specific packet types, update the decompressor context. 1478 o Verification 1480 Packets that update the state of the decompressor are verified, 1481 to prevent incorrect updates to the decompressor context. The 1482 profile defines the mechanisms used to verify the decompression 1483 of a packet. 1485 Context management: 1487 o Robustness logic 1489 Packets may be lost or reordered between the compressor and the 1490 decompressor. The profile defines mechanism to minimize the 1491 impacts of such events, and prevent damage propagation. 1493 o Repair mechanism 1495 Despite the robustness logic, impairment events may still lead to 1496 decompression failure(s), and even to context damage at the 1497 decompressor. The profile defines context repair mechanisms, 1498 including feedback logic if used. 1500 7. Security Considerations 1502 Because encryption eliminates the redundancy that header compression 1503 schemes try to exploit, there is some inducement to forego encryption 1504 of headers in order to enable operation over low-bandwidth links. 1506 A malfunctioning or malicious header compressor could cause the 1507 header decompressor to reconstitute packets that do not match the 1508 original packets but still have valid headers and possibly also valid 1509 transport checksums. Such corruption may be detected with end-to-end 1510 authentication and integrity mechanisms, which will not be affected 1511 by the compression. Moreover, the ROHC header compression scheme uses 1512 an internal checksum for verification of reconstructed headers, which 1513 reduces the probability of producing decompressed headers not 1514 matching the original ones without this being noticed. 1516 Denial-of-service attacks are possible if an intruder can introduce 1517 (for example) bogus IR, IR-DYN or FEEDBACK packets onto the link and 1518 thereby cause compression efficiency to be reduced. However, an 1519 intruder having the ability to inject arbitrary packets at the link 1520 layer in this manner raises additional security issues that dwarf 1521 those related to the use of header compression. 1523 8. IANA Considerations 1525 An IANA registry for "RObust Header Compression (ROHC) Profile 1526 Identifiers" [21] was created by RFC 3095 [3]. The assignment policy, 1527 as outlined by RFC 3095, is the following: 1529 The ROHC profile identifier is a non-negative integer. In many 1530 negotiation protocols, it will be represented as a 16-bit value. Due 1531 to the way the profile identifier is abbreviated in ROHC packets, the 1532 8 least significant bits of the profile identifier have a special 1533 significance: Two profile identifiers with identical 8 LSBs should be 1534 assigned only if the higher-numbered one is intended to supersede the 1535 lower-numbered one. To highlight this relationship, profile 1536 identifiers should be given in hexadecimal (as in 0x1234, which would 1537 for example supersede 0x0A34). 1539 Following the policies outlined in [22], the IANA policy for 1540 assigning new values for the profile identifier shall be 1541 Specification Required: values and their meanings must be documented 1542 in an RFC or in some other permanent and readily available reference, 1543 in sufficient detail that interoperability between independent 1544 implementations is possible. In the 8 LSBs, the range 0 to 127 is 1545 reserved for IETF standard-track specifications; the range 128 to 254 1546 is available for other specifications that meet this requirement 1547 (such as Informational RFCs). The LSB value 255 is reserved for 1548 future extensibility of the present specification. 1550 The following profile identifiers have so far been allocated: 1552 Profile Identifier Usage Reference 1553 ------------------ ---------------------- --------- 1554 0x0000 ROHC uncompressed RFC 3095 1555 0x0001 ROHC RTP RFC 3095 1556 0x0002 ROHC UDP RFC 3095 1557 0x0003 ROHC ESP RFC 3095 1558 0x0004 ROHC IP RFC 3843 1559 0x0005 ROHC LLA RFC 3242 1560 0x0105 ROHC LLA with R-mode RFC 3408 1561 0x0006 ROHC TCP RFC XXXX [RFC-ed] 1562 0x0007 ROHC RTP/UDP-Lite RFC 4019 1563 0x0008 ROHC UDP-Lite RFC 4019 1565 New profiles will need new identifiers to be assigned by the IANA, 1566 but this document does not require any additional IANA action. 1568 9. Acknowledgments 1570 The authors would like to acknowledge all who have contributed to 1571 previous ROHC work, and especially to the authors of RFC 3095 [3], 1572 which is the technical basis for this document. Thanks also to the 1573 various individuals who contributed to the RFC 3095 corrections and 1574 clarifications document [6], from which technical contents, when 1575 applicable, have been incorporated into this document. Committed WG 1576 document reviewers were Carl Knutsson and Biplab Sarkar, who reviewed 1577 the document during working group last-call. 1579 10. References 1581 10.1. Normative References 1583 [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1584 Levels", RFC 2119, March 1997. 1586 10.2. Informative References 1588 [2] W. Simpson, "PPP in HDLC-like framing", STD 51, RFC 1662, July 1589 1994. 1591 [3] C. Bormann, et al., "RObust Header Compression (ROHC): Framework 1592 and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, 1593 July 2001. 1595 [4] C. Bormann, "RObust Header Compression (ROHC) over PPP", RFC 1596 3241, April 2002. 1598 [5] L-E. Jonsson, "RObust Header Compression (ROHC): Terminology and 1599 Channel Mapping Examples", RFC 3759, April 2004. 1601 [6] L-E. Jonsson, et al., "RObust Header Compression (ROHC): 1602 Corrections and Clarifications to RFC 3095", internet-draft 1603 (work in progress), September 2006. 1604 1606 [7] G. Pelletier, L-E. Jonsson, and K. Sandlund, "RObust Header 1607 Compression (ROHC): ROHC over Channels that can Reorder 1608 Packets", RFC 4224, January 2006. 1610 [8] G. Pelletier, and K. Sandlund, "RObust Header Compression 1611 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP, and UDP- 1612 Lite", internet-draft (work in progress), September 2006. 1613 1615 [9] G. Pelletier, L-E. Jonsson, K. Sandlund, and M. West, "RObust 1616 Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)", 1617 internet-draft (work in progress), October 2006. 1618 1620 [10] J. Postel, "Internet Protocol", STD 5, RFC 791, September 1981. 1622 [11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1623 Specification", RFC 2460, December 1998. 1625 [12] J. Postel, "User Datagram Protocol", STD 6, RFC 768, August 1626 1980. 1628 [13] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 1629 "RTP: A Transport Protocol for Real-Time Applications", RFC 1630 3550, July 2003. 1632 [14] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 1633 September 1981. 1635 [15] V. Jacobson, "Compressing TCP/IP Headers for Low-Speed Serial 1636 Links", RFC 1144, February 1990. 1638 [16] Degermark, M., Nordgren, B. and S. Pink, "IP Header 1639 Compression", RFC 2507, February 1999. 1641 [17] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for 1642 Low-Speed Serial Links", RFC 2508, February 1999. 1644 [18] M. Degermark, "Requirements for robust IP/UDP/RTP header 1645 compression", RFC 3096, July 2001. 1647 [19] T. Koren, et al., "Enhanced Compressed RTP (CRTP) for Links with 1648 High Delay, Packet Loss and Reordering", RFC 3545, July 2003. 1650 [20] Degermark, M., Hannu, H., Jonsson, L.E., and K. Svanbro, 1651 "Evaluation of CRTP Performance over Cellular Radio Networks", 1652 IEEE Personal Communication Magazine, Volume 7, number 4, pp. 1653 20-25, August 2000. 1655 [21] IANA registry, "RObust Header Compression (ROHC) Profile 1656 Identifiers", http://www.iana.org/assignments/rohc-pro-ids 1658 [22] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 1659 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 1661 11. Authors' Addresses 1663 Lars-Erik Jonsson 1664 Optand 737 1665 SE-831 92 Ostersund, Sweden 1666 Phone: +46 70 365 20 58 1667 EMail: lars-erik@lejonsson.com 1669 Ghyslain Pelletier 1670 Ericsson AB 1671 Box 920 1672 SE-971 28 Lulea, Sweden 1673 Phone: +46 8 404 29 43 1674 Fax: +46 920 996 21 1675 EMail: ghyslain.pelletier@ericsson.com 1677 Kristofer Sandlund 1678 Ericsson AB 1679 Box 920 1680 SE-971 28 Lulea, Sweden 1681 Phone: +46 8 404 41 58 1682 Fax: +46 920 996 21 1683 EMail: kristofer.sandlund@ericsson.com 1685 Appendix A - CRC Algorithm 1687 #!/usr/bin/perl -w 1688 use strict; 1689 #================================= 1690 # 1691 # ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02 1692 # 1693 # This little demo shows the four types of CRC in use in RFC 3095, 1694 # the specification for robust header compression. Type your data in 1695 # hexadecimal form and then press Control+D. 1696 # 1697 #--------------------------------- 1698 # 1699 # utility 1700 # 1701 sub dump_bytes($) { 1702 my $x = shift; 1703 my $i; 1704 for ($i = 0; $i < length($x); ) { 1705 printf("%02x ", ord(substr($x, $i, 1))); 1706 printf("\n") if (++$i % 16 == 0); 1707 } 1708 printf("\n") if ($i % 16 != 0); 1709 } 1711 #--------------------------------- 1712 # 1713 # The CRC calculation algorithm. 1714 # 1715 sub do_crc($$$) { 1716 my $nbits = shift; 1717 my $poly = shift; 1718 my $string = shift; 1720 my $crc = ($nbits == 32 ? 0xffffffff : (1 << $nbits) - 1); 1721 for (my $i = 0; $i < length($string); ++$i) { 1722 my $byte = ord(substr($string, $i, 1)); 1723 for( my $b = 0; $b < 8; $b++ ) { 1724 if (($crc & 1) ^ ($byte & 1)) { 1725 $crc >>= 1; 1726 $crc ^= $poly; 1727 } else { 1728 $crc >>= 1; 1729 } 1730 $byte >>= 1; 1731 } 1732 } 1733 printf "%2d bits, ", $nbits; 1734 printf "CRC: %02x\n", $crc; 1736 } 1738 #--------------------------------- 1739 # 1740 # Test harness 1741 # 1742 $/ = undef; 1743 $_ = <>; # read until EOF 1744 my $string = ""; # extract all that looks hex: 1745 s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg; 1746 dump_bytes($string); 1748 #--------------------------------- 1749 # 1750 # 32-bit segmentation CRC 1751 # Note that the text implies this is complemented like for PPP 1752 # (this differs from 8, 7, and 3-bit CRC) 1753 # 1754 # C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 + 1755 # x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32 1756 # 1757 do_crc(32, 0xedb88320, $string); 1759 #--------------------------------- 1760 # 1761 # 8-bit IR/IR-DYN CRC 1762 # 1763 # C(x) = x^0 + x^1 + x^2 + x^8 1764 # 1765 do_crc(8, 0xe0, $string); 1767 #--------------------------------- 1768 # 1769 # 7-bit FO/SO CRC 1770 # 1771 # C(x) = x^0 + x^1 + x^2 + x^3 + x^6 + x^7 1772 # 1773 do_crc(7, 0x79, $string); 1775 #--------------------------------- 1776 # 1777 # 3-bit FO/SO CRC 1778 # 1779 # C(x) = x^0 + x^1 + x^3 1780 # 1781 do_crc(3, 0x6, $string); 1783 Intellectual Property Statement 1785 The IETF takes no position regarding the validity or scope of any 1786 Intellectual Property Rights or other rights that might be claimed to 1787 pertain to the implementation or use of the technology described in 1788 this document or the extent to which any license under such rights 1789 might or might not be available; nor does it represent that it has 1790 made any independent effort to identify any such rights. Information 1791 on the procedures with respect to rights in RFC documents can be 1792 found in BCP 78 and BCP 79. 1794 Copies of IPR disclosures made to the IETF Secretariat and any 1795 assurances of licenses to be made available, or the result of an 1796 attempt made to obtain a general license or permission for the use of 1797 such proprietary rights by implementers or users of this 1798 specification can be obtained from the IETF on-line IPR repository at 1799 http://www.ietf.org/ipr. 1801 The IETF invites any interested party to bring to its attention any 1802 copyrights, patents or patent applications, or other proprietary 1803 rights that may cover technology that may be required to implement 1804 this standard. Please address the information to the IETF at ietf- 1805 ipr@ietf.org. 1807 Copyright Statement 1809 Copyright (C) The Internet Society (2006). This document is subject 1810 to the rights, licenses and restrictions contained in BCP 78, and 1811 except as set forth therein, the authors retain all their rights. 1813 Disclaimer of Validity 1815 This document and the information contained herein are provided on an 1816 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1817 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1818 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1819 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1820 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1821 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1823 This Internet-Draft expires May 29, 2007.