[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                       Ghyslain Pelletier, Ericsson
INTERNET-DRAFT
Expires: November 2003                                      May 23, 2002


                    RObust Header Compression (ROHC):
                  Context Replication for ROHC Profiles
            <draft-pelletier-rohc-context-replication-00.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, an alternative 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      May 23 2002



Table of contents

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

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

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

       3.1.  Robustness considerations.................................4
       3.2.  Compressor logic..........................................5
       3.2.1.  Selection of the Base Context...........................5
       3.2.2.  Feedback logic..........................................6
       3.2.2.1.  Negative Acknowledgements (NACKs).....................6
       3.2.2.2.  Optional Acknowledgements (ACKs)......................7
       3.3.  Decompressor logic........................................7
       3.3.1.  Replication and context initialization..................7
       3.3.2.  Actions upon failure....................................7
       3.4.  Packet Formats............................................8
       3.4.1.  Checksums in the IR-REPLICATE packet....................8
       3.4.1.1.  7-bit CRC.............................................9
       3.4.1.2.  8-bit CRC.............................................9
       3.4.2.  General Format of the IR-REPLICATE packet...............9

   4.  Security considerations........................................11

   5.  Acknowledgements...............................................11

   6.  References.....................................................11

       6.1.  Normative References.....................................11
       6.2.  Informative References...................................12

   7.  Author's address...............................................12

   Appendix A.  Replication chains....................................13

       A.1.  Replication of the IPv6 Header [RFC-2460]................13
       A.2.  Replication of the IPv4 Header [RFC-791].................14
       A.3.  Replication of the UDP Header [RFC-768]..................16
       A.4.  Replication of the UDP-Lite Header [UDP-Lite]............17
       A.5.  Replication of the TCP Header [RFC-793]..................18












Pelletier                                                       [Page 2]


INTERNET-DRAFT   Context Replication for ROHC profiles      May 23 2002


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)
   occurs 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 the entire
   headers 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      May 23 2002


   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 general header compression 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

     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]. This section describes the compressor and decompressor logic
   as well as the IR packet format used with context replication.


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



Pelletier                                                       [Page 4]


INTERNET-DRAFT   Context Replication for ROHC profiles      May 23 2002


   the context replication procedure be reliable. 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 a
   base context corresponding to the one selected for replication is
   available at the decompressor before initiating the replication
   procedure. The most reliable way to select the base context is thus
   to choose a context that has previously been acknowledged by the
   decompressor.

   In addition, the presence of a CRC covering the information used to
   initialize 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.  Compressor logic

   For profiles defining support for context replication, the compressor
   may replace any IR/IR-DYN packets during the context establishment
   procedure (i.e. in IR state) with the IR-REPLICATE packet, if an
   already existing context can be selected as a base context for
   replication.

3.2.1.  Selection of a Base Context

   When initiating context replication, the compressor MUST select a
   context that has previously been acknowledged by the decompressor as
   the base context, and this 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
   context is still part of the state managed by the decompressor when
   the IR-REPLICATE 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 with different
   contexts 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.



Pelletier                                                       [Page 5]


INTERNET-DRAFT   Context Replication for ROHC profiles      May 23 2002



   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.

   Finally, the Base CID within the packet format of the IR-REPLICATE
   may be assigned a different value than the context identifier
   associated to the new flow (i.e. Base CID != CID); otherwise the base
   context is overwritten with the new context by the replication
   process.

