[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-jonsson-rohc-rfc3095bis-framework) 00 01 02 03 04 RFC 4995

Network Working Group                                       L-E. Jonsson
INTERNET-DRAFT                                              G. Pelletier
Expires: December 2006                                       K. Sandlund
                                                                Ericsson
                                                           June 26, 2005



               The RObust Header Compression (ROHC) Framework
                <draft-ietf-rohc-rfc3095bis-framework-01.txt>


Status of this memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   By submitting this Internet-Draft, each author accepts the provisions
   of Section 3 of BCP 78.

   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 to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

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

Abstract

   The RObust Header Compression (ROHC) protocol provides an efficient,
   flexible and future-proof header compression concept. It is designed
   to operate efficiently and robustly over various link technologies
   with different characteristics. RFC 3095 defined the ROHC framework
   along with an initial set of compression profiles.

   To improve and simplify the ROHC specifications, this document
   explicitly defines the ROHC framework separately, and thus replaces
   the framework specification of RFC 3095.





Jonsson, et al.                                                 [Page 1]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


Table of Contents

   1. Introduction.....................................................3
   2. Terminology......................................................4
      2.1. ROHC Terminology............................................4
      2.2. Acronyms....................................................6
   3. Background (Informative).........................................6
      3.1. Header Compression Fundamentals.............................6
      3.2. A Short History of Header Compression.......................7
   4. Overview of Robust Header compression (ROHC) (Informative).......8
      4.1. General Principles..........................................8
      4.2. Compression Efficiency, Robustness and Transparency.........9
      4.3. Developing the ROHC protocol................................9
      4.4. Operational Characteristics of the ROHC Channel............10
      4.5. Compression and Master Sequence Number (MSN)...............12
      4.6. Static and Dynamic parts of a Context......................12
   5. The ROHC Framework (Normative)..................................13
      5.1. The ROHC Channel...........................................13
         5.1.1. Contexts and Context Identifiers......................13
         5.1.2. Per-Channel Parameters................................14
      5.2. ROHC Packets and Packet Types..............................15
         5.2.1. General Format of ROHC Packets........................15
            5.2.1.1. Format of the Padding Octet......................16
            5.2.1.2. Format of the Add-CID octet......................16
            5.2.1.3. General Format of the Compressed Header Types....16
         5.2.2. Initialization and Refresh (IR) Packet Types..........17
            5.2.2.1. ROHC IR Packet Type..............................17
            5.2.2.2. ROHC IR-DYN Packet Type..........................18
            5.2.2.3. ROHC Initial Decompressor Processing.............19
         5.2.3. ROHC Feedback.........................................20
            5.2.3.1. ROHC Feedback Format.............................21
         5.2.4. ROHC segmentation.....................................22
            5.2.4.1. Segmentation Usage Considerations................23
            5.2.4.2. Segmentation Protocol............................23
      5.3. General encoding methods...................................24
         5.3.1. Header compression CRCs, coverage and polynomials.....24
            5.3.1.1. 8-bit CRCs in IR and IR-DYN headers..............24
            5.3.1.2. 3-bit CRC in Compressed Headers..................24
            5.3.1.3. 7-bit CRC in Compressed Headers..................25
         5.3.2. Self-describing variable-length values................25
      5.4. ROHC UNCOMPRESSED -- no compression  (Profile 0x0000)......26
         5.4.1. IR Packet.............................................27
         5.4.2. Normal Packet.........................................27
         5.4.3. Decompressor Operation................................28
         5.4.4. Feedback..............................................28
   6. Overview of a ROHC Profile (Informative)........................29
   7. Security Considerations.........................................30
   8. IANA Considerations.............................................30
   9. Acknowledgment..................................................31
   10. References.....................................................31
      10.1. Normative References......................................31



Jonsson, et. al                                                 [Page 2]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


      10.2. Informative References....................................31
   11. Authors' Addresses.............................................33

1. Introduction

   For many types of networks, reducing the deployment and operational
   costs by improving the usage of the bandwidth resources is of vital
   importance. Header compression over a link is possible because some
   of the information carried within the header of a packet becomes
   compressible between packets belonging to the same flow.

   For links where the overhead of the IP header(s) is problematic, the
   total size of the header may be significant. Applications carrying
   data carried within RTP [13] will then, in addition to link layer
   framing, have an IPv4 [10] header (20 octets), a UDP [12] header (8
   octets), and an RTP header (12 octets) for a total of 40 octets. With
   IPv6 [11], the IPv6 header is 40 octets for a total of 60 octets.
   Applications transferring data using TCP [14] will have 20 octets for
   the transport header, for a total size of 40 octets for IPv4 and 60
   octets for IPv6.

   The relative gain for specific flows (or applications) depends on the
   size of the payload used in each packet. For applications such as
   Voice-over-IP, where the size of the payload containing coded speech
   can be as small as 15-20 octets, this gain will be quite significant.
   Similarly, relative gains for TCP flows carrying large payloads (such
   as FTP transfers) will be less than for flows carrying smaller
   payloads (such as application signaling with e.g. SIP).

   As more and more wireless link technologies are being deployed to
   carry IP traffic, care must be taken to address the specific
   characteristics of these technologies within the header compression
   algorithms. Legacy header compression schemes, such as those defined
   in [16] and [17], have been shown to perform inadequately over links
   where both the lossy behavior and the round-trip times (RTT) are non-
   negligible, such as those observed for example in wireless links and
   IP tunnels.

   In addition, a header compression scheme must handle the often non-
   trivial residual errors, i.e. where the lower link may pass a packet
   that contains undetected bit errors to the decompressor. It must also
   handle loss and reordering before the compression point, as well as
   on the link between the compression and decompression points [7].

   The RObust Header Compression (ROHC) protocol is designed to address
   efficient compression over links showing problematic characteristics
   as explained above, and it is expected to perform very efficiently
   over any type of link technology. ROHC provides an efficient,
   flexible and future-proof header compression concept. It is designed
   to operate efficiently and robustly over various link technologies
   with different characteristics. In particular, from the robustness



Jonsson, et. al                                                 [Page 3]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


   characteristics built into the protocol itself, it is especially well
   suited for wireless links and tunnels.

   RFC 3095 defines the ROHC framework along with an initial set of
   compression profiles. To improve and simplify the specification, it
   has been agreed that the framework and the profiles parts of RFC 3095
   be split into separate documents.

   This document explicitly defines the ROHC framework, and thus
   replaces the framework specification of RFC 3095.

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

2.1. ROHC Terminology

   Context

      The context of the compressor is the state it uses to compress a
      header. The context of the decompressor is the state it uses to
      decompress a header. Either of these or the two in combination
      are usually referred to as "context", when it is clear which is
      intended. The context contains relevant information from previous
      headers in the packet flow, such as static fields and possible
      reference values for compression and decompression. Moreover,
      additional information describing the packet flow is also part
      of the context, for example information about how the IP
      Identifier field changes and the typical inter-packet increase in
      sequence numbers or timestamps.

   Context damage

      When the context of the decompressor is not consistent with the
      context of the compressor, decompression may fail to reproduce the
      original header. This situation can occur when the context of the
      decompressor has not been initialized properly or when packets
      have been lost or damaged between compressor and decompressor.

      Packets which cannot be decompressed due to inconsistent contexts
      are said to be lost due to context damage. Packets that are
      decompressed but contain errors due to inconsistent contexts are
      said to be damaged due to context damage.

   Context repair mechanism

      Context repair mechanisms are used to bring the contexts back in
      sync when they were not, an important task since context damage
      causes excessive loss propagation. Examples of such mechanisms are



