idnits 2.17.1 draft-ietf-rohc-context-replication-06.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.5 on line 863. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 124 has weird spacing: '...tion by reusi...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (October 5, 2004) is 7115 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) -- Looks like a reference, but probably isn't: 'ROHC-TCP' on line 745 Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ghyslain Pelletier, Ericsson 2 INTERNET-DRAFT 3 Expires: April 2005 October 5, 2004 5 RObust Header Compression (ROHC): 6 Context Replication for ROHC Profiles 7 9 Status of this memo 11 By submitting this Internet-Draft, I (we) certify that any applicable 12 patent or other IPR claims of which I am (we are) aware have been 13 disclosed, and any of which I (we) become aware will be disclosed, in 14 accordance with RFC 3668 (BCP 79). 16 By submitting this Internet-Draft, I (we) accept the provisions of 17 Section #3 of RFC 3667 (BCP 78). 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 cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/lid-abstracts.txt 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 context replication, a complement to the 40 context initialization procedure found in ROHC (Robust Header 41 Compression) [2]. Profiles defining support for context replication 42 may use the mechanism described herein to establish a new context 43 based on another already existing context. Context replication is 44 introduced to reduce the overhead of the context establishment 45 procedure, and may be especially useful for the compression of 46 multiple short-lived flows that may be occurring simultaneously or 47 near-simultaneously, such as short-lived TCP flows. 49 Table of Contents 51 1. Introduction.....................................................2 52 2. Terminology......................................................3 53 3. Context Replication for ROHC profiles............................4 54 3.1. Robustness considerations...................................4 55 3.2. Replication of Control Fields...............................5 56 3.3. Compressor states and logic.................................5 57 3.3.1. Context replication (CR) state.........................6 58 3.3.2. State machine with context replication.................6 59 3.3.3. State transition logic.................................7 60 3.3.3.1. Selection of base context, upward transition......7 61 3.3.3.2. Optimistic approach, upward transition............8 62 3.3.3.3. Optional acknowledgements (ACKs), upward transition 63 ...........................................................8 64 3.3.3.4. Negative ACKs (NACKs), downward transition........9 65 3.4. Decompressor logic..........................................9 66 3.4.1. Replication and context initialization.................9 67 3.4.2. Reconstruction and verification........................9 68 3.4.3. Actions upon failure..................................10 69 3.4.4. Feedback logic........................................10 70 3.5. Packet Formats.............................................10 71 3.5.1. CRCs in the IR-CR packet..............................11 72 3.5.1.1. 7-bit CRC........................................12 73 3.5.1.2. 8-bit CRC........................................12 74 3.5.2. General format of the IR-CR packet....................12 75 3.5.3. Properties of the Base Context Identifier (BCID)......14 76 4. Security Considerations.........................................14 77 5. Acknowledgments.................................................14 78 6. Authors' Addresses..............................................14 79 7. References......................................................15 80 7.1. Normative references.......................................15 81 7.2. Informative References.....................................15 82 Appendix A - General format of the IR-CR packet (informative)......16 83 Appendix B - Inter-profile context replication (informative).......17 85 1. Introduction 87 There is often some redundancy between header fields of different 88 flows passing through the same compressor-decompressor pair. This 89 means that some of the information needed to initialize the context 90 for decompressing the headers of a new flow may already be present at 91 the decompressor. It may be desirable to reuse this information and 92 remove some of the overhead normally required for the initialization 93 of a new header compression context at both compressor and 94 decompressor. 96 Reducing the overhead of the context establishment procedure is 97 particularly useful when multiple short-lived connections (or flows) 98 occur simultaneously, or near-simultaneously, between the same 99 compressor-decompressor pair. As each new packet stream requires most 100 of the header information to be sent during the initialization phase 101 before smaller compressed headers can be used, a multitude of short- 102 lived connections may significantly reduce the overall gain from 103 header compression. 105 Context replication allows some header fields, such as the IP source 106 and/or destination addresses (16 octets each for IPv6), to be omitted 107 within the special IR packet type specifically defined for 108 replication. It also allows other fields, such as source and/or 109 destination ports, to be either omitted or sent in a compressed form 110 from the very first packet of the header compressed flow. 112 Context replication is herein defined as a general ROHC mechanism. 113 The benefits of context replication are not limited to any particular 114 protocol and its support may be defined for any ROHC profile. 116 In particular, context replication is applicable to TCP compression, 117 since many TCP transfers are short-lived; a behavior analysis of 118 TCP/IP header fields among multiple short-lived connections may be 119 found in [5]. In addition, [4] introduces considerations and 120 requirements for the ROHC-TCP profile [3] to efficiently compress 121 such short-lived TCP transfers. 123 For profiles supporting this mechanism, the compressor performs 124 context replication by reusing or creating a copy of an existing 125 context, i.e. a base context, to create the replicated context. The 126 replicated context is then updated to match the header fields of the 127 new flow. The compressor then sends to the decompressor a packet that 128 contains a reference to the selected base context, along with some 129 data for the fields that need to be updated when creating the 130 replicated context. Finally, the decompressor creates the replicated 131 context based on the reference to the base context along with the 132 uncompressed and compressed data from the received packet. 134 This document specifies the context replication procedure for ROHC 135 profiles. It defines the general compressor and decompressor logic 136 used during context replication, as well as the general format of the 137 special IR packet required for this procedure. Profiles defining 138 support for context replication must further specify the specific 139 format(s) of this packet. 141 The fundamentals of the ROHC framework may be found in [2]. It is 142 assumed throughout this document that these are understood. 144 2. Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD, "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in RFC 2119 [1]. 150 This document reuses some of the terminology found in [2]. In 151 addition, this document defines the following terms: 153 Base context 155 A base context is a context that has been validated by both the 156 compressor and the decompressor. The compressor can use a base 157 context as the reference when building a new context using 158 replication. 160 Base CID (BCID) 162 The Base Context Identifier is the CID used to identify the base 163 context, from where information needed for context replication can 164 be extracted. 166 Context replication 168 Context replication is the mechanism that initializes a new context 169 based on another already existing context (a base context). 171 3. Context Replication for ROHC profiles 173 For profiles defining its support, context replication may be used as 174 an alternative to the context initialization procedure found in [2]. 175 Note that for such profiles, only the decompressor is mandated to 176 support context replication; the use of the IR-CR packet is optional 177 for the compressor. 179 This section describes the compressor and decompressor logic as well 180 as the general format of the IR packet used with context replication. 182 3.1. Robustness considerations 184 Context replication deviates from the initialization procedure 185 defined in [2] by its capacity to achieve a certain level of 186 compression already from the first packet used to initialize the 187 context for a new flow. It is therefore of particular importance that 188 the context replication procedure be robust. This requires that a 189 base context suitable for replication be used, that the integrity of 190 the initialization packet be guaranteed and finally that the outcome 191 of the replication process be verified. 193 The primary mechanisms used to achieve robustness of the context 194 replication procedure are the selection of the base context based on 195 prior feedback from the decompressor and the use of checksums. 196 Specifically, the compressor must obtain enough confidence that the 197 base context selected for replication is valid and available at the 198 decompressor before initiating the replication procedure. The most 199 reliable way to select the base context is thus to choose a context 200 for which at least the static part to be replicated has previously 201 been acknowledged by the decompressor. 203 In addition, the presence of a CRC covering the information that 204 initializes the context ensures the integrity of the IR header used 205 for replication. Finally, an additional CRC calculated over the 206 original uncompressed header allows the decompressor to validate the 207 reconstructed header and the outcome of the replication process. 209 3.2. Replication of Control Fields 211 Control fields are fields that are either transmitted from a ROHC 212 compressor to a ROHC decompressor or inferred based on the behavior 213 of other fields, but are not part of the uncompressed header itself. 215 They can be used to control compression and decompression behavior, 216 in particular what set of packet formats is used. Control fields are 217 profile-specific. Example of such fields include the NBO and RND 218 flags [2] that indicate whether the IP-ID field is in Network Byte 219 Order and the type of behavior of the field, respectively. Another 220 example is the parameter indicating the mode of operation [2]. 222 The IR-CR differs from the IR packet [2] in that its purpose is to 223 entirely specify what part of the base context is replicated, and to 224 convey the complementary information needed to create a new context. 225 Because of this, a profile supporting the use of the IR-CR packet 226 SHOULD define for each control field if the value of the field is 227 replicated from the base context to the new context, or if its value 228 is reinitialized. 230 In addition, a compressor MUST NOT initiate context replication while 231 a control field that is not reinitialized by replication is being 232 updated, such as for the case where the handshake for a mode 233 transition [2] is taking place. 235 3.3. Compressor states and logic 237 Compression with ROHC normally starts in the IR state, where IR 238 packets must be sent to initialize a new context at the decompressor. 239 IR packets include all static and non-static fields of the original 240 header in uncompressed form plus some additional information. The 241 compressor stays in the IR state until it obtains confidence that the 242 decompressor has received the information. 244 Context replication provides an optional mechanism to complement the 245 ROHC initialization procedure. It defines a packet type, the IR 246 packet for Context Replication (IR-CR), which can be used to 247 initialize a new context. Consequently, the Context Replication (CR) 248 state is introduced to the compressor state machine to encompass the 249 additional logic required for the use of the IR-CR packet. 251 For profiles defining support for context replication, the compressor 252 may thus transit directly from the IR state to the CR state if an 253 already existing context can be selected as a base context for 254 replication. This effectively replaces any IR/IR-DYN packets sent 255 during the context establishment procedure with an IR-CR packet. 257 3.3.1. Context replication (CR) state 259 The purpose of the CR state is to initialize a new context by reusing 260 an already existing context. In this state, the compressor sends a 261 combination of uncompressed and compressed information, along with a 262 reference to a base context plus some additional information. Header 263 information pertaining to fields that are being replicated is 264 therefore not sent. 266 The compressor stays in the CR state until it is confident that the 267 decompressor has received the replication information correctly. 269 3.3.2. State machine with context replication 271 The compressor always starts in the lower compression state (IR), and 272 transits to the context replication state (CR) under the constraint 273 that the compressor can select a base context that is suitable for 274 the flow being compressed (see also section 3.3.3.1). 276 The transition from the CR state to a higher compression state (e.g. 277 the CO state for [3]) is based on the optimistic approach principle 278 or feedback received from the decompressor. 280 The figure below shows the additional state for the compressor. The 281 details of the state transitions and compression logic are given in 282 sub-sections following the figure. 284 BCID selection Optimistic approach / ACK 285 +----->----->------+ +----->----->----->-----+ 286 | | | | 287 | v | v 288 +---------+ +---------+ +-------------+ 289 | IR | | CR | | Higher | 290 | state | | state | | order state | 291 +---------+ +---------+ +-------------+ 292 ^ | 293 | NACK / STATIC-NACK | 294 +---<-----<-----<----+ 296 Note that context replication is a complement to the normal 297 initialization procedure for ROHC profiles supporting it. The 298 compressor transition to the CR state is therefore an optional 299 addition to the state machine, and this does not affect already 300 existing transitions between the IR state and higher order state(s). 302 3.3.3. State transition logic 304 Decisions about transition to and from the CR state are taken by 305 the compressor on the basis of: 307 - availability of a base context 308 - positive feedback from the decompressor (Acknowledgements -- ACKs) 309 - negative feedback from the decompressor (Negative ACKs -- NACKs) 310 - confidence level regarding error-free decompression of a packet 312 Context replication is designed to operate over links where a 313 feedback channel is available. This is necessary to ensure that the 314 information used to create a new context is synchronized between the 315 compressor and the decompressor. In addition, context replication may 316 also make use of feedback from decompressor to compressor for 317 transition back to the IR state and for OPTIONAL improved forward 318 transition towards a state with a higher compression ratio. 320 The format that must be used by all profiles for the feedback field 321 within the general ROHC format is specified in section 5.2.2 of [2]; 322 the feedback information is structured using two possible formats: 323 FEEDBACK-1 and FEEDBACK-2. In particular, FEEDBACK-2 can carry one of 324 three possible types of feedback information: ACK, NACK or STATIC- 325 NACK. 327 3.3.3.1. Selection of base context, upward transition 329 The compressor may initiate a transition from the IR state to the CR 330 state when a suitable base context can be identified. To perform this 331 transition, the compressor select a context that has previously been 332 acknowledged by the decompressor as the base context. The selected 333 context MUST have been acknowledged by the decompressor using the CRC 334 option (see also [2], section 5.7.6.3) in the feedback message. The 335 static part of the base context to be replicated MUST have been 336 acknowledged by the decompressor and the base context MUST be valid 337 at replication time. 339 This also implies that a compressor is not allowed to use the context 340 replication mechanism if a feedback channel is not present. Note 341 however that the presence of the feedback channel cannot provide the 342 guarantee that a base context selected for replication has not been 343 corrupted after it has been acknowledged, or that it is still part of 344 the state managed by the decompressor when the IR-CR will be 345 received. 347 More specifically, RFC 3095 [2] defines the context identifier (CID) 348 as a reference to the state information (i.e. the context) used for 349 compression and decompression. Multiple packet streams - each having 350 their own context - may thus share a channel, and the CID space along 351 with its representation within packet formats may be negotiated as 352 part of the channel state. However, because RFC 3095 [2] does not 353 explicitly define context state management between compressor and 354 decompressor, in particular for connection-oriented flows (e.g. TCP), 355 no more than a high degree of confidence can be achieved when 356 selecting a base context. 358 In the case where feedback is not used by the decompressor, the 359 compressor may have to periodically transit back to the IR state. In 360 such case, the same logic applies for the transition back to the 361 higher order state via the CR state: a base context previously 362 acknowledged and suitable for replication must be re-selected. 364 The criteria for whether an existing context is a suitable base 365 context for replication for a new flow are left to implementations. 367 Whenever available, the compressor MAY also use the sequencing 368 information from the last acknowledgement received to determine what 369 fields can be replicated, and not replicate any fields that have 370 changed significantly from the state corresponding to the 371 acknowledged packet. 373 3.3.3.2. Optimistic approach, upward transition 375 Transition to a higher order state can be carried out according to 376 the optimistic approach principle. This means that the compressor may 377 perform an upward state transition when it is fairly confident that 378 the decompressor has received enough information to correctly 379 decompress packets sent according to the higher compression state. 381 In general, there are many approaches where the compressor can obtain 382 such information. The compressor may obtain its confidence by sending 383 several IR-CR packets with the same information. 385 3.3.3.3. Optional acknowledgements (ACKs), upward transition 387 An ACK may be sent by the decompressor to indicate that a context has 388 been successfully initialized during context replication. 390 Upon reception of an ACK, the compressor may assume that the context 391 replication procedure was successful and transit from its initial 392 state (e.g. IR state) to a higher compression state. 394 3.3.3.4. Negative ACKs (NACKs), downward transition 396 A STATIC-NACK sent by the decompressor may indicate that the 397 decompressor could not initialize a valid context during context 398 replication, and the corresponding context has been invalidated. 400 Upon reception of a STATIC-NACK, the compressor MUST transit back to 401 its initial no context state. The compressor SHOULD also refrain from 402 sending IR-CR packets using the same base context, at least until an 403 acknowledgement subsequent to the reception of the STATIC-NACK makes 404 this context suitable for replication (section 3.3.3.1). The 405 compressor SHOULD re-initialize the decompressor context using an IR 406 packet. 408 A NACK sent by the decompressor may indicate that a valid context has 409 been successfully initialized but that the decompression of one or 410 more subsequent packets has failed. 412 Upon reception of a NACK, the compressor MAY assume that the static 413 part of the decompressor context is valid but that the dynamic part 414 is invalid, and take actions accordingly. 416 3.4. Decompressor logic 418 3.4.1. Replication and context initialization 420 Upon reception of an IR-CR packet, the decompressor first determines 421 its content ([2], section 5.2.6). The profile indicated in the IR-CR 422 packet determines how it is to be processed. If the CRC (8-bit CRC) 423 fails to verify the packet, the packet MUST be discarded. 425 If the profile as indicated in the IR-CR packet defines the use of 426 the Base CID and if its corresponding field is present within the 427 packet format, this field is used to identify the base context; 428 otherwise the CID is used. 430 3.4.2. Reconstruction and verification 432 The decompressor creates a new context using the information present 433 in the IR-CR packet together with the identified base context, and 434 decompresses the original header. 436 The CRC calculated over the original uncompressed header and carried 437 within the profile specific part of the IR-CR headers (7-bit CRC) 438 MUST be used to verify decompression. 440 When the decompression is verified and successful, the decompressor 441 initializes or updates the context with the information received in 442 the current header. The decompressor SHOULD send an ACK when it 443 succeeds to validate the context as a result of the decompression of 444 one or more IR-CR packets. 446 Otherwise if the reconstructed header fails the CRC check, changes 447 (either initialization or update) to the context MUST NOT be 448 performed. When the decompressor fails to validate the header, 449 actions as specified in section 3.4.3 are taken. 451 3.4.3. Actions upon failure 453 For profiles supporting context replication, the feedback logic of a 454 decompressor is similar to the logic used for context initialization, 455 as described in [2]. 457 Specifically, when the decompressor fails to validate the context 458 following the decompression of one or more initial IR-CR packets, it 459 MUST invalidate the context and remain in its initial state. In 460 addition, the decompressor SHOULD send a STATIC-NACK. In particular, 461 a decompressor implementation performing strict memory management, 462 such as deleting context state information when a connection-oriented 463 flow (e.g. TCP) is known to have terminated, SHOULD send STATIC-NACK 464 in this case. Otherwise there is a risk that the compressor maintains 465 a specific CID as a potential candidate for a later replication 466 attempt, while there actually is insufficient state left in the 467 decompressor for this CID to act as a Base CID. 469 If the context has been successfully validated from the decompression 470 of one or more initial IR-CR packets, the decompressor SHOULD send a 471 NACK when it fails to verify the context following the decompression 472 of one or more subsequent IR-CR packets. 474 3.4.4. Feedback logic 476 The decompressor SHOULD use the CRC option (see [2], section 5.7.6.3) 477 when sending feedback corresponding to an IR or an IR-CR packet. 479 3.5. Packet Formats 481 The format of the IR-CR packet has been designed under the following 482 constraints: 484 a) it must be possible to either overwrite a CID during context 485 replication, or to use a CID different than the Base CID for 486 the replicated context; 487 b) it must be possible to selectively include or exclude from the 488 packet format some fields that may be replicable; 489 c) it must be possible for some fields that may be replicable to be 490 represented within the packet format using either a compressed or 491 an uncompressed form; 492 d) it must be possible for the decompressor to verify the success of 493 the replication procedure; 494 e) it is anticipated that profiles other than [ROHC-TCP] will also 495 define support for context replication, therefore it is desirable 496 that the packet format be profile independent. 498 3.5.1. CRCs in the IR-CR packet 500 The IR packet, as defined in [2], is used to communicate static 501 and/or dynamic parts of a context, and typically initialize the 502 context. For example, the static and dynamic chains of IR packets may 503 contain an uncompressed representation of the original header. 505 The IR packet format includes an 8-bit CRC, calculated over the 506 initial part of the IR packet. This CRC is meant to protect any 507 information that initializes the context. In particular, its coverage 508 always includes any CID information as well as the profile used to 509 interpret the remainder of the IR packet. 511 The purpose of the 8-bit CRC is to ensure the integrity of the IR 512 header itself. Profiles may extend the coverage of this CRC to 513 include the entire IR header, thus allowing the verification of the 514 integrity of the entire uncompressed header. However because the 515 format of the IR packet is common to all ROHC profiles and verified 516 as part of the initial processing of a ROHC decompressor (see [2], 517 section 5.2.6.), profiles may not redefine this CRC beyond the extent 518 of its coverage. 520 RFC 3095 [2] also defines a 3-bit CRC and a 7-bit CRC for compressed 521 headers, used to verify proper decompression and validate the 522 context. This type of CRC is calculated over the original 523 uncompressed header, as it is not sufficient to only protect the 524 compressed data being exchanged between compressor and decompressor 525 to ensure a robust reconstruction of the original header. 527 There is thus a clear distinction in purpose between the 8-bit CRC 528 found in the IR packet and the 3-bit or 7-bit CRC found in compressed 529 headers. With context replication, where the IR-CR packet may contain 530 both compressed as well as uncompressed information and omit entirely 531 replicable fields, this distinction in no longer present. 533 Profiles supporting context replication MUST define a CRC over the 534 original uncompressed header as part of the profile specific 535 information in the IR-CR packet. This is necessary to allow a 536 decompressor to verify that the replication process has succeeded. 538 3.5.1.1. 7-bit CRC 540 The 7-bit CRC in the IR-CR packet is calculated over all octets of 541 the entire original header, before replication, in the same manner as 542 described in section 5.9.2 of [2]. 543 The initial content of the CRC register is to be preset to all 1's. 544 The CRC polynomial used for the 7-bit CRC in the IR-CR is: 546 C(x) = 1 + x + x^2 + x^3 + x^6 + x^7 548 3.5.1.2. 8-bit CRC 550 The coverage of the 8-bit CRC in the IR-CR packet is not profile- 551 dependent, as opposed to the ROHC IR(-DYN) packet (see [2], sections 552 5.2.3. and 5.2.4.). It MUST cover the entire packet, excluding the 553 payload. In particular, this includes the CID or any add-CID octet as 554 well as the Base CID field, if present. For profiles that define the 555 usage of the Base CID within the packet format of the IR-CR as 556 optional, this CRC MUST also cover the information used to indicate 557 the presence of this field within the packet. 559 The initial content of the CRC register is to be preset to all 1's. 560 The CRC polynomial used for the 8-bit CRC in the IR-CR is: 562 C(x) = 1 + x + x^2 + x^8 564 3.5.2. General format of the IR-CR packet 566 The context replication mechanism requires a dedicated IR packet 567 format that uniquely identifies the IR-CR packet. This packet 568 communicates the static and the dynamic parts of the replicated 569 context. It may also communicate a reference to a base context. 571 With consideration to the extensibility of the IR packet type defined 572 in [2], support for replication can be added using the profile 573 specific part of the IR packet. Note that there is one bit, (x), left 574 in the IR header for "Profile specific information". The definition 575 of this bit is profile-specific. Thus, profiles supporting context 576 replication MAY use this bit as a flag indicating whether the packet 577 is an IR packet or an IR-CR packet. Note also that profiles may 578 define an alternative method to identify the IR-CR packet within the 579 profile specific information, instead of using this bit. 581 The IR-CR header associates a CID with a profile, and initializes the 582 context using the context replication mechanism. It is not 583 recommended to use this packet to repair a damaged context. 585 The IR-CR has the following general format: 587 0 1 2 3 4 5 6 7 588 --- --- --- --- --- --- --- --- 589 : Add-CID octet : if for small CIDs and (CID != 0) 590 +---+---+---+---+---+---+---+---+ 591 | 1 1 1 1 1 1 0 x | IR type octet 592 +---+---+---+---+---+---+---+---+ 593 : : 594 / 0-2 octets of CID / 1-2 octets if for large CIDs 595 : : 596 +---+---+---+---+---+---+---+---+ 597 | Profile | 1 octet 598 +---+---+---+---+---+---+---+---+ 599 | CRC | 1 octet 600 +---+---+---+---+---+---+---+---+ 601 | | 602 / Profile specific information / variable length 603 | | 604 - - - - - - - - - - - - - - - - 605 | | 606 / Payload / variable length 607 | | 608 - - - - - - - - - - - - - - - - 610 x: Profile specific information. Interpreted according to the 611 profile indicated in the Profile field. 613 Profile: The profile to be associated with the CID. In the 614 IR-CR packet, the profile identifier is abbreviated to the 615 8 least significant bits. It selects the highest-number 616 profile in the channel state parameter PROFILES that matches 617 the 8 LSBs given (see also [2]). 619 CRC: 8-bit CRC computed using the polynomial of section 3.5.1.2. 621 Profile specific information: The contents of this part of the 622 IR-CR packet are defined by the individual profiles. This 623 information is interpreted according to the profile indicated 624 in the Profile field. It MUST include a 7-bit CRC over the 625 original uncompressed header using the polynomial of section 626 3.5.1.1. It also includes the static and dynamic subheader 627 information used for replication; what header fields are 628 replicated along with their respective encoding methods is 629 thus outside the scope of this document. 631 Payload: The payload of the corresponding original packet, if any. 633 3.5.3. Properties of the Base Context Identifier (BCID) 635 The Base CID within the packet format of the IR-CR may be assigned a 636 different value than the context identifier associated to the new 637 flow (i.e. BCID != CID); otherwise the base context is overwritten 638 with the new context by the replication process. 640 When the channel uses small CIDs, a four-bit field within the packet 641 format of the IR-CR minimally represents the BCID with a value from 0 642 to 15. In particular, the four bits of Add-CID used with small CIDs 643 [2] are not needed for the BCID, as this information is already 644 provided from the CID of the IR-CR packet itself. When large CIDs are 645 used, the BCID is represented in the IR-CR with one or two octets, 646 and it is coded in the same way as a large CID [2]. 648 4. Security Considerations 650 This document adds an alternative mechanism for ROHC profiles to 651 increase the compression efficiency when initializing a new context, 652 by reusing information already existing at the decompressor. This is 653 achieved by introducing new state transition logic, new feedback 654 logic, and a new packet type - all based on logic and packet formats 655 already defined in RFC 3095 [2]. 657 In this respect, this document is not believed to bring any 658 additional weakness to potential attacks to those already listed in 659 [2]. However, it does increase the potential impacts of these attacks 660 by creating dependencies between multiple contexts. Specifically, 661 corruption of one context can fail compressor attempts to initialize 662 another context at the decompressor, or propagate to another context, 663 if the compressor uses a corrupted context as a base for replication. 665 5. Acknowledgments 667 The author would like to thank Richard Price, Kristofer Sandlund, 668 Fredrik Lindstroem, Zhigang Liu and HongBin Liao for valuable input, 669 as well as Mark West and Lars-Erik Jonsson who also served as 670 committed working group document reviewers. 672 6. Authors' Addresses 674 Ghyslain Pelletier 675 Box 920 676 Ericsson AB 677 SE-971 28 Lulea, Sweden 678 Phone: +46 8 404 29 43 679 Fax: +46 920 996 21 680 Email: ghyslain.pelletier@ericsson.com 682 7. References 684 7.1. Normative references 686 [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement 687 Levels", RFC 2119, March 1997. 689 [2] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 690 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, 691 Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., 692 Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): 693 Framework and four profiles: RTP, UDP, ESP, and uncompressed", 694 RFC 3095, July 2001. 696 7.2. Informative References 698 [3] Pelletier, G., Jonsson, L-E., West, M., Price, R. and K. 699 Sandlund, "RObust Header Compression (ROHC): TCP/IP Profile 700 (ROHC-TCP)", Internet Draft (work in progress), , July 2004. 703 [4] Jonsson, L-E., "Requirements on ROHC IP/TCP header compression", 704 Internet Draft (work in progress), , September 2004. 707 [5] West, M. and S. McCann, "TCP/IP Field Behavior", Internet Draft 708 (work in progress), , 709 July 2004. 711 [6] R. Price, R. Finking and G. Pelletier, "Formal Notation for 712 Robust Header Compression (ROHC-FN)", Internet Draft (work in 713 progress), , July 2004. 715 Appendix A - General format of the IR-CR packet (informative) 717 Appendix A.1. General structure (informative) 719 This section provides an example of the format of the profile 720 specific information within the general format of the IR-CR. 722 0 1 2 3 4 5 6 7 723 +---+---+---+---+---+---+---+---+ 724 | | 725 / replication base information / variable length 726 | | 727 +---+---+---+---+---+---+---+---+ 728 | | 729 / replication information / variable length 730 | | 731 - - - - - - - - - - - - - - - - 733 Replication base information: The contents of this part of the IR-CR 734 packet are defined by the individual profiles. This information 735 is interpreted according to the profile indicated in the Profile 736 field. It MUST include a 7-bit CRC over the original uncompressed 737 header using the polynomial of section 3.4.1.1. See Appendix A.2. 739 Replication information: The contents of this part of the IR-CR 740 packet are also defined by the individual profiles. This part 741 contains the static and dynamic subheader information used for 742 replication. How this information is structured is profile 743 specific; profiles may define the contents of this field using a 744 chain structure (static and dynamic replication chains) or by 745 defining header formats for replication (e.g. [ROHC-TCP]). 747 Appendix A.2. Profile specific replication information (informative) 749 This section provides a more detailed example of the possible format 750 of the replication information field described in Appendix A.1: 752 +---+---+---+---+---+---+---+---+ 753 | B | CRC7 | 1 octet 754 +---+---+---+---+---+---+---+---+ 755 | | present if B = 1, 756 / Base CID / 1 octet if for small CIDs, or 757 | | 1-2 octets if for large CIDs 758 +---+---+---+---+---+---+---+---+ 760 B: B = 1 indicates that the Base CID field is present. 762 CRC7: The CRC over the original, uncompressed, header. This 7-bit CRC 763 is computed according to section 3.4.1.1. 765 Base CID: The CID identifying the base context used for replication. 767 Appendix B - Inter-profile context replication (informative) 769 Context replication as defined in this document does not explicitly 770 support the concept of context replication between profiles. However, 771 it might be of interest when developing new compression profiles. 773 Inter-profile context replication would require that the decompressor 774 have access to data structures from the base context, which belongs 775 to a profile different than the profile using replication. This 776 information would have to be made available in a format consistent 777 with the data structures and encoding method(s) in use for all header 778 fields that are being replicated. 780 Appendix B.1. Defining support for inter-profile context replication 782 A ROHC profile describes how to compress a specific protocol stack, 783 and includes one or more sets of packet formats. The packet formats 784 will typically compress the protocol headers relative to a context of 785 field values from previous headers in a flow. This context may also 786 contain some control data. The packet formats thus specify a mapping 787 between the uncompressed and compressed version of a protocol field. 789 This mapping is achieved through the use of one or more encoding 790 methods, which are simply functions applied to compress or decompress 791 a field. An encoding method is in turn defined using a name, a set of 792 function parameters and a formal expression (i.e. using the ROHC-FN 793 [6]) or a textual description (i.e. a la RFC 3095 [2]) of its 794 behaviour. 796 To compress one or more fields of a specific protocol stack, 797 different profiles may define their packet formats using different 798 encoding methods, or using a variant of a similar technique. A 799 typical example of the latter is list compression, such as used for 800 IP extension headers. This implies that context entries for a field 801 belonging to a specific protocol stack may differ in their content, 802 representation and structure from one profile to another. 804 As a consequence of the above, a profile supporting context 805 replication can only use a base context from another profile 806 explicitly supporting the concept of a base context. That is, 807 existing profiles not supporting this concept must be updated first 808 to ensure that they can export the necessary context data entries 809 using a meaningful representation during replication. 811 Specifically, inter-profile context replication would require that 812 decompressor implementations (including existing ones) of other 813 profiles be updated when adding support for a profile using context 814 replication. Inter-profile context replication can therefore not be 815 seen as being only a specific implementation issue. 817 The compressor must know if the decompressor supports inter-profile 818 context replication before initiating the procedure. The compressor 819 must also know which contexts belonging to what profile may be used 820 as a base context. Therefore, a compressor cannot initiate context 821 replication using a base context belonging to a different profile, 822 unless this profile explicitly provides the proper mapping for its 823 context entries or unless this profile is defined formally using 824 ROHC-FN [6] in manner that makes both profiles compatible. The set of 825 profiles negotiated for the channel (see also RFC 3095 [2]) can then 826 be used to determine if a context for a specific profile can be used 827 as a base context. 829 Appendix B.2. Compatibility between different profiles (informative) 831 Compatibility between profiles, when replicating a field for a 832 particular protocol stack, can be expressed as follow: a field that 833 is compressed by different profiles is compatible for inter-profile 834 replication if it is defined in the set of packet formats using the 835 same mapping function between its uncompressed and compressed 836 version. 838 For example, the IP Destination Address field which, based on the 839 packet formats and compression strategies defined in RFC 3095 [2], is 840 implicitly compressed using an encoding method equivalent to the 841 static() method defined in ROHC-FN [6]. 843 In particular, for profiles that define their packet formats using a 844 formal notation such as ROHC-FN [6], two different encoding methods 845 may not have the same name. A field from a protocol stack is thus 846 said to be compatible for replication between two different profiles 847 if it has an equivalent definition within respective packet formats. 849 Copyright Statement 851 Copyright (C) The Internet Society (2004). This document is subject 852 to the rights, licenses and restrictions contained in BCP 78, and 853 except as set forth therein, the authors retain all their rights. 855 Disclaimer of Validity 857 This document and the information contained herein are provided on an 858 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 859 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 860 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 861 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 862 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 863 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 865 This Internet-Draft expires April 5, 2005.