3.2.2.  Feedback logic

   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.

   [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.2.2.1.  Negative Acknowledgements (NACKs)

   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-
   REPLICATE packets using the same base context. 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, and take actions accordingly.






Pelletier                                                       [Page 6]


INTERNET-DRAFT   Context Replication for ROHC profiles      May 23 2002


3.2.2.2.  Optional Acknowledgements (ACKs)

   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.  Decompressor logic

3.3.1.  Replication and context initialization

   Upon reception of an IR-REPLICATE packet, the decompressor first
   determines its content (RFC-3095, section 5.2.6). The profile
   indicated in the IR-REPLICATE 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-REPLICATE 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.

   The decompressor then creates a new context using the information
   present in the IR-REPLICATE packet together with the identified base
   context, and decompresses the original header. The decompressor
   validates the resulting header using the CRC calculated over the
   original uncompressed header; if the decompessor fails to validate
   the header, the actions specified in section 3.3.2 must be taken.

3.3.2.  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-REPLICATE
   packets, it MUST invalidate the context and remain in its initial
   state. In addition, the decompressor SHOULD send a STATIC-NACK.

   If the context has been successfully validated from the decompression
   of one or more initial IR-REPLICATE packets, the decompressor SHOULD
   send a NACK when it fails to verify the context following the
   decompression of one or more subsequent IR-REPLICATE packets.

   The decompressor SHOULD send an ACK when it succeeds to validate the
   context as a result of the decompression of one or more IR-REPLICATE
   packets.



Pelletier                                                       [Page 7]


INTERNET-DRAFT   Context Replication for ROHC profiles      May 23 2002


3.4.  Packet Formats

   The format of the IR-REPLICATE 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 specifically 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.4.1.  CRCs in the IR-REPLICATE 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. The static and dynamic chains of IR packets contains 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
   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.




Pelletier                                                       [Page 8]


INTERNET-DRAFT   Context Replication for ROHC profiles      May 23 2002


   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-REPLICATE 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-REPLICATE packet. This is necessary to allow a
   decompressor to verify that the replication process has succeeded.

3.4.1.1.  7-bit CRC

   The 7-bit CRC in the IR-REPLICATE 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-REPLICATE is:

      C(x) = 1 + x + x^2 + x^3 + x^6 + x^7

3.4.1.2.  8-bit CRC

   The coverage of the 8-bit CRC in the IR-REPLICATE packet is profile-
   dependent, but it MUST cover at least the initial part of the packet
   ending with the Profile field and if present, the Base CID field. For
   profiles that define the usage of the Base CID within the packet
   format of the IR-REPLICATE as optional, the CRC MUST also cover the
   information used to indicate the presence of this field within the
   packet. Any other information which initializes the context of the
   decompressor should also be protected by the CRC.

   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-REPLICATE is:

      C(x) = 1 + x + x^2 + x^8

3.4.2.  General Format of the IR-REPLICATE packet

   The context replication mechanism requires a dedicated IR packet
   format that uniquely identifies the IR-REPLICATE 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



Pelletier                                                       [Page 9]


INTERNET-DRAFT   Context Replication for ROHC profiles      May 23 2002


   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-REPLICATE packet. Note also that profiles
   may define an alternative method to identify the IR-REPLICATE packet
   within the profile specific information, instead of using this bit.

   The IR-REPLICATE 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-REPLICATE 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
   |                               |
   +---+---+---+---+---+---+---+---+
   |                               |
   |   Static replication chain    / variable length
   |                               |
   +---+---+---+---+---+---+---+---+
   |                               |
   /  Dynamic replication chain    / 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-
         REPLICATE packet, the profile identifier is abbreviated to the
         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]).



Pelletier                                                      [Page 10]


INTERNET-DRAFT   Context Replication for ROHC profiles      May 23 2002


     CRC:  8-bit CRC computed using the polynomial of section 3.4.1.2.

     Profile specific information:  The contents of this part of the IR-
         REPLICATE 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.

     Static replication chain:  A chain of static subheader information
         used for replication.

     Dynamic replication chain:  A chain of dynamic subheader
         information used for replication.  What dynamic information is
         present is inferred from the static replication chain.

     Payload:  The payload of the corresponding original packet, if any.
         The presence of a payload is inferred from the packet length.


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 and HongBin Liao for valuable input to this document.


6.  References