Jonsson, et. al                                                 [Page 4]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


      the context request mechanism of CRTP, NACK-based mechanisms, and
      periodic refreshes used in unidirectional operation. Note that
      there are also mechanisms that can prevent context inconsistencies
      from occurring, for example repetitions of extra information after
      changes, and CRCs that protect context-updating information.

   Damage propagation

      Delivery of incorrect decompressed headers due to context damage,
      i.e. due to errors in (i.e., loss of or damage to) previous
      header(s) or feedback.

   Error detection

      Detection of errors by lower layers. If error detection is not
      perfect, there will be residual errors.

   Error propagation

      Damage propagation or loss propagation.

   Header compression profile

      A header compression profile is a compression algorithm, which
      Specifies how to compress specific header combination(s). A
      compression profile may be tailored to handle a specific set of
      link characteristics, e.g. loss characteristics, reordering
      between compression points, etc. Compression profiles provide the
      details of the header compression framework introduced in this
      document. The profile concept makes use of profile identifiers to
      separate the different profiles that are used over the same
      channel. These identifiers are each associated with one
      compression context when setting up the compression scheme.

   Link

       A physical transmission path that constitutes a single IP hop.

   Loss propagation

      Loss of headers, due to errors in (i.e., loss of or damage to)
      previous header(s)or feedback.

   Packet flow

      A sequence of packets where the field values and change patterns
      of field values are such that the headers can be compressed using
      the same context.






Jonsson, et. al                                                 [Page 5]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


   Residual error

      Error introduced during transmission and not detected by lower-
      layer error detection schemes.

   ROHC channel

       A logical unidirectional point-to-point channel carrying ROHC
       packets from the compressor to the decompressor, optionally
       carrying ROHC feedback information on the behalf of another
       compressor-decompressor pair operating on a separate ROHC channel
       in the opposite direction. See also [5].

   This document also makes use of the conceptual terminology defined by
   "ROHC Terminology and Channel Mapping Examples", RFC 3759 [5].

2.2. Acronyms

   This section lists most acronyms used for reference.

   CID    Context Identifier.
   CRC    Cyclic Redundancy Check, an error detection mechanism.
   IR     Initialization and Refresh.
   MRRU   Maximum Reconstructed Reception Unit.
   ROHC   RObust Header Compression.

3. Background (Informative)

   This chapter provides a background to the subject of header
   compression. The fundamental ideas are described together with a
   discussion about the history of header compression schemes. The
   motivations driving development of the various schemes are discussed,
   and their drawbacks identified, thereby providing the foundations for
   the design of the ROHC framework and profiles [3].

3.1. Header Compression Fundamentals

   Header compression is possible because there is significant
   redundancy between header fields; both within the same packet header
   but in particular between consecutive packets belonging to the same
   flow. On the path end-to-end, the entire header information is
   necessary for all packets in the flow, but over a single link some of
   it becomes redundant and can be reduced, as long as it is
   transparently recovered at the receiving end of the link. The header
   size can be reduced by first sending field information that is
   expected to remain static for (at least most of) the lifetime of the
   flow. Further compression is achieved for the fields carrying
   information changing more dynamically by using compression methods
   tailored to their respective assumed change behavior.





Jonsson, et. al                                                 [Page 6]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


   To achieve compression and decompression, some necessary information
   from past packets is maintained in a context. The compressor and the
   decompressor update their respective contexts upon certain, not
   necessarily synchronized, events. Impairment events may lead to
   inconsistencies in the decompressor context (i.e. context damage),
   which in turn may cause incorrect decompression. A robust header
   compression scheme needs mechanisms to minimize the possibility of
   context damage, in combination with mechanisms for context repair.

3.2. A Short History of Header Compression

   The first header compression scheme, CTCP [15], was introduced by Van
   Jacobson. CTCP, also often referred to as VJ compression, compresses
   the 40 octets of the TCP/IP header down to 4 octets. CTCP uses delta
   encoding for sequentially changing fields. The CTCP compressor
   detects transport-level retransmissions and sends a header that
   updates the entire context when they occur. This repair mechanism
   does not require any explicit signaling between compressor and
   decompressor.

   A general IP header compression scheme, IP header compression [16],
   improves somewhat on CTCP. IPHC can compress arbitrary IP, TCP, and
   UDP headers. When compressing non-TCP headers, IPHC does not use
   delta encoding and is robust. The repair mechanism of CTCP is
   augmented with negative acknowledgements, called CONTEXT_STATE
   messages, which speeds up the repair. This context repair mechanism
   is thus limited by the round-trip time of the link. IPHC does not
   compress RTP headers.

   CRTP [17] is an RTP extension to IPHC. CRTP compresses the 40 octets
   of IPv4/UDP/RTP headers to a minimum of 2 octets when the UDP
   Checksum is not enabled. If the UDP Checksum is enabled, the minimum
   CRTP header is 4 octets.

   On lossy links with long round-trip times, such as most cellular
   wireless links and IP tunnels, CRTP does not perform well [20]. Each
   packet lost over the link causes decompression of several subsequent
   packets to fail, because the context becomes out of sync during at
   least one link round-trip time from the lost packet. Unfortunately,
   the large headers that CRTP sends when updating the context waste
   additional bandwidth. This behavior is documented in [20].

   CRTP uses a local repair mechanism known as TWICE, which was
   introduced by IPHC. TWICE derives its name from the observation that
   when the flow of compressed packets is regular, the correct guess
   when one packet is lost between the compression points is to apply
   the update in the current packet twice. While TWICE improves CRTP
   performance significantly, [20] also found that even with TWICE, CRTP
   doubled the number of lost packets.





Jonsson, et. al                                                 [Page 7]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


   An enhanced variant of CRTP, called eCRTP [19], means to improve the
   robustness of CRTP in the presence of reordering and packet losses,
   while keeping the protocol almost unchanged from CRTP. As a result,
   eCRTP does provide better means to implement some degree of
   robustness, albeit at the expense of additional overhead leading to a
   reduction in compression efficiency in comparison to CRTP.

4. Overview of Robust Header compression (ROHC) (Informative)

4.1. General Principles

   As mentioned earlier, header compression is possible per link due to
   the fact that there is much redundancy between header field values
   within packets, and especially between consecutive packets of a
   packet flow. To utilize these properties for header compression,
   there are a few essential steps to consider.

   The first step consists in identifying and grouping packets together
   into different "flows", so that packet-to-packet redundancy is
   maximized in order to improve the compression ratio. Grouping packets
   into flows is usually based on source and destination host (IP)
   addresses, transport protocol type (e.g. UDP or TCP), process (port)
   numbers and potentially additional unique application identifiers,
   such as the SSRC in RTP [13]. For each flow, the compressor and the
   decompressor each establish a context for the flow, and identify the
   context with a CID included in each compressed header.

   The second step is to understand the change patterns of the various
   header fields. On a high level, header fields fall into one of the
   following classes:

    INFERRED      These fields contain values that can be inferred from
                  other fields or external sources, for example the size
                  of the frame carrying the packet can often be derived
                  from the link layer protocol, and thus does not have
                  to be transmitted at all by the compression scheme.

    STATIC        Fields classified as STATIC are assumed to be constant
                  throughout the lifetime of the packet flow. Their
                  value are therefore only communicated initially.

    STATIC-DEF    Fields classified as STATIC-DEF are used to define a
                  packet flow, as discussed above. Packets for which
                  respective values of these fields differ are treated
                  as belonging to different flows. They are in general
                  compressed as STATIC fields.

    STATIC-KNOWN  Fields classified as STATIC-KNOWN are expected to have
                  well-known values, and therefore their values do not
                  need to be communicated at all.




