Network Working Group G. Pelletier Request for Comments: 4164 Ericsson Category: Standards Track August 2005 RObust Header Compression (ROHC): Context Replication for ROHC Profiles Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005).
AbstractThis document defines context replication, a complement to the context initialization procedure found in Robust Header Compression (ROHC), as specified in RFC 3095. Profiles defining support for context replication may use the mechanism described herein to establish a new context based on another already existing context. Context replication is introduced to reduce the overhead of the context establishment procedure. It may be especially useful for the compression of multiple short-lived flows that may be occurring simultaneously or near-simultaneously, such as short-lived TCP flows.
1. Introduction ....................................................3 2. Terminology .....................................................4 3. Context Replication for ROHC Profiles ...........................5 3.1. Robustness Considerations ..................................5 3.2. Replication of Control Fields ..............................5 3.3. Compressor States and Logic ................................6 3.3.1. Context Replication (CR) State ......................6 3.3.2. State Machine with Context Replication ..............7 3.3.3. State Transition Logic ..............................7 220.127.116.11. Selection of Base Context, Upward Transition .................................8 18.104.22.168. Optimistic Approach, Upward Transition .....9 22.214.171.124. Optional Acknowledgements (ACKs), Upward Transition ..........................9 126.96.36.199. Negative ACKs (NACKs), Downward Transition .................................9 3.4. Decompressor Logic ........................................10 3.4.1. Replication and Context Initialization .............10 3.4.2. Reconstruction and Verification ....................10 3.4.3. Actions upon Failure ...............................11 3.4.4. Feedback Logic .....................................11 3.5. Packet Formats ............................................11 3.5.1. CRCs in the IR-CR Packet ...........................12 188.8.131.52. 7-bit CRC .................................13 184.108.40.206. 8-bit CRC .................................13 3.5.2. General Format of the IR-CR Packet .................13 3.5.3. Properties of the Base Context Identifier (BCID) ...15 4. Security Considerations ........................................15 5. Acknowledgements ...............................................15 6. References .....................................................16 6.1. Normative References ......................................16 6.2. Informative References ....................................16 Appendix A: General Format of the IR-CR Packet (Informative).......17 A.1. General Structure (Informative) ..........................17 A.2. Profile-Specific Replication Information (Informative) ...17 Appendix B: Inter-Profile Context Replication (Informative)........18 B.1. Defining Support for Inter-Profile Context Replication ...18 B.2. Compatibility between Different Profiles (Informative) ...19
5]. In addition,  introduces considerations and requirements for the ROHC-TCP profile  to efficiently compress such short-lived TCP transfers. For profiles supporting this mechanism, the compressor performs context replication by reusing or creating a copy of an existing context, i.e., a base context, to create the replicated context. The replicated context is then updated to match the header fields of the new flow. The compressor then sends to the decompressor a packet that contains a reference to the selected base context, along with some data for the fields that need to be updated when creating the
replicated context. Finally, the decompressor creates the replicated context based on the reference to the base context along with the uncompressed and compressed data from the received packet. This document specifies the context replication procedure for ROHC profiles. It defines the general compressor and decompressor logic used during context replication, as well as the general format of the special IR packet required for this procedure. Profiles defining support for context replication must further specify the specific format(s) of this packet. The fundamentals of the ROHC framework may be found in . It is assumed throughout this document that these are understood. RFC 2119 . This document reuses some of the terminology found in . In addition, this document defines the following terms: Base context A base context is a context that has been validated by both the compressor and the decompressor. The compressor can use a base context as the reference when building a new context using replication. Base CID (BCID) The Base Context Identifier is the CID used to identify the base context, from which information needed for context replication can be extracted. Context replication Context replication is the mechanism that initializes a new context based on another already existing context (a base context).
2]. Note that for such profiles, only the decompressor is mandated to support context replication; the use of the IR-CR packet is optional for the compressor. This section describes the compressor and decompressor logic as well as the general format of the IR packet used with context replication. 2] in that it is able to achieve a certain level of compression from the first packet used to initialize the context for a new flow. Therefore, it is of particular importance that the context replication procedure be robust. This requires that a base context suitable for replication be used, that the integrity of the initialization packet be guaranteed, and finally that the outcome of the replication process be verified. The primary mechanisms used to achieve robustness of the context replication procedure are the selection of the base context (based on prior feedback from the decompressor) and the use of checksums. Specifically, the compressor must obtain enough confidence that the base context selected for replication is valid and available at the decompressor before initiating the replication procedure. Thus, the most reliable way to select the base context is to choose a context for which at least the static part to be replicated has previously been acknowledged by the decompressor. In addition, the presence of a CRC covering the information that initializes the context ensures the integrity of the IR header used for replication. Finally, an additional CRC calculated over the original uncompressed header allows the decompressor to validate the reconstructed header and the outcome of the replication process. 2], which indicate whether the IP-ID field is in Network
Byte Order and the type of behavior of the field, respectively. Another example is the parameter indicating the mode of operation . The IR-CR differs from the IR packet  in that its purpose is to entirely specify what part of the base context is replicated, and to convey the complementary information needed to create a new context. Because of this, a profile supporting the use of the IR-CR packet SHOULD define for each control field if the value of the field is replicated from the base context to the new context, or if its value is reinitialized. In addition, a compressor MUST NOT initiate context replication while a control field that is not reinitialized by replication is being updated, e.g., during the handshake for a mode transition .
The compressor stays in the CR state until it is confident that the decompressor has received the replication information correctly. Section 220.127.116.11). The transition from the CR state to a higher compression state (e.g., the CO state for ) is based on the optimistic approach principle or feedback received from the decompressor. The figure below shows the additional state for the compressor. The details of the state transitions and compression logic are given in sub-sections following the figure. BCID selection Optimistic approach / ACK +----->----->------+ +----->----->----->-----+ | | | | | v | v +---------+ +---------+ +-------------+ | IR | | CR | | Higher | | state | | state | | order state | +---------+ +---------+ +-------------+ ^ | | NACK / STATIC-NACK | +---<-----<-----<----+ Note that context replication is a complement to the normal initialization procedure for ROHC profiles that support it. Therefore, the compressor transition to the CR state is an optional addition to the state machine, and does not affect already existing transitions between the IR state and higher order state(s).
Context replication is designed to operate over links where a feedback channel is available. This is necessary to ensure that the information used to create a new context is synchronized between the compressor and the decompressor. In addition, context replication may also make use of feedback from decompressor to compressor for transition back to the IR state and for OPTIONAL improved forward transition towards a state with a higher compression ratio. The format that must be used by all profiles for the feedback field within the general ROHC format is specified in Section 5.2.2 of ; the feedback information is structured using two possible formats: FEEDBACK-1 and FEEDBACK-2. In particular, FEEDBACK-2 can carry one of three possible types of feedback information: ACK, NACK, or STATIC-NACK. 2], Section 18.104.22.168) in the feedback message. The static part of the base context to be replicated MUST have been acknowledged by the decompressor and the base context MUST be valid at replication time. This also implies that a compressor is not allowed to use the context replication mechanism if a feedback channel is not present. However, note that the presence of the feedback channel cannot provide the guarantee that a base context selected for replication has not been corrupted after it has been acknowledged, or that it is still part of the state managed by the decompressor when the IR-CR will be received. More specifically, RFC 3095  defines the context identifier (CID) as a reference to the state information (i.e., the context) used for compression and decompression. Multiple packet streams, each having its own context, may thus share a channel; and the CID space along with its representation within packet formats may be negotiated as part of the channel state. However, because RFC 3095  does not explicitly define context state management between compressor and decompressor, in particular for connection-oriented flows (e.g., TCP), no more than a high degree of confidence can be achieved when selecting a base context.
In the case where feedback is not used by the decompressor, the compressor may have to periodically transit back to the IR state. In such a case, the same logic applies for the transition back to the higher order state via the CR state: a base context, previously acknowledged and suitable for replication, must be re-selected. The criteria for whether an existing context is a suitable base context for replication for a new flow are left to implementations. Whenever the sequencing information from the last acknowledgement received is available, the compressor MAY use it to determine what fields can be replicated to avoid replicating any fields that have changed significantly from the state corresponding to the acknowledged packet.
STATIC-NACK makes this context suitable for replication (Section 22.214.171.124). The compressor SHOULD re-initialize the decompressor context using an IR packet. A NACK sent by the decompressor may indicate that a valid context has been successfully initialized but that the decompression of one or more subsequent packets has failed. Upon reception of a NACK, the compressor MAY assume that the static part of the decompressor context is valid, but that the dynamic part is invalid; the compressor may take actions accordingly. 2], Section 5.2.6). The profile indicated in the IR-CR packet determines how it is to be processed. If the CRC (8-bit CRC) fails to verify the packet, the packet MUST be discarded. If the profile as indicated in the IR-CR packet defines the use of the Base CID, and if its corresponding field is present within the packet format, this field is used to identify the base context; otherwise, the CID is used. Section 3.4.3 are taken.
2]. Specifically, when the decompressor fails to validate the context following the decompression of one or more initial IR-CR packets, it MUST invalidate the context and remain in its initial state. In addition, the decompressor SHOULD send a STATIC-NACK. In particular, a decompressor implementation performing strict memory management, such as deleting context state information when a connection-oriented flow (e.g., TCP) is known to have terminated, SHOULD send STATIC-NACK in this case. Otherwise, there is a risk that the compressor will maintain a specific CID as a potential candidate for a later replication attempt, while actually there is insufficient state left in the decompressor for this CID to act as a Base CID. If the context has been successfully validated from the decompression of one or more initial IR-CR packets, the decompressor SHOULD send a NACK when it fails to verify the context following the decompression of one or more subsequent IR-CR packets. 2], Section 126.96.36.199) when sending feedback corresponding to an IR or an IR-CR packet. 3], will also define support for context replication. Therefore it is desirable that the packet format be profile independent.
2], is used to communicate static and/or dynamic parts of a context, and typically initialize the context. For example, the static and dynamic chains of IR packets may contain an uncompressed representation of the original header. The IR packet format includes an 8-bit CRC, calculated over the initial part of the IR packet. This CRC is meant to protect any information that initializes the context. In particular, its coverage always includes any CID information as well as the profile used to interpret the remainder of the IR packet. The purpose of the 8-bit CRC is to ensure the integrity of the IR header itself. Profiles may extend the coverage of this CRC to include the entire IR header, thus allowing the verification of the integrity of the entire uncompressed header. However, because the format of the IR packet is common to all ROHC profiles and verified as part of the initial processing of a ROHC decompressor (see , Section 5.2.6.), profiles may not redefine this CRC beyond the extent of its coverage. RFC 3095  also defines a 3-bit CRC and a 7-bit CRC for compressed headers, used to verify proper decompression and validate the context. This type of CRC is calculated over the original uncompressed header, as it is not sufficient to protect only the compressed data being exchanged between compressor and decompressor for the purpose of ensuring a robust reconstruction of the original header. Thus, there is a clear distinction in purpose between the 8-bit CRC found in the IR packet and the 3-bit or 7-bit CRC found in compressed headers. With context replication, where the IR-CR packet may contain both compressed as well as uncompressed information and omit entirely replicable fields, this distinction in no longer present. Profiles supporting context replication MUST define a CRC over the original uncompressed header as part of the profile-specific information in the IR-CR packet. This is necessary to allow a decompressor to verify that the replication process has succeeded.
Section 5.9.2 of . The initial content of the CRC register is to be preset to all 1's. The CRC polynomial used for the 7-bit CRC in the IR-CR is: C(x) = 1 + x + x^2 + x^3 + x^6 + x^7 2], Sections 5.2.3 and 5.2.4). It MUST cover the entire packet, excluding the payload. In particular, this includes the CID or any add-CID octet as well as the Base CID field, if present. For profiles that define the usage of the Base CID within the packet format of the IR-CR as optional, this CRC MUST also cover the information used to indicate the presence of this field within the packet. The initial content of the CRC register is to be preset to all 1's. The CRC polynomial used for the 8-bit CRC in the IR-CR is: C(x) = 1 + x + x^2 + x^8 2], support for replication can be added using the profile- specific part of the IR packet. Note that there is one bit, (x), left in the IR header for "Profile specific information". The definition of this bit is profile specific. Thus, profiles supporting context replication MAY use this bit as a flag indicating whether the packet is an IR packet or an IR-CR packet. Note also that profiles may define an alternative method to identify the IR-CR packet within the profile-specific information, instead of using this bit. The IR-CR header associates a CID with a profile, and initializes the context using the context replication mechanism. It is not recommended to use this packet to repair a damaged context.
The IR-CR has the following general format: 0 1 2 3 4 5 6 7 --- --- --- --- --- --- --- --- : Add-CID octet : if for small CIDs and (CID != 0) +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 1 0 x | IR type octet +---+---+---+---+---+---+---+---+ : : / 0-2 octets of CID / 1-2 octets if for large CIDs : : +---+---+---+---+---+---+---+---+ | Profile | 1 octet +---+---+---+---+---+---+---+---+ | CRC | 1 octet +---+---+---+---+---+---+---+---+ | | / Profile-specific information / variable length | | - - - - - - - - - - - - - - - - | | / Payload / variable length | | - - - - - - - - - - - - - - - - x: Profile-specific information. Interpreted according to the profile indicated in the Profile field. Profile: The profile to be associated with the CID. In the IR-CR packet, the profile identifier is abbreviated to the 8 least significant bits (LSBs). It selects the highest- number profile in the channel state parameter PROFILES that matches the 8 LSBs given (see also ). CRC: 8-bit CRC computed using the polynomial of Section 188.8.131.52. Profile-specific information: The contents of this part of the IR-CR packet are defined by the individual profiles. This information is interpreted according to the profile indicated in the Profile field. It MUST include a 7-bit CRC over the original uncompressed header using the polynomial of Section 184.108.40.206. It also includes the static and dynamic subheader information used for replication; thus, which header fields are replicated and their respective encoding methods are outside the scope of this document.
Payload: The payload of the corresponding original packet, if any. 2] are not needed for the BCID, as this information is already provided by the CID of the IR-CR packet itself. When large CIDs are used, the BCID is represented in the IR-CR with one or two octets, and it is coded in the same way as a large CID . RFC 3095 . In this respect, this document is not believed to bring any additional weakness to potential attacks to those already listed in . However, it does increase the potential impacts of these attacks by creating dependencies between multiple contexts. Specifically, corruption of one context can fail compressor attempts to initialize another context at the decompressor, or to propagate to another context, if the compressor uses a corrupted context as a base for replication.
 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.  Pelletier, G., Jonsson, L-E., Sandlund, K., and M. West, "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)", Work in Progress, July 2005.  Jonsson, L-E., "RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression", RFC 4163, August 2005.  West, M. and S. McCann, "TCP/IP Field Behavior", Work in Progress, October 2004.  Finking, R. and G. Pelletier, "Formal Notation for Robust Header Compression (ROHC-FN)", Work in Progress, June 2005.