6.1.  Normative References

   [RFC-768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
               August 1980.

   [RFC-791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
               September 1981.

   [RFC-793]   Postel, J., "Transmission Control Protocol," RFC 793
               (STD7), September 1981.

   [RFC-2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
               (IPv6) Specification", RFC 2460, December 1998.

   [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,



Pelletier                                                      [Page 11]


INTERNET-DRAFT   Context Replication for ROHC profiles      May 23 2002


               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.

   [UDP-Lite]  Larzon, L., Degermark, M., Pink, S., Jonsson, L.,
               Fairhurst, G., "The UDP-Lite Protocol", Internet draft
               (work in progress), December 2002, <draft-ietf-tsvwg-
               udp-lite-01.txt>

   6.2.  Informative References

   [ROHC-TCP]  Pelletier, G., Zhang, Q., Jonsson, L-E., Liao, H., West,
               M., "RObust Header Compression (ROHC): TCP/IP Profile
               (ROHC-TCP)", Internet Draft (work in progress), <draft-
               ietf-rohc-tcp-04.txt>, May 2003.

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


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@epl.ericsson.se
















Pelletier                                                      [Page 12]


INTERNET-DRAFT   Context Replication for ROHC profiles      May 23 2002


Appendix A.  Replication chains

   This section provides examples of static and dynamic replication
   chains for IPv6, IPv4, UDP, UDP-Lite and TCP.

A.1.  Replication of the IPv6 Header [RFC-2460]

   Static part:

      +---+---+---+---+---+---+---+---+
      | F | N | S | D |Flow Label(msb)|
      +---+---+---+---+---+---+---+---+
      /        Flow Label (lsb)       /   2 octets, if F = 1
      +---+---+---+---+---+---+---+---+
      |          Next Header          |   1 octet, if N = 1
      +---+---+---+---+---+---+---+---+
      /        Source Address         /   16 octets, if S = 1
      +---+---+---+---+---+---+---+---+
      /      Destination Address      /   16 octets, if D = 1
      +---+---+---+---+---+---+---+---+

   Dynamic part:

      +---+---+---+---+---+---+---+---+
      |         Traffic Class         |   1 octet
      +---+---+---+---+---+---+---+---+
      |           Hop Limit           |   1 octet
      +---+---+---+---+---+---+---+---+
      / Generic extension header list /   variable length
      +---+---+---+---+---+---+---+---+

   Eliminated:

      Payload Length
      Version

   Replicable:

      Flow Label            (Flow Label must be all '0's)

         Flow Label must not be used, i.e. this field must be all '0's.
         Note that the Flow Label(msb) field is valid only if F = 1.

      Next Header

         The type of the following header in the static replication
         chain must be the same type as the one found in the static
         chain of the base context.

      Source Address
      Destination Address



Pelletier                                                      [Page 13]


INTERNET-DRAFT   Context Replication for ROHC profiles      May 23 2002


   Extras:

      F, N, S and D: replication flags.
      Generic extension header list: see [RFC-3095, section 5.7.7.3].

   CRC-DYNAMIC: Payload Length field (octets 5-6).

   CRC-STATIC: All other fields (octets 1-4, 7-40).

   CRC coverage for extension headers is defined in [RFC-3095, section
   5.8.7].

   Note: The Next Header field indicates the type of the following
   header in the static chain, rather than being a copy of the Next
   Header field of the original IPv6 header.  See also [RFC-30905,
   section 5.7.7.8].

   Note: When using context replication from a base context where the
   static part contains multiple IP levels for a flow with a different
   number of IP levels, only the outer IP header can be replicated.


A.2.  Replication of the IPv4 Header [RFC-791]

   Static part:

      +---+---+---+---+---+---+---+---+
      | P | S | D | DF|RND|NBO|   0   |
      +---+---+---+---+---+---+---+---+
      |           Protocol            |   1 octets, if P = 1
      +---+---+---+---+---+---+---+---+
      /        Source Address         /   4 octets, if S = 1
      +---+---+---+---+---+---+---+---+
      /      Destination Address      /   4 octets, if D = 1
      +---+---+---+---+---+---+---+---+

   Dynamic part:

      +---+---+---+---+---+---+---+---+
      |        Type of Service        |
      +---+---+---+---+---+---+---+---+
      |         Time to Live          |
      +---+---+---+---+---+---+---+---+
      /        Identification         /   2 octets
      +---+---+---+---+---+---+---+---+
      / Generic extension header list /   variable length
      +---+---+---+---+---+---+---+---+

   Eliminated:

      IHL, Total Length, MF flag, Fragment Offset, Header Checksum,



Pelletier                                                      [Page 14]


INTERNET-DRAFT   Context Replication for ROHC profiles      May 23 2002


      Options, Padding and Version. See also [RFC-3095, section
      5.7.7.4].

   Replicable:

      Protocol

         The type of the following header in the static replication
         chain must be the same type as the one found in the static
         chain of the base context.

      Source Address
      Destination Address

   Extras:

      P, S and D: replication flags.
      RND, NBO. See [RFC-3095, section 5.7].

   CRC-DYNAMIC: Total Length, Identification, Header Checksum
                (octets 3-4, 5-6, 11-12).

   CRC-STATIC: All other fields (octets 1-2, 7-10, 13-20)

   CRC coverage for extension headers is defined in [ROHC, section
   5.8.7].

   Note: The Protocol field indicates the type of the following header
   in the static chain, rather than being a copy of the Protocol field
   of the original IPv4 header.  See also [RFC-3095, section 5.7.7.8].

   Note: When using context replication from a base context where the
   static part contains multiple IP levels for a flow with a different
   number of IP levels, only the outer IP header can be replicated.




















Pelletier                                                      [Page 15]


INTERNET-DRAFT   Context Replication for ROHC profiles      May 23 2002


A.3.  Replication of the UDP Header [RFC-768]

   <# Author's    Is it possible to identify a useful scenario where  #>
   <# note   :    replication of the UDP part of a context is         #>
   <#             desirable? It is not clear how much value there is  #>
   <#             the UDP header. For UDP, the static and dynamic     #>
   <#             chains found in [RFC-3095] could be used.           #>

   Static part:

      +---+---+---+---+---+---+---+---+
      | S | SC| D | DC| C |     0     |
      +---+---+---+---+---+---+---+---+
      :                               :   Present  if  S = 1 and
      /          Source Port          /   1 octet  if SC = 1
      :                               :   2 octets if SC = 0
      +---+---+---+---+---+---+---+---+
      :                               :   Present  if  D = 1 and
      /       Destination Port        /   1 octet  if DC = 1
      :                               :   2 octets if DC = 0
      +---+---+---+---+---+---+---+---+

   Dynamic part:

      +---+---+---+---+---+---+---+---+
      /           Checksum            /   2 octets, present if C = 1
      +---+---+---+---+---+---+---+---+

   Eliminated:

      Length

      The Length field of the UDP header MUST match the Length field(s)
      of the preceding subheaders, i.e., there must not be any padding
      after the UDP payload that is covered by the IP Length.

   Replicable:

      Source Port
      Destination Port
      Checksum

   Extras:

      S, SC, D, DC, C: replication flags.

   CRC-DYNAMIC: Length field, Checksum (octets 5-8).

   CRC-STATIC: All other fields (octets 1-4).





Pelletier                                                      [Page 16]


INTERNET-DRAFT   Context Replication for ROHC profiles      May 23 2002


A.4.  Replication of the UDP-Lite Header [UDP-Lite]

   <# Author's    Is it possible to identify a useful scenario where  #>
   <# note   :    replication of the UDP-Lite part of a context is    #>
   <#             desirable? It is not clear how much value there     #>
   <#             is to replicate parts of the UDP-Lite header. For   #>
   <#             UDP-Lite, the static and dynamic chains defined in  #>
   <#             the UDP-Lite profile could be used.                 #>

   Static part:

      +---+---+---+---+---+---+---+---+
      | S | SC| D | DC| C | CC|   0   |
      +---+---+---+---+---+---+---+---+
      :                               :   Present  if  S = 1 and
      /          Source Port          /   1 octet  if SC = 1
      :                               :   2 octets if SC = 0
      +---+---+---+---+---+---+---+---+
      :                               :   Present  if  D = 1 and
      /       Destination Port        /   1 octet  if DC = 1
      :                               :   2 octets if DC = 0
      +---+---+---+---+---+---+---+---+

   Dynamic part:

      +---+---+---+---+---+---+---+---+
      :                               :   Present  if  C = 1 and
      /       Checksum Coverage       /   1 octet  if CC = 1
      :                               :   2 octets if CC = 0
      +---+---+---+---+---+---+---+---+
      /           Checksum            /   2 octets
      +---+---+---+---+---+---+---+---+

   Replicable:

      Source Port
      Destination Port
      Checksum Coverage
      Checksum

   Extras:

      S, SC, D, DC, C, CC: replication flags.

   CRC-DYNAMIC: Checksum Coverage field, Checksum field (octets 5-8).

   CRC-STATIC: All other fields (octets 1-4).







Pelletier                                                      [Page 17]


INTERNET-DRAFT   Context Replication for ROHC profiles      May 23 2002


A.5.  Replication of the TCP Header [RFC-793]

   Static part:

      +---+---+---+---+---+---+---+---+
      | S | SC| D | DC| W | U | M | 0 |
      +---+---+---+---+---+---+---+---+
      :                               :   Present, if  S = 1 and
      /          Source Port          /   1 octet, if SC = 1
      :                               :   2 octets, if SC = 0
      +---+---+---+---+---+---+---+---+
      :                               :   Present, if  D = 1 and
      /       Destination Port        /   1 octet, if DC = 1
      :                               :   2 octets, if DC = 0
      +---+---+---+---+---+---+---+---+

   Dynamic part:

      +---+---+---+---+---+---+---+---+
      /    Master Sequence Number     /   2 octets, if M = 1
      +---+---+---+---+---+---+---+---+
      /       Sequence Number         /   4 octets
      +---+---+---+---+---+---+---+---+
      /    Acknowledgement Number     /   4 octets
      +---+---+---+---+---+---+---+---+
      | Data Offset   |   Reserved    |   1 octet
      +---+---+---+---+---+---+---+---+
      |CWR|ECE|URG|ACK|PSH|RST|SYN|FIN|   1 octet
      +---+---+---+---+---+---+---+---+
      /            Window             /   2 octets, present if W = 1
      +---+---+---+---+---+---+---+---+
      /           Checksum            /   2 octets
      +---+---+---+---+---+---+---+---+
      /        Urgent Pointer         /   2 octets, present if U = 1
      +---+---+---+---+---+---+---+---+
      /           Options             /   variable length
      +---+---+---+---+---+---+---+---+

   Eliminated:

      Nothing.

   Extras:

      S, SC, D, DC, W, U, M: replication flags.

   Replicable:

      Source Port
      Destination Port
      Master Sequence Number



Pelletier                                                      [Page 18]


INTERNET-DRAFT   Context Replication for ROHC profiles      May 23 2002


     Window
     Urgent Pointer

   CRC-DYNAMIC: Length field, Checksum (octets 5-8).

   CRC-STATIC: All other fields (octets 1-4).

   Note: This chain is always the last chain in the IR-Replicate packet.




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 November 23, 2003.





Pelletier                                                      [Page 19]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/