Jonsson, et. al                                                 [Page 8]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


    CHANGING      These fields are expected to vary randomly, within
                  a limited value set or range, or in some other manner.
                  CHANGING fields are usually handled in various
                  sophisticated ways, based on a more detailed
                  classification of their expected change patterns.

   Finally, the last step is to choose the encoding method(s) that will
   be applied onto different fields, based on the classification. The
   encoding methods, in combination with the identified field behavior,
   provide the input to the design of the compressed header formats. The
   analysis of the probability distribution of the identified change
   patterns then provide the means to optimize the packet formats, where
   the most frequently occurring change patterns for a field should be
   encoded within the most efficient format(s).

   However, compression efficiency has to be traded against two other
   properties: the robustness of the encoding to losses and errors
   between the compressor and the decompressor, and the ability to
   detect and cope with errors in the decompression process.

4.2. Compression Efficiency, Robustness and Transparency

   The performance of a header compression scheme can be described with
   three parameters: its compression efficiency, its robustness and its
   compression transparency.

   Compression efficiency

     The compression efficiency is determined by how much the header
     sizes are reduced by the compression scheme.

   Robustness

     A robust scheme tolerates packet losses, residual bit errors, and
     out-of-order delivery on the link over which header compression
     takes place, without losing additional packets or introducing
     additional errors in decompressed headers.

   Compression transparency

     The compression transparency is a measure of the extent to which
     the scheme maintains the semantics of the original headers. If all
     decompressed headers are semantically identical to the
     corresponding original headers, the scheme is transparent.

4.3. Developing the ROHC protocol

   The challenge in developing a header compression protocol is to
   conciliate compression efficiency and robustness, while maintaining
   transparency. Increasing robustness should not come at the expense of
   a lower compression efficiency, and vice-versa. The scheme should



Jonsson, et. al                                                 [Page 9]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


   also be flexible enough in its design to minimize the impacts from
   the varying round-trip times and loss patterns of links where header
   compression will be used.

   To achieve this, the header compression scheme must provide
   facilities for the decompressor to verify decompression and detect
   potential context damage, as well as facilities to perform local
   repairs and to send context repair requests when possible. Header
   compression schemes prior to the ones developed by the RObust Header
   Compression (ROHC) WG were not designed with the above high-level
   objectives in mind.

   The ROHC WG has developed header compression solutions to meet the
   needs of today's and future link technologies. While special
   attention has been put towards meeting the more stringent
   requirements stemming out from the characteristics of wireless links,
   the results are equally applicable to many other link technologies.

   RFC 3095 [3], "RObust Header Compression (ROHC): Framework and four
   profiles: RTP, UDP, ESP, and uncompressed", was published 2001, as
   the first output of the ROHC WG. ROHC is a general and extendable
   framework for header compression, on top of which profiles can be
   defined for compression of different protocols headers. RFC 3095
   introduced a number of new compression techniques, and was successful
   at living up to the requirements on it, as described in [18].

   Interoperability testing of RFC 3095 confirms the capabilities of
   ROHC to meet its purposes, but feedback from implementers have also
   indicated that the protocol specification is complex and sometimes
   obscure. Most importantly, a clear distinction between framework and
   profiles is not obvious, which also makes development of additional
   profiles troublesome. This document therefore aims at explicitly
   specifying the ROHC framework, while a companion document [8]
   specifies revised versions of the compression profiles of RFC 3095.

4.4. Operational Characteristics of the ROHC Channel

   Robust header compression can be used over many type of link
   technologies. The ROHC framework provides flexibility for profiles to
   address a wide range of applications, and this section lists some of
   the operational characteristics of the ROHC channel (see also [5]).

   Multiplexing over a single logical channel

      The ROHC channel provides a mechanism to identify a context within
      the general ROHC header format. The Context Identifier (CID) makes
      it possible for a logical channel that supports ROHC to transport
      multiple header-compressed flows, while still making it possible
      for a channel to be dedicated to one single flow without any CID
      overhead. More specifically, ROHC uses a distinct context
      identifier space per logical channel, and the context identifier



Jonsson, et. al                                                [Page 10]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


      can be omitted for one of the flows over the ROHC channel when
      configured to use a small CID space.

   Establishment of Channel Parameters

      A link layer defining support for the ROHC channel must provide
      the means to establish header compression channel parameters (see
      section 5.1). This can be achieved either through a negotiation
      mechanism, static provisioning or some out-of-band signaling.

   Packet type indication

      The ROHC channel defines a packet type identifier space, and puts
      restrictions with respect to the use of a number of identifiers
      that are common for all ROHC profiles. Identifiers that have no
      restrictions, i.e. identifiers that are not defined by this
      document, are available to each profile. The identifier is part
      of each compressed header, and this makes it possible for the link
      that supports the ROHC channel to allocate one single packet type
      for ROHC.

   Out-of-order delivery between compression endpoints

      Each profile define its own level of robustness, including against
      reordering of packets between compression endpoints, if any.

      The definition of the ROHC channel includes state that is
      established prior to the first header compressed packet being
      sent. It does not in itself make any assumption with respect to
      the order of the packets that are delivered by the link to the
      decompressor. However, the channel state can include parameters
      that characterizes the maximum reordering depth that profiles
      supporting out-of-order delivery over the ROHC channel may use.

      For profiles specified in [3], the channel between compressor and
      decompressor is required to maintain in-order delivery of the
      packets, i.e. the definition of these profiles assume that the
      decompressor always receives packets in the same order as the
      compressor sent them. The impacts of reordering on the performance
      of these profiles is described in [7]. Reordering before the
      compression point, however, is dealt with, i.e. these profiles
      make no assumption that the compressor will only receive packets
      in sequence.

      For the ROHCv2 profiles specified in [8], their definition assume
      that the decompressor can receive packets out-of-order, i.e. not
      in the same order as the compressor sent them. Reordering before
      the compression point is also dealt with.






Jonsson, et. al                                                [Page 11]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


   Duplication of packets

      The link supporting the ROHC channel is required to not duplicate
      packets (duplication before the compression point, however, is
      dealt with, i.e., there is no assumption that the compressor will
      receive only one copy of each packet).

   Framing

      The link layer must provide framing that makes it possible to
      distinguish frame boundaries and individual frames.

   Error detection/protection

      ROHC profiles are designed to cope with residual errors in the
      headers delivered to the decompressor. CRCs are used to detect
      decompression failures and to prevent or reduce damage
      propagation. However, it is recommended that lower layers deploy
      error detection for ROHC headers and to not deliver ROHC headers
      with high residual error rates.

4.5. Compression and Master Sequence Number (MSN)

   Compression of header fields is based on the establishment of a
   function to a sequence number, called the Master Sequence Number
   (MSN). This function describes the change pattern of the field with
   respect to an increase of the MSN.

   Change patterns include e.g. fields that increase monotonically or by
   a small value, but also fields that seldom change as well as fields
   that remain unchanging for the entire lifetime of the flow, in which
   case the function to the MSN is equivalent to a constant value.

   The compressor first establishes functions for each of the header
   fields, and it then reliably communicates the MSN. When the change
   pattern of the field does not match the established function, i.e.,
   the existing function gives a result that is different from the field
   in the header to be compressed, additional information is sent to
   update the parameters of that function.

   The MSN is defined per profile. It can be either derived directly
   from one of the fields of the protocol being compressed (e.g. the RTP
   SN [8]), or it can be created and maintained by the compressor (e.g.
   the MSN for compression of UDP in profile 0x0102 [8] or the MSN in
   ROHC-TCP [9]).

