idnits 2.17.1 draft-pelletier-rohc-context-replication-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 ([RFC-3095]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances 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 725 has weird spacing: '...Present if S...' == Line 726 has weird spacing: '...1 octet if SC...' == Line 729 has weird spacing: '...Present if D...' == Line 730 has weird spacing: '...1 octet if DC...' == Line 776 has weird spacing: '...Present if S...' == (5 more instances...) -- 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 (May 23, 2002) is 8002 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) == Unused Reference: 'RFC-2026' is defined on line 561, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'UDP-Lite' Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Ghyslain Pelletier, Ericsson 3 INTERNET-DRAFT 4 Expires: November 2003 May 23, 2002 6 RObust Header Compression (ROHC): 7 Context Replication for ROHC Profiles 8 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/lid-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Abstract 32 This document defines context replication, an alternative to the 33 context initialization procedure found in ROHC (Robust Header 34 Compression) [RFC-3095]. Profiles defining support for context 35 replication may use the mechanism described herein to establish a new 36 context based on another already existing context. 38 Context replication is introduced to reduce the overhead of the 39 context establishment procedure, and may be especially useful for the 40 compression of multiple short-lived flows that may be occurring 41 simultaneously or near-simultaneously, such as for example short- 42 lived TCP flows. 44 Table of contents 46 1. Introduction....................................................3 48 2. Terminology.....................................................4 50 3. Context replication for ROHC profiles...........................4 52 3.1. Robustness considerations.................................4 53 3.2. Compressor logic..........................................5 54 3.2.1. Selection of the Base Context...........................5 55 3.2.2. Feedback logic..........................................6 56 3.2.2.1. Negative Acknowledgements (NACKs).....................6 57 3.2.2.2. Optional Acknowledgements (ACKs)......................7 58 3.3. Decompressor logic........................................7 59 3.3.1. Replication and context initialization..................7 60 3.3.2. Actions upon failure....................................7 61 3.4. Packet Formats............................................8 62 3.4.1. Checksums in the IR-REPLICATE packet....................8 63 3.4.1.1. 7-bit CRC.............................................9 64 3.4.1.2. 8-bit CRC.............................................9 65 3.4.2. General Format of the IR-REPLICATE packet...............9 67 4. Security considerations........................................11 69 5. Acknowledgements...............................................11 71 6. References.....................................................11 73 6.1. Normative References.....................................11 74 6.2. Informative References...................................12 76 7. Author's address...............................................12 78 Appendix A. Replication chains....................................13 80 A.1. Replication of the IPv6 Header [RFC-2460]................13 81 A.2. Replication of the IPv4 Header [RFC-791].................14 82 A.3. Replication of the UDP Header [RFC-768]..................16 83 A.4. Replication of the UDP-Lite Header [UDP-Lite]............17 84 A.5. Replication of the TCP Header [RFC-793]..................18 86 1. Introduction 88 There is often some redundancy between header fields of different 89 flows passing through the same compressor-decompressor pair. This 90 means that some of the information needed to initialize the context 91 for compressing the headers of a new flow may already be present at 92 the decompressor. It may be desirable to reuse this information and 93 remove some of the overhead normally required for the initialization 94 of a new header compression context. 96 Reducing the overhead of the context establishment procedure is 97 particularly useful when multiple short-lived connections (or flows) 98 occurs simultaneously, or near-simultaneously, between the same 99 compressor-decompressor pair. Such flows may lead to lower header 100 compression gains, as each new packet stream requires the entire 101 headers to be sent initially and smaller compressed headers may only 102 be sent thereafter. 104 Context replication allows some header fields, such as the IP source 105 and/or destination addresses (16 octets each for IPv6), to be omitted 106 within the IR packet specially defined for replication. It also 107 allows other fields, such as source and/or destination ports, to be 108 either omitted or sent in a compressed form from the very first 109 packet of the header compressed flow. In addition, this mechanism 110 allows contexts from different profiles to be used with context 111 replication, where for obvious reasons only header fields common to 112 both profiles can possibly be replicated. 114 Context replication is herein defined as a general ROHC mechanism; 115 its support may be defined for any ROHC profile. However, although 116 the benefits of context replication are not limited to any particular 117 protocol, it is best motivated for TCP compression. Specifically, 118 many TCP transfers are short-lived; a behavior analysis of TCP/IP 119 header fields among multiple short-lived connections may be found in 120 [TCP-BEH]. In addition, [TCP-REQ] introduces considerations and 121 requirements for the ROHC-TCP profile [ROHC-TCP] to efficiently 122 compress such short-lived TCP transfers. 124 For profiles supporting this mechanism, context replication is 125 performed by the compressor first initializing a new context for the 126 new flow. This context is then populated using parts of an existing 127 context, i.e. a base context, to create the replicated context. The 128 compressor then sends to the decompressor a packet that contains a 129 reference to the selected base context, along with some data for the 130 fields that need to be updated when creating the replicated context. 131 Finally, the decompressor creates the replicated context based on the 132 reference to the base context along with the uncompressed and 133 compressed data from the received packet. 135 This document specifies the context replication procedure for ROHC 136 profiles. It defines the general compressor and decompressor logic 137 used during context replication, as well as the general format of the 138 special IR packet required for this procedure. Profiles defining 139 support for context replication must further specify the specific 140 format of this packet. 142 The fundamentals of general header compression may be found in [RFC- 143 3095]. These are assumed to be understood throughout this document. 145 2. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC2119. 151 This document reuses some of the terminology found in [RFC-3095]. In 152 addition, this document defines the following terms: 154 Base context 156 A base context is a context that has been validated by both the 157 compressor and the decompressor. A base context can be used by the 158 compressor as the reference when building a new context using 159 replication. 161 Base CID 163 The Base Context Identifier is the CID used to identify the Base 164 Context, where information needed for context replication can 165 be extracted from. 167 Context replication 169 Context replication is the mechanism that initializes a new context 170 based on another already existing context (a base context). 172 3. Context Replication for ROHC profiles 174 For profiles defining its support, context replication may be used as 175 an alternative to the context initialization procedure found in [RFC- 176 3095]. This section describes the compressor and decompressor logic 177 as well as the IR packet format used with context replication. 179 3.1. Robustness considerations 181 Context replication deviates from the initialization procedure 182 defined in [RFC-3095] by its capacity to achieve a certain level of 183 compression already from the first packet used to initialize the 184 context for a new flow. It is therefore of particular importance that 185 the context replication procedure be reliable. This requires that a 186 base context suitable for replication be used, that the integrity of 187 the initialization packet be guaranteed and finally that the outcome 188 of the replication process be verified. 190 The primary mechanisms used to achieve robustness of the context 191 replication procedure are the selection of the base context based on 192 prior feedback from the decompressor and the use of checksums. 194 Specifically, the compressor must obtain enough confidence that a 195 base context corresponding to the one selected for replication is 196 available at the decompressor before initiating the replication 197 procedure. The most reliable way to select the base context is thus 198 to choose a context that has previously been acknowledged by the 199 decompressor. 201 In addition, the presence of a CRC covering the information used to 202 initialize the context ensures the integrity of the IR header used 203 for replication. Finally, an additional CRC calculated over the 204 original uncompressed header allows the decompressor to validate the 205 reconstructed header and the outcome of the replication process. 207 3.2. Compressor logic 209 For profiles defining support for context replication, the compressor 210 may replace any IR/IR-DYN packets during the context establishment 211 procedure (i.e. in IR state) with the IR-REPLICATE packet, if an 212 already existing context can be selected as a base context for 213 replication. 215 3.2.1. Selection of a Base Context 217 When initiating context replication, the compressor MUST select a 218 context that has previously been acknowledged by the decompressor as 219 the base context, and this base context must be valid at replication 220 time. This also implies that a compressor is not allowed to use the 221 context replication mechanism if a feedback channel is not present. 222 Note however that this cannot provide the guarantee that the selected 223 context is still part of the state managed by the decompressor when 224 the IR-REPLICATE will be received. 226 More specifically, [RFC-3095] defines the context identifier (CID) as 227 a reference to the state information (i.e. the context) used for 228 compression and decompression. Multiple packet streams with different 229 contexts may thus share a channel, and the CID space along with its 230 representation within packet formats may be negotiated as part of the 231 channel state. However, because [RFC-3095] does not explicitly define 232 context state management between compressor and decompressor, and in 233 particular for connection-oriented flows (e.g. TCP), only a high 234 degree of confidence can be achieved when selecting a base context. 236 The criteria whether an existing context is a suitable base context 237 for replication for a new flow are left to implementations. For 238 simplicity, contexts with the same Source-IP and/or Destination-IP 239 may be considered as replicable contexts, and the most recent one 240 should be selected as the candidate to be replicated. 242 Finally, the Base CID within the packet format of the IR-REPLICATE 243 may be assigned a different value than the context identifier 244 associated to the new flow (i.e. Base CID != CID); otherwise the base 245 context is overwritten with the new context by the replication 246 process. 248 3.2.2. Feedback logic 250 Context replication is designed to operate over links where a 251 feedback channel is available. This is necessary to ensure that the 252 information used to create a new context is synchronized between the 253 compressor and the decompressor. In addition, context replication may 254 also make use of feedback from decompressor to compressor for 255 transition back to the IR state and for OPTIONAL improved forward 256 transition. 258 [RFC-3095, section 5.2.2.] specifies the required format for the 259 feedback field within the general ROHC packet format to be used by 260 all profiles; the feedback information is structured using two 261 possible formats: FEEDBACK-1 and FEEDBACK-2. In particular, FEEDBACK- 262 2 can carry one of three possible types of feedback information: ACK, 263 NACK or STATIC-NACK. 265 3.2.2.1. Negative Acknowledgements (NACKs) 267 A STATIC-NACK sent by the decompressor may indicate that a valid 268 context could not be initialized by the decompressor during context 269 replication, and the corresponding context has been invalidated. 271 Upon reception of a STATIC-NACK, the compressor MUST transit back to 272 its initial no context state and SHOULD refrain from sending IR- 273 REPLICATE packets using the same base context. The compressor SHOULD 274 re-initialize the decompressor context using an IR packet. 276 A NACK sent by the decompressor may indicate that a valid context has 277 been successfully initialized but that the decompression of one or 278 more subsequent packets has failed. 280 Upon reception of a NACK, the compressor may assume that the static 281 part of the decompressor context is valid but that the dynamic part 282 is invalid, and take actions accordingly. 284 3.2.2.2. Optional Acknowledgements (ACKs) 286 An ACK may be sent by the decompressor to indicate that a context has 287 been successfully initialized during context replication. 289 Upon reception of an ACK, the compressor may assume that the context 290 replication procedure was successful and transit from its initial 291 state (e.g. IR state) to a higher compression state. 293 3.3. Decompressor logic 295 3.3.1. Replication and context initialization 297 Upon reception of an IR-REPLICATE packet, the decompressor first 298 determines its content (RFC-3095, section 5.2.6). The profile 299 indicated in the IR-REPLICATE packet determines how it is to be 300 processed. If the CRC (8-bit CRC) fails to verify the packet, the 301 packet MUST be discarded. 303 If the profile as indicated in the IR-REPLICATE packet defines the 304 use of the Base CID and if its corresponding field is present within 305 the packet format, this field is used to identify the base context; 306 otherwise the CID is used. 308 The decompressor then creates a new context using the information 309 present in the IR-REPLICATE packet together with the identified base 310 context, and decompresses the original header. The decompressor 311 validates the resulting header using the CRC calculated over the 312 original uncompressed header; if the decompessor fails to validate 313 the header, the actions specified in section 3.3.2 must be taken. 315 3.3.2. Actions upon failure 317 For profiles supporting context replication, the feedback logic of a 318 decompressor is similar to the logic used for context initialization, 319 as described in [RFC-3095]. 321 Specifically, when the decompressor fails to validate the context 322 following the decompression of one or more initial IR-REPLICATE 323 packets, it MUST invalidate the context and remain in its initial 324 state. In addition, the decompressor SHOULD send a STATIC-NACK. 326 If the context has been successfully validated from the decompression 327 of one or more initial IR-REPLICATE packets, the decompressor SHOULD 328 send a NACK when it fails to verify the context following the 329 decompression of one or more subsequent IR-REPLICATE packets. 331 The decompressor SHOULD send an ACK when it succeeds to validate the 332 context as a result of the decompression of one or more IR-REPLICATE 333 packets. 335 3.4. Packet Formats 337 The format of the IR-REPLICATE packet has been designed under the 338 following constraints: 340 a) it must be possible to either overwrite a CID during context 341 replication, or to use a CID different than the Base CID for 342 the replicated context; 343 b) it must be possible to replicate from a base context using a 344 profile different than the one associated with the replicated 345 context, for fields specifically common to both profiles; 346 c) it must be possible to selectively include or exclude from the 347 packet format some fields that may be replicable; 348 d) it must be possible for some fields that may be replicable to be 349 represented within the packet format using either a compressed or 350 an uncompressed form; 351 e) it must be possible for the decompressor to verify the success of 352 the replication procedure; 353 f) it is anticipated that profiles other than [ROHC-TCP] will also 354 define support for context replication, therefore it is desirable 355 that the packet format be as profile independent as possible. 357 3.4.1. CRCs in the IR-REPLICATE packet 359 The IR packet, as defined in [RFC-3095], is used to communicate 360 static and/or dynamic parts of a context, and typically initialize 361 the context. The static and dynamic chains of IR packets contains an 362 uncompressed representation of the original header. 364 The IR packet format includes an 8-bit CRC, calculated over the 365 initial part of the IR packet. This CRC is meant to protect any 366 information that initialize the context. In particular, its coverage 367 always includes any CID information as well as the profile used to 368 interpret the remainder of the IR packet. 370 The purpose of the 8-bit CRC is to ensure the integrity of the IR 371 header itself. Profiles may extend the coverage of this CRC to 372 include the entire IR header, thus allowing the verification of the 373 integrity of the entire uncompressed header. However because the 374 format of the IR packet is common to all ROHC profiles and verified 375 as part of the initial processing of a ROHC decompressor (see [RFC- 376 3095, section 5.2.6.]), profiles may not redefine this CRC beyond the 377 extent of its coverage. 379 [RFC-3095] also defines a 3-bit CRC and a 7-bit CRC for compressed 380 headers, used to verify proper decompression and validate the 381 context. This type of CRC is calculated over the original 382 uncompressed header, as it is not sufficient to only protect the 383 compressed data being exchanged between compressor and decompressor 384 to ensure a robust reconstruction of the original header. 386 There is thus a clear distinction in purposes between the 8-bit CRC 387 found in the IR packet and the 3-bit or 7-bit CRC found in compressed 388 headers. With context replication, where the IR-REPLICATE packet may 389 contain both compressed as well as uncompressed information and omit 390 entirely replicable fields, this distinction in no longer present. 392 Profiles supporting context replication MUST define a CRC over the 393 original uncompressed header as part of the profile specific 394 information in the IR-REPLICATE packet. This is necessary to allow a 395 decompressor to verify that the replication process has succeeded. 397 3.4.1.1. 7-bit CRC 399 The 7-bit CRC in the IR-REPLICATE packet is calculated over all 400 octets of the entire original header, before replication, in the same 401 manner as described in [RFC-3095, section 5.9.2]. 403 The initial content of the CRC register is to be preset to all 1's. 405 The CRC polynomial used for the 7-bit CRC in the IR-REPLICATE is: 407 C(x) = 1 + x + x^2 + x^3 + x^6 + x^7 409 3.4.1.2. 8-bit CRC 411 The coverage of the 8-bit CRC in the IR-REPLICATE packet is profile- 412 dependent, but it MUST cover at least the initial part of the packet 413 ending with the Profile field and if present, the Base CID field. For 414 profiles that define the usage of the Base CID within the packet 415 format of the IR-REPLICATE as optional, the CRC MUST also cover the 416 information used to indicate the presence of this field within the 417 packet. Any other information which initializes the context of the 418 decompressor should also be protected by the CRC. 420 The initial content of the CRC register is to be preset to all 1's. 422 The CRC polynomial used for the 8-bit CRC in the IR-REPLICATE is: 424 C(x) = 1 + x + x^2 + x^8 426 3.4.2. General Format of the IR-REPLICATE packet 428 The context replication mechanism requires a dedicated IR packet 429 format that uniquely identifies the IR-REPLICATE packet. This packet 430 communicates the static and the dynamic parts of the replicated 431 context. It may also communicate a reference to a base context. 433 With consideration to the extensibility of the IR packet type defined 434 in [RFC-3095], support for replication can be added using the profile 435 specific part of the IR packet. Note that there is one bit, (x), left 436 in the IR header for "Profile specific information". The definition 437 of this bit is profile-specific. Thus, profiles supporting context 438 replication may use this bit as a flag indicating whether the packet 439 is an IR packet or an IR-REPLICATE packet. Note also that profiles 440 may define an alternative method to identify the IR-REPLICATE packet 441 within the profile specific information, instead of using this bit. 443 The IR-REPLICATE header associates a CID with a profile, and 444 initializes the context using the context replication mechanism. It 445 is not recommended to use this packet to repair a damaged context. 447 The IR-REPLICATE has the following general format: 449 0 1 2 3 4 5 6 7 450 --- --- --- --- --- --- --- --- 451 : Add-CID octet : if for small CIDs and (CID != 0) 452 +---+---+---+---+---+---+---+---+ 453 | 1 1 1 1 1 1 0 x | IR type octet 454 +---+---+---+---+---+---+---+---+ 455 : : 456 / 0-2 octets of CID / 1-2 octets if for large CIDs 457 : : 458 +---+---+---+---+---+---+---+---+ 459 | Profile | 1 octet 460 +---+---+---+---+---+---+---+---+ 461 | CRC | 1 octet 462 +---+---+---+---+---+---+---+---+ 463 | | 464 / profile specific information / variable length 465 | | 466 +---+---+---+---+---+---+---+---+ 467 | | 468 | Static replication chain / variable length 469 | | 470 +---+---+---+---+---+---+---+---+ 471 | | 472 / Dynamic replication chain / variable length 473 | | 474 - - - - - - - - - - - - - - - - 475 | | 476 / Payload / variable length 477 | | 478 - - - - - - - - - - - - - - - - 480 x: Profile specific information. Interpreted according to the 481 profile indicated in the Profile field. 483 Profile: The profile to be associated with the CID. In the IR- 484 REPLICATE packet, the profile identifier is abbreviated to the 485 8 least significant bits. It selects the highest-number 486 profile in the channel state parameter PROFILES that matches 487 the 8 LSBs given (see also [RFC-3095]). 489 CRC: 8-bit CRC computed using the polynomial of section 3.4.1.2. 491 Profile specific information: The contents of this part of the IR- 492 REPLICATE packet are defined by the individual profiles. This 493 information is interpreted according to the profile indicated 494 in the Profile field. It MUST include a 7-bit CRC over the 495 original uncompressed header using the polynomial of section 496 3.4.1.1. 498 Static replication chain: A chain of static subheader information 499 used for replication. 501 Dynamic replication chain: A chain of dynamic subheader 502 information used for replication. What dynamic information is 503 present is inferred from the static replication chain. 505 Payload: The payload of the corresponding original packet, if any. 506 The presence of a payload is inferred from the packet length. 508 4. Security considerations 510 This document does not bring any new additional security 511 considerations than those already listed in [ROHC-TCP]. 513 5. Acknowledgements 515 The author would like to thank Lars-Erik Jonsson, Richard Price, Mark 516 West and HongBin Liao for valuable input to this document. 518 6. References 520 6.1. Normative References 522 [RFC-768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 523 August 1980. 525 [RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791, 526 September 1981. 528 [RFC-793] Postel, J., "Transmission Control Protocol," RFC 793 529 (STD7), September 1981. 531 [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 532 (IPv6) Specification", RFC 2460, December 1998. 534 [RFC-3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, 535 H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., 536 Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, 537 K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust 538 Header Compression (ROHC): Framework and four profiles: 539 RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. 541 [UDP-Lite] Larzon, L., Degermark, M., Pink, S., Jonsson, L., 542 Fairhurst, G., "The UDP-Lite Protocol", Internet draft 543 (work in progress), December 2002, 546 6.2. Informative References 548 [ROHC-TCP] Pelletier, G., Zhang, Q., Jonsson, L-E., Liao, H., West, 549 M., "RObust Header Compression (ROHC): TCP/IP Profile 550 (ROHC-TCP)", Internet Draft (work in progress), , May 2003. 553 [TCP-REQ] Jonsson, L-E., "Requirements on ROHC IP/TCP header 554 compression", Internet Draft (work in progress), 555 , October 2002. 557 [TCP-BEH] West, M. and S. McCann, "TCP/IP Field Behavior", Internet 558 Draft (work in progress), , March 2003. 561 [RFC-2026] Bradner, S., "The Internet Standards Process", RFC 2026, 562 October 1996. 564 7. Author's address 566 Ghyslain Pelletier 567 Box 920 568 Ericsson AB 569 SE-971 28 Lulea, Sweden 571 Phone: +46 920 20 24 32 572 Fax: +46 920 20 20 99 573 Email: ghyslain.pelletier@epl.ericsson.se 575 Appendix A. Replication chains 577 This section provides examples of static and dynamic replication 578 chains for IPv6, IPv4, UDP, UDP-Lite and TCP. 580 A.1. Replication of the IPv6 Header [RFC-2460] 582 Static part: 584 +---+---+---+---+---+---+---+---+ 585 | F | N | S | D |Flow Label(msb)| 586 +---+---+---+---+---+---+---+---+ 587 / Flow Label (lsb) / 2 octets, if F = 1 588 +---+---+---+---+---+---+---+---+ 589 | Next Header | 1 octet, if N = 1 590 +---+---+---+---+---+---+---+---+ 591 / Source Address / 16 octets, if S = 1 592 +---+---+---+---+---+---+---+---+ 593 / Destination Address / 16 octets, if D = 1 594 +---+---+---+---+---+---+---+---+ 596 Dynamic part: 598 +---+---+---+---+---+---+---+---+ 599 | Traffic Class | 1 octet 600 +---+---+---+---+---+---+---+---+ 601 | Hop Limit | 1 octet 602 +---+---+---+---+---+---+---+---+ 603 / Generic extension header list / variable length 604 +---+---+---+---+---+---+---+---+ 606 Eliminated: 608 Payload Length 609 Version 611 Replicable: 613 Flow Label (Flow Label must be all '0's) 615 Flow Label must not be used, i.e. this field must be all '0's. 616 Note that the Flow Label(msb) field is valid only if F = 1. 618 Next Header 620 The type of the following header in the static replication 621 chain must be the same type as the one found in the static 622 chain of the base context. 624 Source Address 625 Destination Address 627 Extras: 629 F, N, S and D: replication flags. 630 Generic extension header list: see [RFC-3095, section 5.7.7.3]. 632 CRC-DYNAMIC: Payload Length field (octets 5-6). 634 CRC-STATIC: All other fields (octets 1-4, 7-40). 636 CRC coverage for extension headers is defined in [RFC-3095, section 637 5.8.7]. 639 Note: The Next Header field indicates the type of the following 640 header in the static chain, rather than being a copy of the Next 641 Header field of the original IPv6 header. See also [RFC-30905, 642 section 5.7.7.8]. 644 Note: When using context replication from a base context where the 645 static part contains multiple IP levels for a flow with a different 646 number of IP levels, only the outer IP header can be replicated. 648 A.2. Replication of the IPv4 Header [RFC-791] 650 Static part: 652 +---+---+---+---+---+---+---+---+ 653 | P | S | D | DF|RND|NBO| 0 | 654 +---+---+---+---+---+---+---+---+ 655 | Protocol | 1 octets, if P = 1 656 +---+---+---+---+---+---+---+---+ 657 / Source Address / 4 octets, if S = 1 658 +---+---+---+---+---+---+---+---+ 659 / Destination Address / 4 octets, if D = 1 660 +---+---+---+---+---+---+---+---+ 662 Dynamic part: 664 +---+---+---+---+---+---+---+---+ 665 | Type of Service | 666 +---+---+---+---+---+---+---+---+ 667 | Time to Live | 668 +---+---+---+---+---+---+---+---+ 669 / Identification / 2 octets 670 +---+---+---+---+---+---+---+---+ 671 / Generic extension header list / variable length 672 +---+---+---+---+---+---+---+---+ 674 Eliminated: 676 IHL, Total Length, MF flag, Fragment Offset, Header Checksum, 677 Options, Padding and Version. See also [RFC-3095, section 678 5.7.7.4]. 680 Replicable: 682 Protocol 684 The type of the following header in the static replication 685 chain must be the same type as the one found in the static 686 chain of the base context. 688 Source Address 689 Destination Address 691 Extras: 693 P, S and D: replication flags. 694 RND, NBO. See [RFC-3095, section 5.7]. 696 CRC-DYNAMIC: Total Length, Identification, Header Checksum 697 (octets 3-4, 5-6, 11-12). 699 CRC-STATIC: All other fields (octets 1-2, 7-10, 13-20) 701 CRC coverage for extension headers is defined in [ROHC, section 702 5.8.7]. 704 Note: The Protocol field indicates the type of the following header 705 in the static chain, rather than being a copy of the Protocol field 706 of the original IPv4 header. See also [RFC-3095, section 5.7.7.8]. 708 Note: When using context replication from a base context where the 709 static part contains multiple IP levels for a flow with a different 710 number of IP levels, only the outer IP header can be replicated. 712 A.3. Replication of the UDP Header [RFC-768] 714 <# Author's Is it possible to identify a useful scenario where #> 715 <# note : replication of the UDP part of a context is #> 716 <# desirable? It is not clear how much value there is #> 717 <# the UDP header. For UDP, the static and dynamic #> 718 <# chains found in [RFC-3095] could be used. #> 720 Static part: 722 +---+---+---+---+---+---+---+---+ 723 | S | SC| D | DC| C | 0 | 724 +---+---+---+---+---+---+---+---+ 725 : : Present if S = 1 and 726 / Source Port / 1 octet if SC = 1 727 : : 2 octets if SC = 0 728 +---+---+---+---+---+---+---+---+ 729 : : Present if D = 1 and 730 / Destination Port / 1 octet if DC = 1 731 : : 2 octets if DC = 0 732 +---+---+---+---+---+---+---+---+ 734 Dynamic part: 736 +---+---+---+---+---+---+---+---+ 737 / Checksum / 2 octets, present if C = 1 738 +---+---+---+---+---+---+---+---+ 740 Eliminated: 742 Length 744 The Length field of the UDP header MUST match the Length field(s) 745 of the preceding subheaders, i.e., there must not be any padding 746 after the UDP payload that is covered by the IP Length. 748 Replicable: 750 Source Port 751 Destination Port 752 Checksum 754 Extras: 756 S, SC, D, DC, C: replication flags. 758 CRC-DYNAMIC: Length field, Checksum (octets 5-8). 760 CRC-STATIC: All other fields (octets 1-4). 762 A.4. Replication of the UDP-Lite Header [UDP-Lite] 764 <# Author's Is it possible to identify a useful scenario where #> 765 <# note : replication of the UDP-Lite part of a context is #> 766 <# desirable? It is not clear how much value there #> 767 <# is to replicate parts of the UDP-Lite header. For #> 768 <# UDP-Lite, the static and dynamic chains defined in #> 769 <# the UDP-Lite profile could be used. #> 771 Static part: 773 +---+---+---+---+---+---+---+---+ 774 | S | SC| D | DC| C | CC| 0 | 775 +---+---+---+---+---+---+---+---+ 776 : : Present if S = 1 and 777 / Source Port / 1 octet if SC = 1 778 : : 2 octets if SC = 0 779 +---+---+---+---+---+---+---+---+ 780 : : Present if D = 1 and 781 / Destination Port / 1 octet if DC = 1 782 : : 2 octets if DC = 0 783 +---+---+---+---+---+---+---+---+ 785 Dynamic part: 787 +---+---+---+---+---+---+---+---+ 788 : : Present if C = 1 and 789 / Checksum Coverage / 1 octet if CC = 1 790 : : 2 octets if CC = 0 791 +---+---+---+---+---+---+---+---+ 792 / Checksum / 2 octets 793 +---+---+---+---+---+---+---+---+ 795 Replicable: 797 Source Port 798 Destination Port 799 Checksum Coverage 800 Checksum 802 Extras: 804 S, SC, D, DC, C, CC: replication flags. 806 CRC-DYNAMIC: Checksum Coverage field, Checksum field (octets 5-8). 808 CRC-STATIC: All other fields (octets 1-4). 810 A.5. Replication of the TCP Header [RFC-793] 812 Static part: 814 +---+---+---+---+---+---+---+---+ 815 | S | SC| D | DC| W | U | M | 0 | 816 +---+---+---+---+---+---+---+---+ 817 : : Present, if S = 1 and 818 / Source Port / 1 octet, if SC = 1 819 : : 2 octets, if SC = 0 820 +---+---+---+---+---+---+---+---+ 821 : : Present, if D = 1 and 822 / Destination Port / 1 octet, if DC = 1 823 : : 2 octets, if DC = 0 824 +---+---+---+---+---+---+---+---+ 826 Dynamic part: 828 +---+---+---+---+---+---+---+---+ 829 / Master Sequence Number / 2 octets, if M = 1 830 +---+---+---+---+---+---+---+---+ 831 / Sequence Number / 4 octets 832 +---+---+---+---+---+---+---+---+ 833 / Acknowledgement Number / 4 octets 834 +---+---+---+---+---+---+---+---+ 835 | Data Offset | Reserved | 1 octet 836 +---+---+---+---+---+---+---+---+ 837 |CWR|ECE|URG|ACK|PSH|RST|SYN|FIN| 1 octet 838 +---+---+---+---+---+---+---+---+ 839 / Window / 2 octets, present if W = 1 840 +---+---+---+---+---+---+---+---+ 841 / Checksum / 2 octets 842 +---+---+---+---+---+---+---+---+ 843 / Urgent Pointer / 2 octets, present if U = 1 844 +---+---+---+---+---+---+---+---+ 845 / Options / variable length 846 +---+---+---+---+---+---+---+---+ 848 Eliminated: 850 Nothing. 852 Extras: 854 S, SC, D, DC, W, U, M: replication flags. 856 Replicable: 858 Source Port 859 Destination Port 860 Master Sequence Number 862 Window 863 Urgent Pointer 865 CRC-DYNAMIC: Length field, Checksum (octets 5-8). 867 CRC-STATIC: All other fields (octets 1-4). 869 Note: This chain is always the last chain in the IR-Replicate packet. 871 Full Copyright Statement 873 Copyright (C) The Internet Society (2003). All Rights Reserved. 875 This document and translations of it may be copied and furnished to 876 others, and derivative works that comment on or otherwise explain it 877 or assist in its implementation may be prepared, copied, published 878 and distributed, in whole or in part, without restriction of any 879 kind, provided that the above copyright notice and this paragraph are 880 included on all such copies and derivative works. However, this 881 document itself may not be modified in any way, such as by removing 882 the copyright notice or references to the Internet Society or other 883 Internet organizations, except as needed for the purpose of 884 developing Internet standards in which case the procedures for 885 copyrights defined in the Internet Standards process must be 886 followed, or as required to translate it into languages other than 887 English. 889 The limited permissions granted above are perpetual and will not be 890 revoked by the Internet Society or its successors or assigns. 892 This document and the information contained herein is provided on an 893 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 894 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 895 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 896 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 897 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 899 This Internet-Draft expires November 23, 2003.