doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

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]
+