4.6. Static and Dynamic parts of a Context

   A compression context can be conceptually divided into two different
   parts, the static context and the dynamic context, each based on the
   properties of the fields that are being compressed.



Jonsson, et. al                                                [Page 12]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


   The static part includes the information necessary to compress and
   decompress the fields whose change behavior is classified as STATIC,
   STATIC-KNOWN or STATIC-DEF (as described in section 4.1 above.

   The dynamic part includes the state maintained for all the other
   fields, i.e. those that are classified as CHANGING.

5. The ROHC Framework (Normative)

   This section normatively defines the parts common to all ROHC
   profiles, i.e. the framework. The framework specifies the
   requirements and functionality of the ROHC channel, including how to
   handle multiple compressed flows over the same channel.

   Finally, this section specifies encoding methods used in the packet
   formats that are common to all profiles. These encoding methods may
   be reused within profile specifications for encoding fields in
   profile-specific parts of a packet format, without requiring their
   redefinition.

5.1. The ROHC Channel

5.1.1. Contexts and Context Identifiers

   Associated with each compressed flow is a context. The context is the
   state that the compressor and the decompressor maintain in order to
   correctly compress or decompress the headers of the packet in the
   flow. Each context is identified using a Context Identifier (CID).

   A context is considered to be a new context when the CID is
   associated with a profile for the first time since the creation of
   the ROHC channel, or when the CID gets associated from the reception
   of an IR (this does not apply to the IR-DYN) with a different profile
   than the profile in the context.

   Context information is conceptually kept in a table. The context
   table is indexed using the CID, which is sent along with compressed
   headers and feedback information.

   The CID space can be either small, which means that CIDs can take the
   values 0 through 15, or large, which means that CIDs take values
   between 0 and 2^14 - 1 = 16383. Whether the CID space is large or
   small MUST be established, possibly by negotiation, before any
   compressed packet may be sent over the ROHC channel.

   The CID space is distinct for each channel, i.e., CID 3 over channel
   A and CID 3 over channel B do not refer to the same context, even if
   the endpoints of A and B are the same nodes. In particular, CIDs for
   any pair of ROHC channels are not related (two associated ROHC
   channels serving as feedback channels for one another need not even
   have CID spaces of the same size).



Jonsson, et. al                                                [Page 13]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


5.1.2. Per-Channel Parameters

   The ROHC channel is based on a number of parameters that form part of
   the established channel state and the per-context state. The state of
   the ROHC channel MUST be established before the first ROHC packet may
   be sent. This may be achieved using negotiation protocols provided by
   the link layer (see also [4], which describes an option for
   negotiation of ROHC parameters for PPP. This section describes some
   of this state information in an abstract way:

   MAX_CID: Nonnegative integer; highest context ID number to be used by
      the compressor (note that this parameter is not coupled to, but in
      effect further constrained by, LARGE_CIDS). This value represents
      an agreement by the decompressor that it can provide sufficient
      memory resources to host at least MAX_CID+1 contexts; the
      decompressor MUST maintain established contexts within this space
      until either the CID gets re-used or the channel is taken down.

   LARGE_CIDS: Boolean; if false, the short CID representation (0 bytes
      or 1 prefix byte, covering CID 0 to 15) is used; if true, the
      embedded CID representation (1 or 2 embedded CID bytes covering
      CID 0 to 16383) is used. See also 5.1.1.

   PROFILES: Set of nonnegative integers, each integer indicating a
      profile supported by the decompressor. A profile is identified by
      a 16-bit value, where the 8 LSB bits indicate the actual profile,
      and the 8 MSB bits indicate the variant of that profile.  The ROHC
      compressed header format identifies the profile used with only the
      8 LSB bits; this means that if multiple variants of the same
      profile are available for a ROHC channel, the PROFILES set MUST
      NOT include more than one variant of the same profile after
      negotiation. The compressor MUST NOT compress using a profile not
      in PROFILES.

   FEEDBACK_FOR: Optional reference to a channel in the reverse
      direction. If provided, this parameter indicates which channel
      any feedback sent on this channel refers to (see [5]).

   MRRU: Nonnegative integer. Maximum reconstructed reception unit. This
      is the size of the largest reconstructed unit in octets that the
      decompressor is expected to reassemble from segments (see 5.2.4).
      Note that this size includes the CRC. If MRRU is negotiated to be
      0, no segment headers are allowed on the channel.

   MAX_R_DEPTH: Nonnegative integer. Maximum reordering depth expected
      between the compressor and the decompressor, when the link
      supporting the RoHC channel cannot guarantee in-order delivery. If
      MAX_R_DEPTH is negotiated to be 0, the channel is assumed not to
      deliver packets to the decompressor in an order that differs for
      the order the compressor sent them, per compressed flow (CID).
      This parameter is optional.



Jonsson, et. al                                                [Page 14]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


5.2. ROHC Packets and Packet Types

   This section uses the following convention in the diagrams when
   representing various ROHC packet types, fields and formats:

     - colons ":" indicate that the part is optional
     - slashes "/" indicate variable length

   The ROHC packet type indication scheme has been designed to provide
   optional padding, a feedback packet type, an optional Add-CID octet
   (which include 4 bits of CID), and a simple segmentation and
   reassembly mechanism.

   The following packet types are reserved at the ROHC framework level:

     1110     : Padding or Add-CID octet
     11110    : Feedback
     11111000 : IR-DYN packet
     1111110  : IR packet
     1111111  : Segment

   Other packet types can be defined and used by individual profiles:

     0        : available (not reserved by ROHC framework)
     10       : available (not reserved by ROHC framework)
     110      : available (not reserved by ROHC framework)
      1111101  : available (not reserved by ROHC framework)
      11111001 : available (not reserved by ROHC framework)

5.2.1. General Format of ROHC Packets

   A ROHC packet has the following general format:

    --- --- --- --- --- --- --- ---
   :           Padding             :  variable length
    --- --- --- --- --- --- --- ---
   :           Feedback            :  0 or more feedback elements
    --- --- --- --- --- --- --- ---
   :            Header             :  variable, with CID information
    --- --- --- --- --- --- --- ---
   :           Payload             :  variable length
    --- --- --- --- --- --- --- ---

   Padding is any number (zero or more) of padding octets.

   Feedback may consist of multiple concatenated feedback elements, as
   defined in 5.2.3.1.

   Header is either a profile-specific header or an IR or IR-DYN header
   (see section 5.2.2).




Jonsson, et. al                                                [Page 15]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


   Payload corresponds to zero or more octets of payload from the
   uncompressed packet, starting with the first octet in the
   uncompressed packet after the last header compressible by the current
   profile.

   At least one of Feedback or Header MUST be present.

5.2.1.1. Format of the Padding Octet

   Padding Octet:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   1   0   0   0   0   0 |
   +---+---+---+---+---+---+---+---+

   Note: The Padding Octet MUST NOT be interpreted as an Add-CID
   octet for CID 0.

5.2.1.2. Format of the Add-CID octet

   Add-CID Octet:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   1   0 |      CID      |
   +---+---+---+---+---+---+---+---+

   CID:   0x1 through 0xF indicates CIDs 1 through 15.

   Note: The Padding Octet looks like an Add-CID octet for CID 0.

5.2.1.3. General Format of the Compressed Header Types

   All Header packet types have the following general format:

     0              x-1  x       7
    --- --- --- --- --- --- --- ---
   :         Add-CID octet         :  if (CID 1-15) and (small CIDs)
   +---+--- --- --- ---+--- --- ---+
   | type indication   |   body    |  1 octet (8-x bits of body)
   +---+--- ---+---+---+--- --- ---+
   :                               :
   /    0, 1, or 2 octets of CID   /  1 or 2 octets if (large CIDs)
   :                               :
   +---+---+---+---+---+---+---+---+
   /             body              /  variable length
   +---+---+---+---+---+---+---+---+

   Header either starts with a packet type indication or has a packet
   type indication immediately following an Add-CID Octet:



Jonsson, et. al                                                [Page 16]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005



     When the ROHC channel is configured with a small CID space:

       o If an Add-CID immediately precedes the packet type, it has the
         CID of the Add-CID; otherwise it has CID 0.

       o A small CID with the value 0 is represented using zero bits;
         therefore a flow associated with CID 0 has no CID overhead in
         the compressed header. In such case, Header starts with a
         packet type indication.

       o A small CID with a value from 1 to 15 is represented by a four-
         bit field in place of a packet type field (Add-CID) plus four
         more bits, i.e. using the Add-CID octet as described above. In
         this case, Header starts with the Add-CID octet, followed by a
         packet type indication.

       o There is no large CID in the compressed header.

     When the ROHC channel is configured with a large CID space:

       o The large CID is always present and is represented using the
         encoding scheme of section 5.3.2, limited to two octets. In
         this case, Header starts with a packet type indication.

5.2.2. Initialization and Refresh (IR) Packet Types

   Initially, all contexts are in no context state, i.e., all packets
   referencing this context except packets that have enough information
   on the static fields are discarded. Section 5.2.2.3 describes the
   decompressor logic for the IR and IR-DYN packet types.

   IR packet types contain a profile identifier, which determines how
   the rest of the header is to be interpreted. They also associate a
   profile with a context. The stored profile parameter further
   determines the syntax and semantics of the packet type identifiers
   and packet types used in conjunction with a specific context.

   The IR and IR-DYN packets always update the context for all context-
   updating fields carried in the header. It never clears the context,
   unless otherwise specified by the profile in the Profile field.

5.2.2.1. ROHC IR Packet Type

   The IR header associates a CID with a profile, and typically also
   initializes the context. It can typically also refresh all (or parts
   of) the context. It has the following general format.







Jonsson, et. al                                                [Page 17]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


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

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

   Profile: The profile to be associated with the CID. In the IR
      header, the profile identifier is abbreviated to the 8 least
      significant bits (see section 5.1.2).

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

   Profile specific information: The contents of this part of the IR
      header are defined by the individual profiles. Interpreted
      according to the profile indicated in the Profile field of the IR
      header.

5.2.2.2. ROHC IR-DYN Packet Type

   In contrast to the IR header, the IR-DYN header can never initialize
   an uninitialized context. However, it can redefine what profile is
   associated with a context, if the target profile allows this. Thus
   this packet type also needs to be reserved at the framework level.
   The IR-DYN header typically also initializes or refreshes parts of a
   context. It has the following general format:













Jonsson, et. al                                                [Page 18]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


     0   1   2   3   4   5   6   7
    --- --- --- --- --- --- --- ---
   :         Add-CID octet         : if for small CIDs and (CID != 0)
   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   1   0   0   0 | IR-DYN 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
   |                               |
   +---+---+---+---+---+---+---+---+

   Profile: The profile to be associated with the CID.  This is
       abbreviated in the same way as with IR packets.

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

   Profile specific information: This part of the IR packet is
       defined by individual profiles. It is interpreted according
       to the profile indicated in the Profile field.

5.2.2.3. ROHC Initial Decompressor Processing

   When the decompressor receives a packet of type IR, the profile
   indicated in the IR packet determines how it is to be processed.

   If the 8-bit CRC fails to verify the integrity of the header, the
   packet MUST NOT be delivered to upper layers. If a profile is
   indicated in the context, the logic of that profile determines what,
   if any, feedback is to be sent. If no profile is noted in the
   context, the logic used to determine what, if any, feedback is to be
   sent is up to the implementation; however, it may be suitable to take
   no further actions as any part of the IR packet may have caused the
   failure.

   When the decompressor receives a packet of type IR-DYN, the profile
   indicated in the IR-DYN packet determines how it is to be processed.

      o If the 8-bit CRC fails to verify the integrity of the header,
        the packet MUST NOT be delivered to upper layers. If a profile
        is indicated in the context, the logic of that profile
        determines what, if any, feedback is to be sent. If no profile
        is noted in the context, the logic used to determine what, if
        any, feedback is to be sent is up to the implementation;



Jonsson, et. al                                                [Page 19]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


        however, it may be suitable to take no further actions as any
        part of the IR packet may have caused the failure.

      o If the context has not been initialized by an IR packet, the
        packet MUST NOT be delivered to upper layers. The logic of the
        profile indicated in the IR-DYN header (if verified by the 8-bit
        CRC), determines what, if any, feedback is to be sent.

   If a parsing error occurs for any packet type, the decompressor MUST
   discard the packet without further processing. For example, a CID
   field is present in the compressed header when the large CID space is
   used for the ROHC channel, and the field is coded using the self-
   describing variable-length encoding of section 5.3.2; if the field
   starts with 110 or 111, this would generate a parsing error for the
   decompressor because this field must not be encoded with a size
   larger than 2 octets.

5.2.3. ROHC Feedback

   Feedback carries information from decompressor to compressor.
   Feedback can be sent over a ROHC channel that operates in the same
   direction as the feedback.

   The ROHC packet type scheme has been designed to allow the transport
   of feedback using interspersion or piggybacking, or a combination of
   both, over a ROHC channel with the help of the following properties:

   Reserved packet type:

      A feedback packet type is reserved at the framework level. The
      packet type can carry variable-length feedback information.

   CID information:

      The feedback information sent on a particular channel is passed
      to, and interpreted by, the compressor associated with feedback on
      that channel. Thus, the feedback information contains CID
      information. The ROHC feedback scheme thus requires that a channel
      carries feedback to at most one compressor. How a compressor is
      associated with the feedback for a particular channel is outside
      the scope of this specification. See also [5].

   Length information:

      The length of the feedback information can be determined by
      examining the first few octets of the feedback. This makes
      possible the piggybacking of feedback, and also the concatenation
      of more than one feedback element in a packet. The length
      information thus decouples the decompressor from the associated
      same-side compressor, as the decompressor can extract the feedback
      information from the compressed header without parsing its



Jonsson, et. al                                                [Page 20]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


      content, and hand over the extracted information.

   The association between compressor-decompressor pairs operating in
   opposite directions, for the purpose of exchanging piggyback and/or
   interspersed feedback, SHOULD be maintained for the lifetime of the
   ROHC channel. Otherwise, it is RECOMMENDED that the compressor be
   notified if the feedback channel is no longer available: the
   compressor SHOULD then restart compression by creating a new context
   for each flow, and SHOULD use a CID value that was not previously
   associated with the profile used to compress the flow.

5.2.3.1. ROHC Feedback Format

   ROHC defines three different categories of feedback messages:
   acknowledgement (ACK), negative ACK (NACK) and NACK for the entire
   context (STATIC-NACK). Other type of information may be defined in
   profile-specific feedback information.

   ACK         : Acknowledges successful decompression of a packet.
                 Indicates that the decompressor consider its context
                 to be valid up to this packet.

   NACK        : Indicates that the decompressor considers some or all
                 of the dynamic part of its context invalid.

   STATIC-NACK : Indicates that the decompressor considers its entire
                 static context invalid, or that it has not been
                 established.

   Feedback sent on a ROHC channel consists of one or more concatenated
   feedback elements, where each feedback element has the following
   format:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   0 |   Code    |  feedback type octet
   +---+---+---+---+---+---+---+---+
   :             Size              :  if Code = 0
   +---+---+---+---+---+---+---+---+
   :         Add-CID octet         : if for small CIDs and (CID != 0)
   +---+---+---+---+---+---+---+---+
   :                               :
   /  large CID (5.3.2 encoding)   / 1-2 octets if for large CIDs
   :                               :
   +---+---+---+---+---+---+---+---+
   /         FEEDBACK type         / variable length
   +---+---+---+---+---+---+---+---+

   Code: 0 indicates that a Size octet is present.
         1-7 indicates the size of the feedback data field, in
         octets.



Jonsson, et. al                                                [Page 21]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005



   Size: Optional field indicating the size of the feedback data
         field, in octets.

   FEEDBACK type: FEEDBACK-1 or FEEDBACK-2.

   CID information in feedback data indicates the CID of the packet flow
   for which feedback is sent. Note that the LARGE_CIDS parameter that
   controls whether a large CID is present is taken from the channel
   state of the receiving compressor's channel, NOT from that of the
   channel carrying the feedback.

   The large CID, if present, is encoded according to section 5.3.2.
   The CID field MUST NOT be encoded using more than 2 octets.

   The FEEDBACK type field can have either of the following two formats:

   FEEDBACK-1

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | profile specific information  |  1 octet
   +---+---+---+---+---+---+---+---+

   FEEDBACK-2

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   |Acktype|                       |
   +---+---+   profile specific    /  at least 2 octets
   /             information       |
   +---+---+---+---+---+---+---+---+

   Acktype:  0 = ACK
             1 = NACK
             2 = STATIC-NACK
             3 is reserved (MUST NOT be used.  Otherwise unparseable.)

   Note: It is RECOMMENDED that profiles disallow the decompressor to
   make a decompression attempt for packets carrying only a 3-bit CRC
   after it has invalidated some or the entire dynamic context, until a
   packet that contains sufficient information on the dynamic fields is
   received, decompressed and successfully verified by a 7- or an 8-bit
   CRC.

5.2.4. ROHC segmentation

   ROHC defines a simple segmentation protocol. The compressor may
   perform segmentation e.g. to accommodate packets that are larger than
   a specific size configured for the channel.




Jonsson, et. al                                                [Page 22]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


5.2.4.1. Segmentation Usage Considerations

   The segmentation protocol defined in ROHC is not particularly
   efficient. It is not intended to replace link layer segmentation
   functions; these SHOULD be used whenever available and efficient for
   the task at hand.

   The ROHC segmentation protocol has been designed with an assumption
   of in-order delivery of packets between the compressor and the
   decompressor, using only a CRC for error detection, and no sequence
   numbers. If in-order delivery cannot be guaranteed, e.g. if
   MAX_R_DEPTH > 0, ROHC segmentation MUST NOT be used.

5.2.4.2. Segmentation Protocol

   Segment Packet

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   1   1   1 | F |
   +---+---+---+---+---+---+---+---+
   /           Segment             /  variable length
   +---+---+---+---+---+---+---+---+

   F: Final bit. If set, it indicates that this is the last segment of
      a reconstructed unit.

   Padding octets and/or feedback may precede the segment header. It
   never carries a CID. The reconstructed packet MUST NOT contain
   padding, segments or feedback.

   All segment header packets for one reconstructed unit have to be
   received consecutively and in the correct order by the decompressor,
   i.e., any non-segment-header packet following a non-final segment
   header aborts the reassembly of the current reconstructed unit and
   causes the decompressor to discard the non-final segments received on
   this channel so far. When a final segment header is received, the
   decompressor reassembles the segment carried in this packet and any
   non-final segments that immediately preceded it into a single
   reconstructed unit, in the order they were received. The
   reconstructed unit has the format:

   Reconstructed Unit

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   /   Reconstructed ROHC packet   /  variable length
   +---+---+---+---+---+---+---+---+
   /              CRC              /  4 octets
   +---+---+---+---+---+---+---+---+




Jonsson, et. al                                                [Page 23]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


   The CRC is used by the decompressor to validate the reconstructed
   unit. It uses the FCS-32 algorithm with the following generator
   polynomial: x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 + x^11 +
   x^12 + x^16 + x^22 + x^23 + x^26 + x^32 [2]. If the reconstructed
   unit is 4 octets or less, or if the CRC fails, or if it is larger
   than the channel parameter MRRU (see 5.1.2), the reconstructed unit
   MUST be discarded by the decompressor. If the CRC succeeds, the
   reconstructed ROHC packet is interpreted as a ROHC Header, optionally
   followed by a payload.

5.3. General encoding methods

5.3.1. Header compression CRCs, coverage and polynomials

   This chapter describes how to calculate the CRCs used in ROHC packet
   headers. For all CRCs, the algorithm in [2] is used, with the
   polynomials specified in subsequent sections. A PERL implementation
   of the algorithm can be found in Appendix A of [6].

   Note that another type of CRC is defined in section 5.2.4.2, to be
   used for reconstructed units.

5.3.1.1. 8-bit CRCs in IR and IR-DYN headers

   The CRC in the IR and IR-DYN packet is calculated over the entire IR
   or IR-DYN packet, excluding Payload and including CID or any Add-CID
   octet. Padding isn't meant to be a meaningful part of a packet and is
   not included in CRC calculation. As a result, the CRC doesn't cover
   the "Add-CID octet for CID 0".

   More specifically, the 8-bit CRC does not cover only and entirely the
   original uncompressed header; therefore it does not provide the means
   for the decompressor to verify a decompression attempt, or either the
   means to verify the correctness of the entire decompressor context.
   However, when successful, it does provide enough robustness for the
   decompressor to update its context with the information carried
   within the IR or the IR-DYN header.

   The CRC polynomial to be used for the 8-bit CRC is:

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

   For purposes of computing the CRC, the CRC field in the header is set
   to zero, and the initial content of the CRC register is to be preset
   to all 1's.

5.3.1.2. 3-bit CRC in Compressed Headers

   The 3-bit CRC in compressed headers is calculated over all octets of
   the entire original header, before compression, in the following
   manner.



Jonsson, et. al                                                [Page 24]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005



   The initial content of the CRC register is preset to all 1's.

   The polynomial to be used for the 3-bit CRC is:

      C(x) = 1 + x + x^3

   The purpose of the 3-bit CRC is to provide the means for the
   decompressor to verify the outcome of a decompression attempt for
   small compressed headers, and to detect context damage based on
   aggregated probability over a number of decompression attempts. It is
   however too weak to provide enough success guarantees from the
   decompression of one single header. Therefore, compressed headers
   carrying a 3-bit CRC are normally not suitable to perform context
   repairs at the decompressor; hence profiles should refrain from
   allowing decompression of such header when some or the entire
   decompressor context is assumed invalid.

5.3.1.3. 7-bit CRC in Compressed Headers

   The 7-bit CRC in compressed headers is calculated over all octets of
   the entire original header, before compression, in the following
   manner.

   The initial content of the CRC register is preset to all 1's.

   The polynomial to be used for the 7-bit CRC is:

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

   The purpose of the 7-bit CRC is to provide the means for the
   decompressor to verify the outcome of a decompression attempt for a
   larger compressed header, and to provide enough protection to
   validate a context repair at the decompressor. The 7-bit CRC is
   strong enough to assume a repair to be successful from the
   decompression of one single header; hence profiles may allow
   decompression of a header carrying a 7-bit CRC when some of the
   decompressor context is assumed invalid.

5.3.2. Self-describing variable-length values

   The values of many fields and compression parameters can vary widely.
   To optimize the transfer of such values, a variable number of octets
   are used to encode them. The first few bits of the first octet
   determine the number of octets used:

   First bit is 0: 1 octet.
            7 bits transferred.
            Up to 127 decimal.
            Encoded octets in hexadecimal: 00 to 7F




Jonsson, et. al                                                [Page 25]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


   First bits are 10: 2 octets.
            14 bits transferred.
            Up to 16 383 decimal.
            Encoded octets in hexadecimal: 80 00 to BF FF

   First bits are 110: 3 octets.
            21 bits transferred.
            Up to 2 097 151 decimal.
            Encoded octets in hexadecimal: C0 00 00 to DF FF FF

   First bits are 111: 4 octets.
            29 bits transferred.
            Up to 536 870 911 decimal.
            Encoded octets in hexadecimal: E0 00 00 00 to FF FF FF FF

5.4. ROHC UNCOMPRESSED -- no compression  (Profile 0x0000)

   This section describes the uncompressed ROHC profile. The profile
   identifier for this profile is 0x0000.

   Profile 0x0000 provides a way to send IP packets without compressing
   them. This can be used for any packet for which a compression profile
   is not available in the set of profiles supported by the ROHC
   channel, or for which compression is not desirable for some reason.

   After initialization, the only overhead for sending packets using
   Profile 0x0000 is the size of the CID. When uncompressed packets are
   frequent, Profile 0x0000 should be associated with a CID with size
   zero or one octet. Profile 0x0000 SHOULD be associated with at most
   one CID.
























Jonsson, et. al                                                [Page 26]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


5.4.1. IR Packet

   The initialization packet (IR packet) for Profile 0x0000 has the
   following 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 |res|
   +---+---+---+---+---+---+---+---+
   :                               :
   /    0-2 octets of CID info     / 1-2 octets if for large CIDs
   :                               :
   +---+---+---+---+---+---+---+---+
   |          Profile = 0          | 1 octet
   +---+---+---+---+---+---+---+---+
   |              CRC              | 1 octet
   +---+---+---+---+---+---+---+---+
   :                               : (optional)
   /           IP packet           / variable length
   :                               :
    --- --- --- --- --- --- --- ---

      res: Always set to zero, ignored by the decompressor.

      Profile: 0.

      CRC: 8-bit CRC, computed using the polynomial of section
           5.3.1.1. The CRC covers the first octet of the IR packet
           through the Profile octet of the IR packet, i.e., it does not
           cover the CRC itself or the IP packet.

      IP packet: An uncompressed IP packet may be included in the IR
           packet. The decompressor determines if the IP packet is
           present by considering the length of the IR packet.







5.4.2. Normal Packet

   A Normal packet is a normal IP packet plus CID information. When the
   channel uses small CIDs, and profile 0x0000 is associated with a
   CID > 0, an Add-CID octet is prepended to the IP packet. When the
   channel uses large CIDs, the CID is placed so that it starts at the
   second octet of the Normal packet.




Jonsson, et. al                                                [Page 27]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


     0   1   2   3   4   5   6   7
    --- --- --- --- --- --- --- ---
   :         Add-CID octet         : if for small CIDs and (CID != 0)
   +---+---+---+---+---+---+---+---+
   |   first octet of IP packet    |
   +---+---+---+---+---+---+---+---+
   :                               :
   /    0-2 octets of CID info     / 1-2 octets if for large CIDs
   :                               :
   +---+---+---+---+---+---+---+---+
   |                               |
   /       rest of IP packet       / variable length
   |                               |
   +---+---+---+---+---+---+---+---+

   Note that the first octet of the IP packet starts with the bit
   pattern 0100 (IPv4) or 0110 (IPv6). This does not conflict with any
   reserved packet types. Hence, no bits in addition to the CID are
   needed.

5.4.3. Decompressor Operation

   The decompressor can be in either of two states: NO_CONTEXT or
   FULL_CONTEXT. It starts in NO_CONTEXT.

      When an IR packet is received in the NO_CONTEXT state, the
      decompressor first validates its header using the 8-bit CRC. If
      the header is successfully validated, the decompressor 1) moves to
      the FULL_CONTEXT state, 2) delivers the IP packet to upper
      layers if present, 3) MAY send an ACK. If the header fails
      validation, it MUST NOT be delivered to upper layers.

      When any other packet is received in the NO_CONTEXT state, it is
      discarded without further action.

      When an IR packet is received in the FULL_CONTEXT state, the
      header is first validated using the 8-bit CRC. If the CRC
      validation succeeds, the decompressor 1) delivers the IP packet to
      upper layers if present, 2) MAY send an ACK. If the header fails
      validation, no action is taken and the packet MUST NOT be
      delivered to upper layers.

      When a Normal packet is received in the FULL_CONTEXT state, the
      CID information is removed and the IP packet is delivered to upper
      layers.

