Network Working Group                    Ghyslain Pelletier, Ericsson AB
INTERNET-DRAFT
Expires: October 2004                                   April 2, 2004


                    RObust Header Compression (ROHC):
                  Context Replication for ROHC Profiles
               <draft-ietf-rohc-context-replication-02.txt>


Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/lid-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Abstract

   This document defines context replication, a complement to the
   context initialization procedure found in ROHC (Robust Header
   Compression) [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, and may be especially useful for the
   compression of multiple short-lived flows that may be occurring
   simultaneously or near-simultaneously, such as for example short-
   lived TCP flows.









Pelletier                                                       [Page 1]


INTERNET-DRAFT   Context Replication for ROHC profiles    April 2, 2004



Table of contents

   1.  Introduction....................................................3

   2.  Terminology.....................................................4

   3.  Context replication for ROHC profiles...........................4

       3.1.  Robustness considerations.................................5
       3.2.  Operational assumptions...................................5
       3.3.  Compressor states and logic...............................5
       3.3.1.  Context Replication (CR) state..........................6
       3.3.2.  State machine with context replication..................6
       3.3.3.  State transition logic..................................7
       3.3.3.1.  Selection of the base context, upward transition......7
       3.3.3.2.  Optimistic approach, upward transition................8
       3.3.3.3.  Optional acknowledgements (ACKs), upward transition...8
       3.3.3.4.  Negative ACKs (NACKs), downward transition............8
       3.4.  Decompressor logic........................................9
       3.4.1.  Replication and context initialization..................9
       3.4.2.  Reconstruction and verification.........................9
       3.4.3.  Actions upon failure....................................9
       3.5.  Packet formats...........................................10
       3.5.1.  Checksums in the IR-CR packet..........................10
       3.5.1.1.  7-bit CRC............................................11
       3.5.1.2.  8-bit CRC............................................11
       3.5.2.  General format of the IR-CR packet.....................12
       3.5.3.  Properties of the Base Context Identifier (BCID).......13
       3.6.  Inter-profile context replication........................13
       3.6.1.  Supporting inter-profile context replication...........14
       3.6.2.  Compatibility between profiles.........................15

   4.  Security considerations........................................15

   5.  Acknowledgements...............................................15

   6.  References.....................................................16

       6.1.  Normative references.....................................16
       6.2.  Informative references...................................16

   7.  Author's address...............................................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

   Full Copyright Statement...........................................18




Pelletier                                                       [Page 2]


INTERNET-DRAFT   Context Replication for ROHC profiles    April 2, 2004


1.  Introduction

   There is often some redundancy between header fields of different
   flows passing through the same compressor-decompressor pair. This
   means that some of the information needed to initialize the context
   for compressing 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.

   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. Such flows may lead to lower header
   compression gains, as each new packet stream requires most of the
   header information to be sent initially and smaller compressed
   headers may only be sent thereafter.

   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 IR packet specially 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. In addition, this mechanism
   allows contexts from different profiles to be used with context
   replication, where for obvious reasons only header fields common to
   both profiles can possibly be replicated.

   Context replication is herein defined as a general ROHC mechanism;
   its support may be defined for any ROHC profile. However, although
   the benefits of context replication are not limited to any particular
   protocol, it is best motivated for TCP compression. Specifically,
   many TCP transfers are short-lived; a behavior analysis of TCP/IP
   header fields among multiple short-lived connections may be found in
   [TCP-BEH]. In addition, [TCP-REQ] introduces considerations and
   requirements for the ROHC-TCP profile [ROHC-TCP] to efficiently
   compress such short-lived TCP transfers.

   For profiles supporting this mechanism, context replication is
   performed by the compressor first initializing a new context for the
   new flow. This context is then populated using parts of an existing
   context, i.e. a base context, to create the replicated context. The
   compressor then sends to the decompressor a packet that contains a
   reference to the selected base context, along with some data for the
   fields that need to be updated when creating the replicated context.
   Finally, the decompressor creates the replicated context based on the
   reference to the base context along with the uncompressed and
   compressed data from the received packet.

   This document specifies the context replication procedure for ROHC
   profiles. It defines the general compressor and decompressor logic



Pelletier                                                       [Page 3]


INTERNET-DRAFT   Context Replication for ROHC profiles    April 2, 2004


   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 of this packet.

   The fundamentals of the ROHC framework may be found in [RFC-3095].
   These are assumed to be understood throughout this document.


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 RFC2119.

   This document reuses some of the terminology found in [RFC-3095]. 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. A base context can be used by the
     compressor 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, where information needed for context replication can
     be extracted from.

   Context replication

     Context replication is the mechanism that initializes a new context
     based on another already existing context (a base context).


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 [RFC-
   3095]. 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.







Pelletier                                                       [Page 4]


INTERNET-DRAFT   Context Replication for ROHC profiles    April 2, 2004


3.1.  Robustness considerations

   Context replication deviates from the initialization procedure
   defined in [RFC-3095] by its capacity to achieve a certain level of
   compression already from the first packet used to initialize the
   context for a new flow. It is therefore 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. The most
   reliable way to select the base context is thus 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.  Operational assumptions

   Modes of operation are profile specific [RFC-3095]. A profile
   supporting context replication and defining modes other than
   unidirectional (U-mode) or bi-directional optimistic (O-mode) modes
   of operation cannot replicate a context when:

     - a mode other than U- or O-mode is active at replication time or;
     - a mode transition is taking place

   unless proper logic to address the above cases is specified
   explicitly as part of that profile.

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
   information has been received by the decompressor.





Pelletier                                                       [Page 5]


INTERNET-DRAFT   Context Replication for ROHC profiles    April 2, 2004


   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), that can be used to
   initialize a new context. Consequently, the Context Replication (CR)
   state is introduced to the compressor state machine to achieve
   compression from the very first packet being sent.

   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 replace 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. Header
   information pertaining to fields that are being replicated is
   therefore not sent.

   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 start in the lower compression state (IR), and
   transit 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 [ROHC-TCP]) 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 |
        +---<-----<-----<----+



