From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4164.txt | 1179 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1179 insertions(+) create mode 100644 doc/rfc/rfc4164.txt (limited to 'doc/rfc/rfc4164.txt') diff --git a/doc/rfc/rfc4164.txt b/doc/rfc/rfc4164.txt new file mode 100644 index 0000000..bef593b --- /dev/null +++ b/doc/rfc/rfc4164.txt @@ -0,0 +1,1179 @@ + + + + + + +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). + +Abstract + + This 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. + + + + + + + + + + + + + + + + + + + + +Pelletier Standards Track [Page 1] + +RFC 4164 Context Replication for ROHC Profiles August 2005 + + +Table of Contents + + 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 + 3.3.3.1. Selection of Base Context, Upward + Transition .................................8 + 3.3.3.2. Optimistic Approach, Upward Transition .....9 + 3.3.3.3. Optional Acknowledgements (ACKs), + Upward Transition ..........................9 + 3.3.3.4. 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 + 3.5.1.1. 7-bit CRC .................................13 + 3.5.1.2. 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 + + + + + + + + + + + +Pelletier Standards Track [Page 2] + +RFC 4164 Context Replication for ROHC Profiles August 2005 + + +1. Introduction + + There is often some redundancy between header fields of different + flows that pass through the same compressor-decompressor pair. This + means that some of the information needed to initialize the context + for decompressing the headers of a new flow may already be present at + the decompressor. It may be desirable to reuse this information and + remove some of the overhead normally required for the initialization + of a new header compression context at both the compressor and + decompressor. + + Reducing the overhead of the context establishment procedure is + particularly useful when multiple short-lived connections (or flows) + occur simultaneously, or near-simultaneously, between the same + compressor-decompressor pair. Because each new packet stream + requires most of the header information to be sent during the + initialization phase before smaller compressed headers can be used, a + multitude of short-lived connections may significantly reduce the + overall gain from header compression. + + Context replication allows some header fields, such as the IP source + and/or destination addresses (16 octets each for IPv6), to be omitted + within the special Initiation and Refresh (IR) packet type + specifically defined for replication. It also allows other fields, + such as source and/or destination ports, to be either omitted or sent + in a compressed form from the very first packet of the header + compressed flow. + + Context replication is herein defined as a general ROHC mechanism. + The benefits of context replication are not limited to any particular + protocol and its support may be defined for any ROHC profile. + + In particular, context replication is applicable to TCP compression + because many TCP transfers are short-lived; a behavior analysis of + TCP/IP header fields among multiple short-lived connections may be + found in [5]. In addition, [4] introduces considerations and + requirements for the ROHC-TCP profile [3] 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 + + + + + +Pelletier Standards Track [Page 3] + +RFC 4164 Context Replication for ROHC Profiles August 2005 + + + 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 [2]. It is + assumed throughout this document that these are understood. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + + This document reuses some of the terminology found in [2]. 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). + + + + + + + + + + +Pelletier Standards Track [Page 4] + +RFC 4164 Context Replication for ROHC Profiles August 2005 + + +3. Context Replication for ROHC Profiles + + For profiles defining its support, context replication may be used as + an alternative to the context initialization procedure found in [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. + +3.1. Robustness Considerations + + Context replication deviates from the initialization procedure + defined in [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. + +3.2. Replication of Control Fields + + Control fields are fields that are either transmitted from a ROHC + compressor to a ROHC decompressor or inferred based on the behavior + of other fields, but are not part of the uncompressed header itself. + + They can be used to control compression and decompression behavior, + in particular, the set of packet formats to be used. Control fields + are profile-specific. Examples of such fields include the NBO and + RND flags [2], which indicate whether the IP-ID field is in Network + + + +Pelletier Standards Track [Page 5] + +RFC 4164 Context Replication for ROHC Profiles August 2005 + + + Byte Order and the type of behavior of the field, respectively. + Another example is the parameter indicating the mode of operation + [2]. + + The IR-CR differs from the IR packet [2] 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 [2]. + +3.3. Compressor States and Logic + + Compression with ROHC normally starts in the IR state, where IR + packets must be sent to initialize a new context at the decompressor. + IR packets include all static and non-static fields of the original + header in uncompressed form plus some additional information. The + compressor stays in the IR state until it obtains confidence that the + decompressor has received the information. + + Context replication provides an optional mechanism to complement the + ROHC initialization procedure. It defines a packet type, the IR + packet for Context Replication (IR-CR), which can be used to + initialize a new context. Consequently, the Context Replication (CR) + state is introduced to the compressor state machine to encompass the + additional logic required for the use of the IR-CR packet. + + For profiles defining support for context replication, the compressor + may thus transit directly from the IR state to the CR state if an + already existing context can be selected as a base context for + replication. This effectively replaces any IR/IR-DYN packets sent + during the context establishment procedure with an IR-CR packet. + +3.3.1. Context Replication (CR) State + + The purpose of the CR state is to initialize a new context by reusing + an already existing context. In this state, the compressor sends a + combination of uncompressed and compressed information, along with a + reference to a base context plus some additional information. + Therefore, header information pertaining to fields that are being + replicated is not sent. + + + + + +Pelletier Standards Track [Page 6] + +RFC 4164 Context Replication for ROHC Profiles August 2005 + + + The compressor stays in the CR state until it is confident that the + decompressor has received the replication information correctly. + +3.3.2. State Machine with Context Replication + + The compressor always starts in the lower compression state (IR), and + transits to the context replication state (CR) under the constraint + that the compressor can select a base context that is suitable for + the flow being compressed (see also Section 3.3.3.1). + + The transition from the CR state to a higher compression state (e.g., + the CO state for [3]) 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). + +3.3.3. State Transition Logic + + Decisions about transition to and from the CR state are taken by the + compressor on the basis of: + + - availability of a base context + - positive feedback from the decompressor (Acknowledgements -- ACKs) + - negative feedback from the decompressor (Negative ACKs -- NACKs) + - confidence level regarding error-free decompression of a packet + + + + + + +Pelletier Standards Track [Page 7] + +RFC 4164 Context Replication for ROHC Profiles August 2005 + + + 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 [2]; + 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. + +3.3.3.1. Selection of Base Context, Upward Transition + + The compressor may initiate a transition from the IR state to the CR + state when a suitable base context can be identified. To perform + this transition, the compressor selects a context that has previously + been acknowledged by the decompressor as the base context. The + selected context MUST have been acknowledged by the decompressor + using the CRC option (see also [2], Section 5.7.6.3) 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 [2] 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 [2] 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. + + + + + + +Pelletier Standards Track [Page 8] + +RFC 4164 Context Replication for ROHC Profiles August 2005 + + + 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. + +3.3.3.2. Optimistic Approach, Upward Transition + + Transition to a higher order state can be carried out according to + the optimistic approach principle. This means that the compressor + may perform an upward state transition when it is fairly confident + that the decompressor has received enough information to correctly + decompress packets sent according to the higher compression state. + + In general, there are many approaches where the compressor can obtain + such information. The compressor may obtain its confidence by + sending several IR-CR packets with the same information. + +3.3.3.3. Optional Acknowledgements (ACKs), Upward Transition + + An ACK may be sent by the decompressor to indicate that a context has + been successfully initialized during context replication. + + Upon reception of an ACK, the compressor may assume that the context + replication procedure was successful and transit from its initial + state (e.g., IR state) to a higher compression state. + +3.3.3.4. Negative ACKs (NACKs), Downward Transition + + A STATIC-NACK sent by the decompressor may indicate that the + decompressor could not initialize a valid context during context + replication, and that the corresponding context has been invalidated. + + Upon reception of a STATIC-NACK, the compressor MUST transit back to + its initial no context state. The compressor SHOULD also refrain + from sending IR-CR packets using the same base context, at least + until an acknowledgement subsequent to the reception of the + + + + + +Pelletier Standards Track [Page 9] + +RFC 4164 Context Replication for ROHC Profiles August 2005 + + + STATIC-NACK makes this context suitable for replication (Section + 3.3.3.1). 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. + +3.4. Decompressor Logic + +3.4.1. Replication and Context Initialization + + Upon reception of an IR-CR packet, the decompressor first determines + its content ([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. + +3.4.2. Reconstruction and Verification + + The decompressor creates a new context using the information present + in the IR-CR packet together with the identified base context, and + decompresses the original header. + + The CRC calculated over the original uncompressed header and carried + within the profile-specific part of the IR-CR headers (7-bit CRC) + MUST be used to verify decompression. + + When the decompression is verified and successful, the decompressor + initializes or updates the context with the information received in + the current header. The decompressor SHOULD send an ACK when it + successfully validates the context as a result of the decompression + of one or more IR-CR packets. + + Otherwise, if the reconstructed header fails the CRC check, changes + (either initialization or update) to the context MUST NOT be + performed. When the decompressor fails to validate the header, + actions as specified in Section 3.4.3 are taken. + + + + + +Pelletier Standards Track [Page 10] + +RFC 4164 Context Replication for ROHC Profiles August 2005 + + +3.4.3. Actions upon Failure + + For profiles supporting context replication, the feedback logic of a + decompressor is similar to the logic used for context initialization, + as described in [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. + +3.4.4. Feedback Logic + + The decompressor SHOULD use the CRC option (see [2], Section 5.7.6.3) + when sending feedback corresponding to an IR or an IR-CR packet. + +3.5. Packet Formats + + The format of the IR-CR packet has been designed under the following + constraints: + + a) it must be possible to either overwrite a CID during context + replication, or to use a different CID than the Base CID for the + replicated context; + b) it must be possible to selectively include or exclude from the + packet format some fields that may be replicable; + c) it must be possible for some fields that may be replicable to be + represented within the packet format using either a compressed or + an uncompressed form; + d) it must be possible for the decompressor to verify the success of + the replication procedure; + e) it is anticipated that profiles, other than ROHC-TCP [3], will + also define support for context replication. Therefore it is + desirable that the packet format be profile independent. + + + + + +Pelletier Standards Track [Page 11] + +RFC 4164 Context Replication for ROHC Profiles August 2005 + + +3.5.1. CRCs in the IR-CR Packet + + The IR packet, as defined in [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 [2], + Section 5.2.6.), profiles may not redefine this CRC beyond the extent + of its coverage. + + RFC 3095 [2] 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. + + + + + + + + + + + +Pelletier Standards Track [Page 12] + +RFC 4164 Context Replication for ROHC Profiles August 2005 + + +3.5.1.1. 7-bit CRC + + The 7-bit CRC in the IR-CR packet is calculated over all octets of + the entire original header, before replication, in the same manner as + described in Section 5.9.2 of [2]. + + 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 + +3.5.1.2. 8-bit CRC + + The coverage of the 8-bit CRC in the IR-CR packet is not profile + dependent, as opposed to the ROHC IR(-DYN) packet (see [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 + +3.5.2. General Format of the IR-CR Packet + + The context replication mechanism requires a dedicated IR packet + format that uniquely identifies the IR-CR packet. This packet + communicates the static and the dynamic parts of the replicated + context. It may also communicate a reference to a base context. + + With consideration to the extensibility of the IR packet type defined + in [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. + + + +Pelletier Standards Track [Page 13] + +RFC 4164 Context Replication for ROHC Profiles August 2005 + + + 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 [2]). + + CRC: 8-bit CRC computed using the polynomial of Section + 3.5.1.2. + + 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 3.5.1.1. 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. + + + + +Pelletier Standards Track [Page 14] + +RFC 4164 Context Replication for ROHC Profiles August 2005 + + + Payload: The payload of the corresponding original packet, if + any. + +3.5.3. Properties of the Base Context Identifier (BCID) + + The Base CID within the packet format of the IR-CR may be assigned a + different value than the context identifier associated with the new + flow (i.e., BCID != CID); otherwise, the base context is overwritten + with the new context by the replication process. + + When the channel uses small CIDs, a four-bit field within the packet + format of the IR-CR minimally represents the BCID with a value from 0 + to 15. In particular, the four bits of Add-CID used with small CIDs + [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 [2]. + +4. Security Considerations + + This document adds an alternative mechanism for ROHC profiles to + increase the compression efficiency when initializing a new context, + by reusing information already existing at the decompressor. This is + achieved by introducing new state transition logic, new feedback + logic, and a new packet type -- all based on logic and packet formats + already defined in RFC 3095 [2]. + + In this respect, this document is not believed to bring any + additional weakness to potential attacks to those already listed in + [2]. 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. + +5. Acknowledgements + + The author would like to thank Richard Price, Kristofer Sandlund, + Fredrik Lindstroem, Zhigang Liu, and HongBin Liao for valuable input, + as well as Mark West and Lars-Erik Jonsson who also served as + committed working group document reviewers. + + + + + + + + + +Pelletier Standards Track [Page 15] + +RFC 4164 Context Replication for ROHC Profiles August 2005 + + +6. References + +6.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] 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. + +6.2. Informative References + + [3] 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. + + [4] Jonsson, L-E., "RObust Header Compression (ROHC): Requirements + on TCP/IP Header Compression", RFC 4163, August 2005. + + [5] West, M. and S. McCann, "TCP/IP Field Behavior", Work in + Progress, October 2004. + + [6] Finking, R. and G. Pelletier, "Formal Notation for Robust Header + Compression (ROHC-FN)", Work in Progress, June 2005. + + + + + + + + + + + + + + + + + + + + + + + +Pelletier Standards Track [Page 16] + +RFC 4164 Context Replication for ROHC Profiles August 2005 + + +Appendix A: General Format of the IR-CR Packet (Informative) + +A.1. General Structure (Informative) + + This section provides an example of the format of the profile- + specific information within the general format of the IR-CR. + + 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 3.4.1.1. 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 [3]). + +A.2. Profile-Specific Replication Information (Informative) + + This section provides a more detailed example of the possible format + of the replication information field described in 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 + +---+---+---+---+---+---+---+---+ + + + + + + + +Pelletier Standards Track [Page 17] + +RFC 4164 Context Replication for ROHC Profiles August 2005 + + + 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 3.4.1.1. + + Base CID: The CID identifying the base context used for replication. + +Appendix B: Inter-Profile Context Replication (Informative) + + Context replication as defined in this document does not explicitly + support the concept of context replication between profiles. + However, it might be of interest when developing new compression + profiles. + + Inter-profile context replication would require that the decompressor + have access to data structures from the base context, which belongs + to a profile different than the profile using replication. This + information would have to be made available in a format consistent + with the data structures and encoding method(s) in use for all header + fields that are being replicated. + +B.1. Defining Support for Inter-Profile Context Replication + + A ROHC profile describes how to compress a specific protocol stack, + and includes one or more sets of packet formats. The packet formats + will typically compress the protocol headers relative to a context of + field values from previous headers in a flow. This context may also + contain some control data. Thus, the packet formats specify a + mapping between the uncompressed and compressed version of a protocol + field. + + This mapping is achieved through the use of one or more encoding + methods, which are simply functions applied to compress or decompress + a field. An encoding method is in turn defined using a name, a set + of function parameters, and a formal expression (i.e., using the + ROHC-FN [6]) or a textual description (i.e., a la RFC 3095 [2]) 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. + + + + + + +Pelletier Standards Track [Page 18] + +RFC 4164 Context Replication for ROHC Profiles August 2005 + + + 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 [6] in a manner that makes both profiles compatible. The set + of profiles negotiated for the channel (see also RFC 3095 [2]) can + then be used to determine if a context for a specific profile can be + used as a base context. + +B.2. Compatibility between Different Profiles (Informative) + + Compatibility between profiles, when replicating a field for a + particular protocol stack, can be expressed as follow: a field that + is compressed by different profiles is compatible for inter-profile + replication if it is defined in the set of packet formats using the + same mapping function between its uncompressed and compressed + version. + + For example, the IP Destination Address field which, based on the + packet formats and compression strategies defined in RFC 3095 [2], is + implicitly compressed using an encoding method equivalent to the + static() method defined in ROHC-FN [6]. + + In particular, for profiles that define their packet formats using a + formal notation such as ROHC-FN [6], 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. + + + + + + + +Pelletier Standards Track [Page 19] + +RFC 4164 Context Replication for ROHC Profiles August 2005 + + +Author's Address + + Ghyslain Pelletier + Box 920 + Ericsson AB + SE-971 28 Lulea, Sweden + + Phone: +46 8 404 29 43 + Fax: +46 920 996 21 + EMail: ghyslain.pelletier@ericsson.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Pelletier Standards Track [Page 20] + +RFC 4164 Context Replication for ROHC Profiles August 2005 + + +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- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Pelletier Standards Track [Page 21] + -- cgit v1.2.3