5.4.4. Feedback

   The only kind of feedback in Profile 0x0000 is ACKs. ACKs use the
   FEEDBACK-1 format of section 5.2.3.1. The value of the profile-
   specific octet in the FEEDBACK-1 ACK is 0 (zero).



Jonsson, et. al                                                [Page 28]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


6. Overview of a ROHC Profile (Informative)

   The ROHC protocol is made up of a framework part and a profile part.
   The framework defines the mechanisms common to all profiles, while
   the profile defines the compression algorithm.
   Section 5 specified the details of the ROHC framework. This section
   provides an informative overview of the elements that make a profile
   specification. The normative specification of individual profiles is
   outside the scope of this document.

   A ROHC profile defines the elements that build up the compression
   algorithm. A ROHC profile consists of:
   Packet formats:

     o Bits-on-the-wire

       The profile defines the layout of the bits for profile-specific
       packet types that it defines, and for the profile-specific parts
       of packet types common to all profiles (e.g. IR and IR-DYN).

     o Field encodings

       Bits and groups of bits from the packet format layout, referred
       to as compressed fields, represents the result of an encoding
       method specific for that compressed field within a specific
       packet format. The profile defines these encoding methods.

     o Updating properties

       The profile-specific packet formats may update the state of the
       decompressor, and may do so in different ways. The profile
       defines how individual profile-specific fields, or entire
       profile-specific packet types, updates the decompressor context.

     o Verification

       Packets that update the state of the decompressor are verified,
       to prevent incorrect updates to the decompressor context. The
       profile defines the mechanism used to verify the decompression of
       a packet.

   Context management:

     o Robustness logic

       Packets may be lost or reordered between the compressor and the
       decompressor. The profile defines mechanism to minimize the
       impacts of such events, and prevent damage propagation.