Pelletier                                                       [Page 6]


INTERNET-DRAFT   Context Replication for ROHC profiles    April 2, 2004


   Note that context replication is a complement to the normal
   initialization procedure for ROHC profiles supporting it. The
   compressor transition to the CR state is therefore an optional
   addition to the state machine, and this 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

   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.

   [RFC-3095, section 5.2.2.] specifies the required format for the
   feedback field within the general ROHC packet format to be used by
   all profiles; 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 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. Note
   however that this cannot provide the guarantee that the selected base
   context has not been corrupted after it has been acknowledged or that
   it is still part of the state managed by the decompressor when the
   IR-CR will be received.

   More specifically, [RFC-3095] defines the context identifier (CID) as
   a reference to the state information (i.e. the context) used for
   compression and decompression. Multiple packet streams - each having



Pelletier                                                       [Page 7]


INTERNET-DRAFT   Context Replication for ROHC profiles    April 2, 2004


   their own context - may thus share a channel, and the CID space along
   with its representation within packet formats may be negotiated as
   part of the channel state. However, because [RFC-3095] does not
   explicitly define context state management between compressor and
   decompressor, and in particular for connection-oriented flows (e.g.
   TCP), only a high degree of confidence can be achieved when selecting
   a base context.

   In the case where feedback is not used by the decompressor, the
   compressor may have to periodically transit back to the IR state. In
   such 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 whether an existing context is a suitable base context
   for replication for a new flow are left to implementations. For
   simplicity, contexts with the same Source-IP and/or Destination-IP
   may be considered as replicable contexts, and the most recent one
   should be selected as the candidate to be replicated.

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 a valid
   context could not be initialized by the decompressor during context
   replication, and the corresponding context has been invalidated.

   Upon reception of a STATIC-NACK, the compressor MUST transit back to
   its initial no context state and SHOULD refrain from sending IR-CR
   packets using the same base context. The compressor SHOULD re-
   initialize the decompressor context using an IR packet.



Pelletier                                                       [Page 8]


INTERNET-DRAFT   Context Replication for ROHC profiles    April 2, 2004


   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, and 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 (RFC-3095, 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 update the context with the information received in
   the current header. The decompressor SHOULD send an ACK when it
   succeeds to validate 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
   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.

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 [RFC-3095].

   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



Pelletier                                                       [Page 9]


INTERNET-DRAFT   Context Replication for ROHC profiles    April 2, 2004


   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 maintains
   a specific CID as a potential candidate for a later replication
   attempt, while there actually 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.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 CID different than the Base CID for
      the replicated context;
   b) it must be possible to replicate from a base context using a
      profile different than the one associated with the replicated
      context, for fields common to both profiles;
   c) it must be possible to selectively include or exclude from the
      packet format some fields that may be replicable;
   d) 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;
   e) it must be possible for the decompressor to verify the success of
      the replication procedure;
   f) it is anticipated that profiles other than [ROHC-TCP] will also
      define support for context replication, therefore it is desirable
      that the packet format be as profile independent as possible.