0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | | / replication base information / variable length | | +---+---+---+---+---+---+---+---+ | | / replication information / variable length | | - - - - - - - - - - - - - - - - Replication base information: The contents of this part of the IR-CR packet are defined by the individual profiles. This information is interpreted according to the profile indicated in the Profile field. It MUST include a 7-bit CRC over the original uncompressed header using the polynomial of Section 220.127.116.11. See Appendix A.2. Replication information: The contents of this part of the IR-CR packet are also defined by the individual profiles. This part contains the static and dynamic subheader information used for replication. How this information is structured is profile specific; profiles may define the contents of this field using a chain structure (static and dynamic replication chains) or by defining header formats for replication (e.g., ROHC-TCP ). Appendix A.1: +---+---+---+---+---+---+---+---+ | B | CRC7 | 1 octet +---+---+---+---+---+---+---+---+ | | present if B = 1, / Base CID / 1 octet if for small CIDs, or | | 1-2 octets if for large CIDs +---+---+---+---+---+---+---+---+
B: B = 1 indicates that the Base CID field is present. CRC7: The CRC over the original, uncompressed, header. This 7-bit CRC is computed according to Section 18.104.22.168. Base CID: The CID identifying the base context used for replication. 6]) or a textual description (i.e., a la RFC 3095 ) of its behaviour. To compress one or more fields of a specific protocol stack, different profiles may define their packet formats using different encoding methods, or using a variant of a similar technique. A typical example of the latter is list compression, such as used for IP extension headers. This implies that context entries for a field belonging to a specific protocol stack may differ in their content, representation, and structure from one profile to another.
As a consequence of the above, a profile that supports context replication can only use a base context from another profile explicitly supporting the concept of a base context. That is, existing profiles not supporting this concept must be updated first to ensure that they can export the necessary context data entries that use a meaningful representation during replication. Specifically, inter-profile context replication would require that decompressor implementations (including existing ones) of other profiles be updated when adding support for a profile that uses context replication. Therefore, inter-profile context replication cannot be seen as an implementation-specific issue. The compressor must know if the decompressor supports inter-profile context replication before initiating the procedure. The compressor must also know which contexts (belonging to which profile) may be used as a base context. Therefore, a compressor cannot initiate context replication using a base context belonging to a different profile, unless that profile explicitly provides the proper mapping for its context entries or that profile is defined formally using ROHC-FN  in a manner that makes both profiles compatible. The set of profiles negotiated for the channel (see also RFC 3095 ) can then be used to determine if a context for a specific profile can be used as a base context. RFC 3095 , is implicitly compressed using an encoding method equivalent to the static() method defined in ROHC-FN . In particular, for profiles that define their packet formats using a formal notation such as ROHC-FN , two different encoding methods may not have the same name. Thus, a field from a protocol stack is said to be compatible for replication between two different profiles if it has an equivalent definition within respective packet formats.
Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.