Jonsson, et. al                                                [Page 29]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


     o Repair mechanism

       Despite the robustness logic, impairment events may still lead to
       decompression failure(s), and even to context damage at the
       decompressor. The profile defines repair mechanisms, including
       feedback logic if used.

7. Security Considerations

   Because encryption eliminates the redundancy that header compression
   schemes try to exploit, there is some inducement to forego encryption
   of headers in order to enable operation over low-bandwidth links.

   A malfunctioning or malicious header compressor could cause the
   header decompressor to reconstitute packets that do not match the
   original packets but still have valid headers and possibly also valid
   transport checksums. Such corruption may be detected with end-to-end
   authentication and integrity mechanisms, which will not be affected
   by the compression. Moreover, the ROHC header compression scheme uses
   an internal checksum for verification of reconstructed headers, which
   reduces the probability of producing decompressed headers not
   matching the original ones without this being noticed.

   Denial-of-service attacks are possible if an intruder can introduce
   (for example) bogus IR, IR-DYN or FEEDBACK packets onto the link and
   thereby cause compression efficiency to be reduced. However, an
   intruder having the ability to inject arbitrary packets at the link
   layer in this manner raises additional security issues that dwarf
   those related to the use of header compression.

8. IANA Considerations

   An IANA registry for "RObust Header Compression (ROHC) Profile
   Identifiers" [21] was created by RFC 3095 [3]. The assignment policy,
   as outlined by RFC 3095, is the following:

   The ROHC profile identifier is a non-negative integer. In many
   negotiation protocols, it will be represented as a 16-bit value. Due
   to the way the profile identifier is abbreviated in ROHC packets, the
   8 least significant bits of the profile identifier have a special
   significance: Two profile identifiers with identical 8 LSBs should be
   assigned only if the higher-numbered one is intended to supersede the
   lower-numbered one. To highlight this relationship, profile
   identifiers should be given in hexadecimal (as in 0x1234, which would
   for example supersede 0x0A34).

   Following the policies outlined in [22], the IANA policy for
   assigning new values for the profile identifier shall be
   Specification Required: values and their meanings must be documented
   in an RFC or in some other permanent and readily available reference,
   in sufficient detail that interoperability between independent