3.5.1.  CRCs in the IR-CR packet

   The IR packet, as defined in [RFC-3095], 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 initialize 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



Pelletier                                                      [Page 10]


INTERNET-DRAFT   Context Replication for ROHC profiles    April 2, 2004


   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 [RFC-
   3095, section 5.2.6.]), profiles may not redefine this CRC beyond the
   extent of its coverage.

   [RFC-3095] also defines a 3-bit CRC and a 7-bit CRC for compressed
   headers, used to verify proper decompression and validate the
   context. This type of CRC is calculated over the original
   uncompressed header, as it is not sufficient to only protect the
   compressed data being exchanged between compressor and decompressor
   to ensure a robust reconstruction of the original header.

   There is thus a clear distinction in purposes 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.

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 [RFC-3095, section 5.9.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 [RFC-3095, section
   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



Pelletier                                                      [Page 11]


INTERNET-DRAFT   Context Replication for ROHC profiles    April 2, 2004


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 [RFC-3095], support for replication can be added using the profile
   specific part of the IR packet. Note that there is one bit, (x), left
   in the IR header for "Profile specific information". The definition
   of this bit is profile-specific. Thus, profiles supporting context
   replication may use this bit as a flag indicating whether the packet
   is an IR packet or an IR-CR packet. Note also that profiles may
   define an alternative method to identify the IR-CR packet within the
   profile specific information, instead of using this bit.

   The IR-CR header associates a CID with a profile, and initializes the
   context using the context replication mechanism. It is not
   recommended to use this packet to repair a damaged context.

   The IR-CR has the following general format:

     0   1   2   3   4   5   6   7
    --- --- --- --- --- --- --- ---
   :         Add-CID octet         : if for small CIDs and (CID != 0)
   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   1   1   0   x | IR type octet
   +---+---+---+---+---+---+---+---+
   :                               :
   /      0-2 octets of CID        / 1-2 octets if for large CIDs
   :                               :
   +---+---+---+---+---+---+---+---+
   |            Profile            | 1 octet
   +---+---+---+---+---+---+---+---+
   |              CRC              | 1 octet
   +---+---+---+---+---+---+---+---+
   |                               |
   / Profile specific information  / variable length
   |                               |
    - - - - - - - - - - - - - - - -
   |                               |
   /           Payload             / variable length
   |                               |
    - - - - - - - - - - - - - - - -

     x:  Profile specific information.  Interpreted according to the
         profile indicated in the Profile field.

     Profile:  The profile to be associated with the CID.  In the
         IR-CR packet, the profile identifier is abbreviated to the



Pelletier                                                      [Page 12]


INTERNET-DRAFT   Context Replication for ROHC profiles    April 2, 2004


         8 least significant bits.  It selects the highest-number
         profile in the channel state parameter PROFILES that matches
         the 8 LSBs given (see also [RFC-3095]).

     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.

     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 to 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, the BCID with a value from 0 to 15
   is minimally represented by a four-bit field within the packet format
   of the IR-CR. In particular, the four bits of Add-CID used with small
   CIDs [RFC-3095] are not needed for the BCID, as this information is
   already provided from the CID of the IR-CR packet itself. When large
   CIDs are used, the BCID is represented in the IR-CR with one or two
   octets, and it is coded in the same way as a large CID [RFC-3095].


3.6.  Inter-profile context replication

   <# Editor's Note:                                              #>
   <#    Open issue: How important is it to support Inter-profile #>
   <#                context replication? Should this section be  #>
   <#                modified or removed?                         #>

   Inter-profile context replication requires that the decompressor has
   access to data structures from the base context, which belongs to a
   profile different than the profile using replication. This
   information must be available in a format consistent with the data
   structures and encoding method(s) in use for all fields being
   replicated.









Pelletier                                                      [Page 13]


INTERNET-DRAFT   Context Replication for ROHC profiles    April 2, 2004


3.6.1.  Supporting inter-profile context replication

   A ROHC profile describes how to compress a specific protocol stack,
   and include 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. The packet formats thus 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. with [ROHC-FN]) or
   a textual description (i.e. a la [RFC-3095]) of its behaviour.

   To compress one or more fields of a specific protocol stack,
   different profiles may define their packet formats using different
   encoding methods, or using a variant of a similar technique. A
   typical example of the latter is list compression, such as used for
   IP extension headers. This implies that context entries for a field
   belonging to a specific protocol stack may differ in their content,
   representation and structure from one profile to another.

   As a consequence of the above, a profile supporting 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
   using a meaningful representation during replication. Specifically,
   inter-profile context replication mandates that decompressor
   implementations (including existing ones) of other profiles be
   updated when adding support for a profile using context replication.
   Inter-profile context replication can therefore not be seen as being
   only a specific implementation issue.

   The compressor must know if the decompressor supports inter-profile
   context replication before initiating it. The compressor must also
   know which contexts belonging to what profile may be used as a base
   context. Therefore, a compressor MUST NOT initiate context
   replication using a base context belonging to a different profile,
   unless this profile explicitly provides the proper mapping for its
   context entries or unless this profile is defined formally using
   [ROHC-FN]. Profiles allowing the usage of the context as a base
   context can then be known by the compressor from the set of profiles
   negotiated for that channel (see also [RFC-3095]).










Pelletier                                                      [Page 14]


INTERNET-DRAFT   Context Replication for ROHC profiles    April 2, 2004


3.6.2.  Compatibility between different profiles

   Inter-profile compatibility when replicating a field for a particular
   protocol stack is thus herein defined as a field 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], is
   implicitly compressed using an encoding method equivalent to the
   static() method defined in [ROHC-FN]. In particular, for profiles
   defining their packet formats using the formal notation [ROHC-FN],
   two different encoding methods may not have the same name. A field
   from a protocol stack is thus said to be compatible for replication
   between two different profiles if it has an equivalent definition
   within the packet formats.