Jonsson, et. al                                                [Page 30]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


   implementations is possible.  In the 8 LSBs, the range 0 to 127 is
   reserved for IETF standard-track specifications; the range 128 to 254
   is available for other specifications that meet this requirement
   (such as Informational RFCs).  The LSB value 255 is reserved for
   future extensibility of the present specification.

   The following profile identifiers have so far been allocated:

   Profile Identifier    Usage                      Reference
   ------------------    ----------------------     ---------
   0x0000                ROHC uncompressed          RFC 3095
   0x0001                ROHC RTP                   RFC 3095
   0x0002                ROHC UDP                   RFC 3095
   0x0003                ROHC ESP                   RFC 3095
   0x0004                ROHC IP                    RFC 3843
   0x0005                ROHC LLA                   RFC 3242
   0x0105                ROHC LLA with R-mode       RFC 3408
   0x0007                ROHC RTP/UDP-Lite          RFC 4019
   0x0008                ROHC UDP-Lite              RFC 4019

   New profiles will need new identifiers to be assigned by the IANA,
   but this document does not require any additional IANA action.

9. Acknowledgment

   The authors would like to acknowledge all who have contributed to
   previous ROHC work, and especially to the authors of RFC 3095 [3],
   which is the technical basis for this document. Thanks also to the
   various individuals who contributed to the ROHC RTP implementer's
   guide, from which technical corrections and clarifications, when
   applicable, have been incorporated into this document.

10. References

10.1. Normative References

   [1]  S. Bradner, "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, March 1997.

   [2]  W. Simpson, "PPP in HDLC-like framing", STD 51, RFC 1662, July
        1994.

10.2. Informative References

   [3]  C. Bormann, et al., "RObust Header Compression (ROHC): Framework
        and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095,
        July 2001.

   [4]  C. Bormann, "RObust Header Compression (ROHC) over PPP", RFC
        3241, April 2002.




Jonsson, et. al                                                [Page 31]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


   [5]  L-E. Jonsson, "RObust Header Compression (ROHC): Terminology and
        Channel Mapping Examples", RFC 3759, April 2004.

   [6]  L-E. Jonsson, et al., "RObust Header Compression (ROHC):
        Corrections and Clarifications to RFC 3095", internet-draft
        (work in progress), May 2006.
        <draft-ietf-rohc-rtp-impl-guide-19.txt>

   [7]  G. Pelletier, L-E. Jonsson, and K. Sandlund, "RObust Header
        Compression (ROHC): ROHC over Channels that can Reorder
        Packets", RFC 4224, January 2006.

   [8]  G. Pelletier, and K. Sandlund, "RObust Header Compression
        Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP, and UDP-
        Lite", internet-draft (work in progress), June 2006.
        <draft-pelletier-rohc-rfc3095bis-profiles-00.txt>

   [9]  G. Pelletier, L-E. Jonsson, K. Sandlund, and M. West, "RObust
        Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)",
        internet-draft (work in progress), June 2006.
        <draft-ietf-rohc-tcp-12.txt>

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

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

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

   [13] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
        "RTP: A Transport Protocol for Real-Time Applications", RFC
        3550, July 2003.

   [14] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
        September 1981.

   [15] V. Jacobson, "Compressing TCP/IP Headers for Low-Speed Serial
        Links", RFC 1144, February 1990.

   [16] Degermark, M., Nordgren, B. and S. Pink, "IP Header
        Compression", RFC 2507, February 1999.

   [17] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for
        Low-Speed Serial Links", RFC 2508, February 1999.

   [18] M. Degermark, "Requirements for robust IP/UDP/RTP header
        compression", RFC 3096, July 2001.

   [19] T. Koren, et al., "Enhanced Compressed RTP (CRTP) for Links with
        High Delay, Packet Loss and Reordering", RFC 3545, July 2003.



Jonsson, et. al                                                [Page 32]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005



   [20] Degermark, M., Hannu, H., Jonsson, L.E., and K. Svanbro,
        "Evaluation of CRTP Performance over Cellular Radio Networks",
        IEEE Personal Communication Magazine, Volume 7, number 4, pp.
        20-25, August 2000.

   [21] IANA registry, "RObust Header Compression (ROHC) Profile
        Identifiers", http://www.iana.org/assignments/rohc-pro-ids

   [22] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

11. Authors' Addresses

   Lars-Erik Jonsson
     Ericsson AB
     Box 920
     SE-971 28 Lulea, Sweden
     Phone: +46 8 404 29 61
     Fax:   +46 920 996 21
     EMail: lars-erik.jonsson@ericsson.com

   Ghyslain Pelletier
     Ericsson AB
     Box 920
     SE-971 28 Lulea, Sweden
     Phone: +46 8 404 29 43
     Fax:   +46 920 996 21
     EMail: ghyslain.pelletier@ericsson.com

   Kristofer Sandlund
     Ericsson AB
     Box 920
     SE-971 28 Lulea, Sweden
     Phone: +46 8 404 41 58
     Fax:   +46 920 996 21
      EMail: kristofer.sandlund@ericsson.com

















Jonsson, et. al                                                [Page 33]

INTERNET-DRAFT             The ROHC Framework             June 26, 2005


Intellectual Property Statement

   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.


Copyright Statement

   Copyright (C) The Internet Society (2006). 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.


Disclaimer of Validity

   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.




This Internet-Draft expires December 26, 2006.








Jonsson, et. al                                                [Page 34]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/