4.  Security considerations

   This document does not bring any new additional security
   considerations than those already listed in [ROHC-TCP].


5.  Acknowledgements

   The author would like to thank Lars-Erik Jonsson, Richard Price, Mark
   West, Kristofer Sandlund, Fredrik Lindstroem and HongBin Liao for
   valuable input to this document.



























Pelletier                                                      [Page 15]


INTERNET-DRAFT   Context Replication for ROHC profiles    April 2, 2004


6.  References

6.1.  Normative references

   [RFC-3095]  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

   [ROHC-TCP]  Pelletier, G., Jonsson, L-E., West, M., Price, R.,
               "RObust Header Compression (ROHC): TCP/IP Profile (ROHC-
               TCP)", Internet Draft (work in progress), <draft-ietf-
               rohc-tcp-06.txt>, April 2004.

   [TCP-REQ]   Jonsson, L-E., "Requirements on ROHC IP/TCP header
               compression", Internet Draft (work in progress),
               <draft-ietf-rohc-tcp-requirements-05.txt>, October 2002.

   [TCP-BEH]   West, M. and S. McCann, "TCP/IP Field Behavior", Internet
               Draft (work in progress), <draft-ietf-rohc-tcp-field-
               behavior-02.txt>, March 2003.

   [RFC-2026]  Bradner, S., "The Internet Standards Process", RFC 2026,
               October 1996.

   [ROHC-FN]   "Formal Notation for Robust Header Compression
               (ROHC-FN)", R. Price et al., <draft-ietf-rohc-formal-
               notation-02.txt> (work in progress), October 2003


7.  Author's address

   Ghyslain Pelletier
   Box 920
   Ericsson AB
   SE-971 28 Lulea, Sweden

   Phone: +46 920 20 24 32
   Fax:   +46 920 20 20 99
   Email: ghyslain.pelletier@ericsson.com










Pelletier                                                      [Page 16]


INTERNET-DRAFT   Context Replication for ROHC profiles    April 2, 2004


Appendix A.  General format of the IR-CR packet (informative)

Appendix 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]).

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

   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.



Pelletier                                                      [Page 17]


INTERNET-DRAFT   Context Replication for ROHC profiles    April 2, 2004


Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.























   This Internet-Draft expires October 2, 2004.



Pelletier                                                      [Page 18]