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

Versions: (draft-ietf-rohc-rfc3095bis-improvements) 00 01 02 03 04 05 06 RFC 5225

Robust Header Compression                                   G. Pelletier
Internet-Draft                                               K. Sandlund
Intended status: Standards Track                                Ericsson
Expires: March 10, 2007                                September 6, 2006


RObust Header Compression Version 2 (RoHCv2): Profiles for RTP, UDP, IP,
                            ESP and UDP Lite
           draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.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.

   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/ietf/1id-abstracts.txt.

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

   This Internet-Draft will expire on March 10, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document specifies ROHC (Robust Header Compression) profiles
   that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol,
   User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (User
   Datagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP
   (Encapsulating Security Payload) headers.

   This specification update the profiles defined in RFC 3095, RFC 3843



Pelletier & Sandlund     Expires March 10, 2007                 [Page 1]

Internet-Draft               ROHCv2 Profiles              September 2006


   and RFC 4019 to their second version (RoHCv2 profiles).  The profiles
   herein thus supersede their earlier definition, but they do not
   obsolete them.

   The RoHCv2 specification introduce a number of simplifications to the
   rules and algorithms that govern the behavior of the compression
   endpoints.  It also defines robustness mechanisms that may be used by
   a compressor implementation to increase the probability of
   decompression success when packets can be lost and/or reordered on
   the ROHC channel.  Finally, the RoHCv2 profiles define its own
   specific set of packet formats, using the ROHC formal notation.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Classification of header fields . . . . . . . . . . . . .   8
     4.2.  Operational Characteristics of RoHCv2 Profiles  . . . . .   9
   5.  Overview of the RoHCv2 Profiles . . . . . . . . . . . . . . .   9
     5.1.  General Concepts  . . . . . . . . . . . . . . . . . . . .  10
       5.1.1.  Control Fields and Context Updates  . . . . . . . . .  10
     5.2.  Compressor Concepts . . . . . . . . . . . . . . . . . . .  10
       5.2.1.  Optimistic Approach . . . . . . . . . . . . . . . . .  10
       5.2.2.  Tradeoff between robustness to losses and to
               reordering  . . . . . . . . . . . . . . . . . . . . .  11
       5.2.3.  Interactions with the Decompressor Context  . . . . .  12
     5.3.  Decompressor Concepts . . . . . . . . . . . . . . . . . .  13
       5.3.1.  Decompressor State Machine  . . . . . . . . . . . . .  14
       5.3.2.  Decompressor Context Management . . . . . . . . . . .  16
       5.3.3.  Feedback logic  . . . . . . . . . . . . . . . . . . .  17
   6.  RoHCv2 Profiles (Normative) . . . . . . . . . . . . . . . . .  18
     6.1.  Profile Operation, per-context  . . . . . . . . . . . . .  18
     6.2.  Control Fields  . . . . . . . . . . . . . . . . . . . . .  19
       6.2.1.  Master Sequence Number (MSN)  . . . . . . . . . . . .  19
       6.2.2.  IP-ID behavior  . . . . . . . . . . . . . . . . . . .  20
     6.3.  Reconstruction and Verification . . . . . . . . . . . . .  20
     6.4.  Compressed Header Chains  . . . . . . . . . . . . . . . .  21
     6.5.  Packet Formats and Encoding Methods . . . . . . . . . . .  22
       6.5.1.  baseheader_extension_headers  . . . . . . . . . . . .  22
       6.5.2.  baseheader_outer_headers  . . . . . . . . . . . . . .  22
       6.5.3.  inferred_udp_length . . . . . . . . . . . . . . . . .  23
       6.5.4.  inferred_ip_v4_header_checksum  . . . . . . . . . . .  23
       6.5.5.  inferred_mine_header_checksum . . . . . . . . . . . .  23
       6.5.6.  inferred_ip_v4_length . . . . . . . . . . . . . . . .  24
       6.5.7.  inferred_ip_v6_length . . . . . . . . . . . . . . . .  24



Pelletier & Sandlund     Expires March 10, 2007                 [Page 2]

Internet-Draft               ROHCv2 Profiles              September 2006


       6.5.8.  Scaled RTP Timestamp Encoding . . . . . . . . . . . .  25
       6.5.9.  inferred_scaled_field . . . . . . . . . . . . . . . .  26
       6.5.10. control_crc3  . . . . . . . . . . . . . . . . . . . .  26
       6.5.11. inferred_sequential_ip_id . . . . . . . . . . . . . .  27
       6.5.12. list_csrc(cc_value) . . . . . . . . . . . . . . . . .  27
     6.6.  Packet Formats  . . . . . . . . . . . . . . . . . . . . .  31
       6.6.1.  Initialization and Refresh Packet (IR)  . . . . . . .  31
       6.6.2.  IR  Packet Payload Discard (IR-PD)  . . . . . . . . .  32
       6.6.3.  IR Dynamic Packet (IR-DYN)  . . . . . . . . . . . . .  33
       6.6.4.  Compressed Packet Formats (CO)  . . . . . . . . . . .  34
     6.7.  Feedback Formats and Options  . . . . . . . . . . . . . .  85
       6.7.1.  Feedback Formats  . . . . . . . . . . . . . . . . . .  85
       6.7.2.  Feedback Options  . . . . . . . . . . . . . . . . . .  87
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  89
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  89
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  90
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  90
     10.1. Normative References  . . . . . . . . . . . . . . . . . .  90
     10.2. Informative References  . . . . . . . . . . . . . . . . .  92
   Appendix A.      Detailed classification of header fields . . . .  92
   Appendix A.1.    General classification . . . . . . . . . . . . .  93
   Appendix A.1.1.  IPv4 header fields . . . . . . . . . . . . . . .  93
   Appendix A.1.2.  IPv6 header fields . . . . . . . . . . . . . . .  95
   Appendix A.1.3.  UDP header fields  . . . . . . . . . . . . . . .  96
   Appendix A.1.4.  UDP-Lite header fields . . . . . . . . . . . . .  96
   Appendix A.1.5.  RTP header fields  . . . . . . . . . . . . . . .  97
   Appendix A.2.    Analysis of change patterns of header fields . .  98
   Appendix A.2.1.  IPv4 Identification  . . . . . . . . . . . . . . 100
   Appendix A.2.2.  IP Traffic Class / Type-Of-Service . . . . . . . 101
   Appendix A.2.3.  IP Hop-limit / Time-To-Live  . . . . . . . . . . 101
   Appendix A.2.4.  IPv4 Don't Fragment  . . . . . . . . . . . . . . 102
   Appendix A.2.5.  UDP Checksum . . . . . . . . . . . . . . . . . . 102
   Appendix A.2.6.  UDP-Lite Checksum Coverage . . . . . . . . . . . 102
   Appendix A.2.7.  UDP-Lite Checksum  . . . . . . . . . . . . . . . 102
   Appendix A.2.8.  RTP CSRC Counter . . . . . . . . . . . . . . . . 102
   Appendix A.2.9.  RTP Marker . . . . . . . . . . . . . . . . . . . 102
   Appendix A.2.10. RTP Padding  . . . . . . . . . . . . . . . . . . 103
   Appendix A.2.11. RTP Extension  . . . . . . . . . . . . . . . . . 103
   Appendix A.2.12. RTP Payload Type . . . . . . . . . . . . . . . . 103
   Appendix A.2.13. RTP Sequence Number  . . . . . . . . . . . . . . 103
   Appendix A.2.14. RTP Timestamp  . . . . . . . . . . . . . . . . . 103
   Appendix A.2.15. RTP Contributing Sources (CSRC)  . . . . . . . . 104
   Appendix A.3.    Header compression strategies  . . . . . . . . . 104
   Appendix A.3.1.  Do not send at all . . . . . . . . . . . . . . . 104
   Appendix A.3.2.  Transmit only initially  . . . . . . . . . . . . 104
   Appendix A.3.3.  Transmit initially, be prepared to update  . . . 105
   Appendix A.3.4.  Be prepared to update, or send as-is
                    frequently . . . . . . . . . . . . . . . . . . . 105



Pelletier & Sandlund     Expires March 10, 2007                 [Page 3]

Internet-Draft               ROHCv2 Profiles              September 2006


   Appendix A.3.5.  Guarantee continuous robustness  . . . . . . . . 105
   Appendix A.3.6.  Transmit as-is in all packets  . . . . . . . . . 105
   Appendix A.3.7.  Establish and be prepared to update delta  . . . 106
   Appendix B.      Differences between RoHCv2 and RFC3095
                    profiles . . . . . . . . . . . . . . . . . . . . 106
   Appendix C.      Sample CRC algorithm . . . . . . . . . . . . . . 106
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 108
   Intellectual Property and Copyright Statements  . . . . . . . . . 110











































Pelletier & Sandlund     Expires March 10, 2007                 [Page 4]

Internet-Draft               ROHCv2 Profiles              September 2006


1.  Introduction

   The ROHC WG has developed a header compression framework on top of
   which various profiles can be defined for different protocol sets or
   compression requirements.  The ROHC framework was first documented in
   [RFC3095], together with profiles for compression of RTP/UDP/IP
   (Real-Time Transport Protocol, User Datagram Protocol, Internet
   Protocol), UDP/IP, IP and ESP/IP (Encapsulating Security Payload)
   headers.  Additional profiles for compression of IP headers [RFC3843]
   and UDP-Lite (User Datagram Protocol Lite) headers [RFC4019] were
   later specified to complete the initial set of ROHC profiles.

   This document defines an updated version for each of the above
   mentionned profiles, and its definition is based on the specification
   of the RoHC framework as found in
   [I-D.ietf-rohc-rfc3095bis-framework].

   Specifically, this document defines header compression schemes for:

   o RTP/UDP/IP      : profile 0x0101 (updates profile 0x0001 [RFC3095])
   o UDP/IP          : profile 0x0102 (updates profile 0x0002 [RFC3095])
   o ESP/IP          : profile 0x0103 (updates profile 0x0003 [RFC3095])
   o IP              : profile 0x0104 (updates profile 0x0004 [RFC3843])
   o RTP/UDP-Lite/IP : profile 0x0107 (updates profile 0x0007 [RFC4019])
   o UDP-Lite/IP     : profile 0x0108 (updates profile 0x0008 [RFC4019])

   ROHCv2 compresses the following type of extension headers:

   o  AH [RFC4302]
   o  GRE [RFC2784][RFC2890]
   o  MINE [RFC2004]
   o  NULL-encrupted ESP [RFC4303]
   o  IPv6 Destination Options header[RFC2460]
   o  IPv6 Hop-by-hop Options header[RFC2460]
   o  IPv6 Routing header [RFC2460].


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   This document is consistent with the terminology found in the ROHC
   framework [I-D.ietf-rohc-rfc3095bis-framework] and in the formal
   notation for ROHC [I-D.ietf-rohc-formal-notation].  In addition, this
   document uses or defines the following terms:




Pelletier & Sandlund     Expires March 10, 2007                 [Page 5]

Internet-Draft               ROHCv2 Profiles              September 2006


   Chaining of Items

      A chain groups fields based on similar characteristics.  ROHCv2
      defines chain items for static, dynamic and irregular fields.
      Chaining is done by appending an item for e.g. each header to the
      chain in their order of appearance in the uncompressed packet.
      Chaining is useful to construct compressed headers from an
      arbitrary number of any of the protocol headers for which a ROHCv2
      profile defines a compressed format.

   CRC-8 validation

      The CRC-8 validation refers to the validation of the integrity
      against bit error(s) of the received IR and in the IR-DYN header,
      using the 8-bit CRC that is included in the header.

   CRC verification

      The CRC verification refers to the verification of the result of a
      decompression attempt, using the 3-bit CRC or 7-bit CRC included
      in the header of a compressed packet format (CO).

   Delta

      The delta refers to the difference in terms of the absolute value
      of a field between two consecutive packets and processed by the
      same compression endpoint.

   Reordering Depth

      The number of packets by which a packet made late in its sequence.
      See definition of sequentially late packet below.

   ROHCv2 packet types

      ROHCv2 profiles use two different packet types: the Initialization
      and Refresh (IR) packet type, and the Compressed packet type (CO).

   Sequentially early packet

      A packet that reaches the decompressor before one or several
      packets that were delayed over the channel, whereas all of the
      said packets belong to the same header-compressed flow and are
      associated to the same compression context (CID).  At the time of
      the arrival of a sequentially early packet, the packet(s) delayed
      on the link cannot be differentiated from lost packet(s).

   Sequentially late packet



Pelletier & Sandlund     Expires March 10, 2007                 [Page 6]

Internet-Draft               ROHCv2 Profiles              September 2006


      A packet is late within its sequence if it reaches the
      decompressor after one or several other packets belonging to the
      same CID have been received, although the sequentially late packet
      was sent from the compressor before the other packet(s).

   Timestamp stride (ts_stride)

      The timestamp stride (TS_STRIDE) is the expected increase in the
      timestamp value between two RTP packets with consecutive sequence
      numbers.


3.  Acronyms

   This section lists most acronyms used for reference, in addition to
   those defined in [I-D.ietf-rohc-rfc3095bis-framework].

   AH       Authentication Header.
   ESP      Encapsulating Security Payload.
   GRE      Generic Routing Encapsulation. RFC 2784, RFC 2890.
   IC       Initial Context state (decompressor)
   FC       Full Context state (decompressor)
   IP       Internet Protocol.
   LSB      Least Significant Bits.
   MINE     Minimal Encapsulation in IP
   MSB      Most Significant Bits.
   MSN      Master Sequence Number.
   NC       No Context state (decompressor).
   OA       Optimistic Approach.
   ROHCv2   Set of header compression profiles defined in this document
   RTP      Real-time Transport Protocol.
   SSRC     Synchronization source. Field in RTP header.
   CSRC     Contributing source. Optional list of CSRCs in RTP header.
   TC       Traffic Class. Octet in IPv6 header. See also TOS.
   TOS      Type Of Service. Octet in IPv4 header. See also TC.
   TS       RTP Timestamp.
   UDP      User Datagram Protocol.
   UDP-Lite User Datagram Protocol Lite.


4.  Background

   This section provides background information on the compression
   profiles defined in this document.  The fundamentals of general
   header compression and of the ROHC framework may be found in section
   3 and 4 of [I-D.ietf-rohc-rfc3095bis-framework], respectively.  The
   fundamentals of the formal notation for ROHC are defined in
   [I-D.ietf-rohc-formal-notation].  [RFC4224] describes the impacts of



Pelletier & Sandlund     Expires March 10, 2007                 [Page 7]

Internet-Draft               ROHCv2 Profiles              September 2006


   out-of-order delivery on profiles based on [RFC3095].

4.1.  Classification of header fields

   Section 3.1 of [I-D.ietf-rohc-rfc3095bis-framework] explains that
   header compression is possible due to the fact that there is much
   redundancy between field values within the headers of a packet, but
   especially between the headers of consecutive packets.

   Appendix A lists and classifies in detail all the header fields
   relevant to this document.  The appendix concludes with
   recommendations on how the various fields should be handled by header
   compression algorithms.

   The main conclusion is that most of the header fields can easily be
   compressed away since they never or seldom change.  A small number of
   fields however need more sophisticated mechanisms.

   These fields are:

   - IPv4 Identification        (16 bits) - IP-ID
   - ESP Sequence Number        (32 bits) - ESP SN
   - UDP Checksum               (16 bits) - Checksum
   - UDP-Lite Checksum          (16 bits) - Checksum
   - UDP-Lite Checksum Coverage (16 bits) - CC
   - RTP Marker                 ( 1 bit ) - M-bit
   - RTP Sequence Number        (16 bits) - RTP SN
   - RTP Timestamp              (32 bits) - TS

   In particular, for RTP, the analysis in Appendix A reveals that the
   values of the RTP Timestamp (TS) field usually have a strong
   correlation to the RTP Sequence Number (SN), which increments by one
   for each packet emitted by an RTP source.  The RTP M-bit is expected
   to have the same value most of the time, but it needs to be
   communicated explicitly on occasion.

   For UDP, the Checksum field cannot be inferred or recalculated at the
   receiving end without violating its end-to-end properties, and is
   thus sent as-is when enabled (mandatory with IPv6).  The same applies
   to the UDP-Lite Checksum (mandatory with both IPv4 and IPv6), while
   the UDP-Lite Checksum Coverage may in some cases be compressible.

   For IPv4, a similar correlation as the one of the RTP TS to the RTP
   SN is often observed between the Identifier field (IP-ID) and the
   master sequence number used for compression (e.g. the RTP SN when
   compressing RTP headers).





Pelletier & Sandlund     Expires March 10, 2007                 [Page 8]

Internet-Draft               ROHCv2 Profiles              September 2006


4.2.  Operational Characteristics of RoHCv2 Profiles

   Robust header compression can be used over many type of link
   technologies.  Section 4.4 of [I-D.ietf-rohc-rfc3095bis-framework]
   lists the operational characteristics of the ROHC channel.  The
   RoHCv2 profiles address a wide range of applications, and this
   section summarizes some of the operational characteristics that are
   specific to these profiles.

   Packet length

      ROHCv2 profiles assume that the lower layer indicates the length
      of a compressed packet.  ROHCv2 compressed headers do not contain
      length information for the payload.

   Out-of-order delivery between compression endpoints


      The definition of the RoHCv2 profiles places no strict requirement
      on the delivery sequence between the compression endpoints, i.e.
      packets may be received in a different order than the compressor
      sent them with a fair chance of successfully be decompressed.


      However, frequent out-of-order delivery and/or significant
      reordering depth will negatively impact the compression
      efficiency.  More specifically, if the channel state includes
      parameters that provide a proper estimate of such significant out-
      of-order delivery, larger headers can be sent more often to
      increase the robustness against decompression failures due to
      reordering.  Otherwise if the compressor cannot operate with
      sufficient knowledge for such reordering, the efficiency will be
      impaired from an increase in the frequency of decompression
      failures and recovery attempts.


5.  Overview of the RoHCv2 Profiles

   This section provides an overview of important and useful concepts of
   ROHCv2 profiles.  These concepts may be used as guidelines for
   implementations but they are not part of the normative definition of
   the profiles, as these concepts relates to the compression efficiency
   of the protocol without impacting the interoperability
   characteristics of an implementation.







Pelletier & Sandlund     Expires March 10, 2007                 [Page 9]

Internet-Draft               ROHCv2 Profiles              September 2006


5.1.  General Concepts

5.1.1.  Control Fields and Context Updates

   Control fields have the same attributes and properties as
   uncompressed fields [I-D.ietf-rohc-formal-notation].  These fields
   are used for compression and decompression of some of the
   uncompressed header fields.  Updating the value of one or more
   control field(s) is thus no less important than updating context
   values for header fields.  Control fields are defined in
   [I-D.ietf-rohc-formal-notation].

   Packet types that initialize or update the value of one or more
   control field(s) thus include an additional 3-bit CRC, as defined by
   the packet formats in Section 6.6.  The CRC is calculated using the
   UVALUE of the control field(s) that it covers.

   This CRC validates all the control fields that are updated.  Failure
   to verify this CRC should be interpreted by the decompressor as a
   decompression failure, in the algorithm it implements to assess the
   validity of its context.

5.2.  Compressor Concepts

   Header compression can be conceptually characterized as the
   interaction of a compressor with a decompressor state machine, one
   per context.  The responsability of the compressor is to minimally
   send the information needed to successfully decompress a packet,
   based on a certain confidence regarding the state of the decompressor
   context.

   This confidence is obtained from the frequency and the type of
   information the compressor sends when updating the decompressor
   context, from the optimistic approach and optionally from feedback
   messages received from the decompressor.

5.2.1.  Optimistic Approach

   A compressor always uses the optimistic approach when it performs
   context updates.  The compressor normally repeats the same type of
   update until it is fairly confident that the decompressor has
   successfully received the information.  If the decompressor
   successfully receives any of the headers containing this update,
   state will be available for the decompressor to process smaller
   compressed headers.

   If field X in the uncompressed header changes value, the compressor
   uses a packet type that contains an encoding of field X until it has



Pelletier & Sandlund     Expires March 10, 2007                [Page 10]

Internet-Draft               ROHCv2 Profiles              September 2006


   gained confidence that the decompressor has received at least one
   packet containing the new value for X. The compressor normally
   selects a compressed format with the smallest header that can convey
   the changes needed to achieve confidence.

   The number N of repetitions for the optimistic approach that is
   needed to obtain this confidence is normally related to the packet
   loss and to the out-of-order delivery characteristics of the link
   where header compression is used; it is thus not defined in this
   document and is left open to implementations.

5.2.2.  Tradeoff between robustness to losses and to reordering

   The ability of a header compression algorithm to handle sequentially
   late packets is mainly limited by two factors: the interpretation
   interval offset of the sliding window used for LSB encoded fields
   [I-D.ietf-rohc-formal-notation], and the optimistic approach
   Section 5.2.1 for seldom changing fields.

   The interpretation interval offset specifies an upper limit for the
   maximum reordering depth, by which is it possible for decompressor to
   recover the original value of a dynamically changing field that is
   encoded using W-LSB.  Its value is bound to the number of LSB
   compressed bits in the compressed header format, and grows with the
   number of bits transmitted.  However, the offset and the LSB encoding
   only provide robustness for the field that it compresses, and
   (implicitly) for other sequentially changing fields that are derived
   from that field.

   This is shown in the figure below:

      <--- interpretation interval (size is 2^k) ---->
      |------------------+---------------------------|
   v_ref-p             v_ref              v_ref + (2^k-1) - p
    Lower                                          Upper
    Bound                                          Bound
      <--- reordering --> <--------- losses --------->

      where delta(SN) = p is the maximum negative delta, corresponding
      to the maximum reordering depth for which the lsb encoding can
      recover the original value of the field;
      where delta(SN) = (2^k-1) - p is the maximum positive delta,
      corresponding to the maximum number of consecutive losses for
      which the lsb encoding can recover the original value of the
      field;






Pelletier & Sandlund     Expires March 10, 2007                [Page 11]

Internet-Draft               ROHCv2 Profiles              September 2006


      where v_ref is the reference value, as defined in the lsb encoding
      method in [I-D.ietf-rohc-formal-notation].

   The optimistic approach Section 5.2.1 provides the upper limit for
   the maximum reordering depth for seldom changing fields.

   There is thus a tradeoff between the robustness against reordering
   and the robustness against packet losses, with respect to the number
   of MSN bits needed and the distribution of the interpretation
   interval between negative and positive deltas in the MSN.

   There is also a tradeoff between compression efficiency and
   robustness.  When only information on the MSN needs to be conveyed to
   the decompressor, the tradeoff relates to the number of compressed
   MSN bits in the compressed header format.  Otherwise, the tradeoff
   relates to the implementation of the optimistic approach.

5.2.3.  Interactions with the Decompressor Context

   The compressor normally starts compression with the initial
   assumption that the decompressor has no useful information to process
   the new flow, and sends Initialization and Refresh (IR) packets.

   The compressor can then adjust the compression level based on its
   confidence that the decompressor has the necessary information to
   successfully process the compressed headers that it selects.  In
   other words, the responsability of the compressor is to ensure that
   the decompressor operates with state information that is sufficient
   to allow decompression of the most efficient compressed header(s),
   and to allow the decompressor to successfully recover that state
   information as soon as possible otherwise.

   The compressor thus has the entire responsability to ensure that the
   decompressor has the proper information to decompress the type of
   compressed header that it sends.  In other words, the choice of
   compressed header depends on the following factors:

   o  the outcome of the encoding method applied to each field;
   o  the optimistic approach, with respect to the characteristics of
      the channel;
   o  the presence or not of an established feedback channel, and if
      present, feedback received from the decompressor (ACKs, NACKs,
      Static-NACK and options).

   Encoding methods normally use previous value(s) from a history of
   packets whose headers it has previously compressed.  The optimistic
   approach is meant to ensure that at least one compressed header
   containing the information to update the state for a field is



Pelletier & Sandlund     Expires March 10, 2007                [Page 12]

Internet-Draft               ROHCv2 Profiles              September 2006


   received.  Finally, feedback indicates what actions the decompressor
   has taken with respect its assumptions regarding the validity of its
   context Section 5.3.2; it indicates what type of compressed header
   the decompressor can or cannot decompress.

   The decompressor has the means to detect decompression failures for
   any type of compressed (CO) header, using the CRC verification.
   Depending on the frequency and/or on the type of the failure, it
   might send a negative acknowledgement (NACK) or an explicit request
   for a complete context update (Static-NACK).  However, the
   decompressor does not have the means to identify the cause of the
   failure, and in particular decompression of what field(s) is
   responsible for the failure.  The compressor is thus always
   reponsible to figure out what is the most suitable response to a
   negative acknowledgement, using the confidence it has in the state of
   the decompressor context, when selecting the type of compressed
   header it will use when compressing a header.

5.3.  Decompressor Concepts

   Initially, when sending the first IR packet for a compressed flow,
   the compressor does not expect to receive feedback for that flow,
   until such feedback is first received.  At this point, the compressor
   may then assume that the decompressor will continue to send feedback
   in order to repair its context when necessary.  The former is
   referred to as unidirectional operation, while the latter is called
   bidirectional operation.

   The decompressor normally always uses the last received and
   successfully validated (IR or IR-DYN packets) or verified (CO
   packets) header as the reference for future decompression.  If the
   received packet is older than the current reference packet based on
   the MSN in the compressed header, the decompressor may refrain from
   using this packet as the new reference packet, even if the
   correctness of its header was successfully verified.

   The decompressor's responsability is thus to minimally consistently
   verify the outcome of the decompression attempt, update its context
   when successful and finally to request context repairs by making
   coherent usage of feedback, once it starts using it.

   Specifically, the outcome of every decompression attempt is verified
   using the CRC present in the compressed header; the decompressor
   updates the context information when this outcome is successfully
   verified; finally if the decompressor uses feedback once for a
   compressed flow then it will continue to do so for as long as the
   corresponding context is associated with the same profile.




Pelletier & Sandlund     Expires March 10, 2007                [Page 13]

Internet-Draft               ROHCv2 Profiles              September 2006


5.3.1.  Decompressor State Machine

   The decompressor operation may be represented as a state machine
   defining three states: No Context (NC), Initial Context (IC) and Full
   Context (FC).

   The decompressor starts with no valid context, the NC state.
   Successful CRC-8 validation of an IR packet moves the decompressor to
   the IC state, where it stays until it successfully verifies a
   decompression attempt for compressed header with a 7-bit CRC.  The
   decompressor state machine normally does not leave the FC state once
   it has entered this state; only repeated decompression failures will
   force the decompressor to transit downwards to a lower state.

   Below is the state machine for the decompressor.  Details of the
   transitions between states and decompression logic are given in the
   sub-sections following the figure.
                                                          CRC-8(IR) or
                                                          CRC-8(IR-DYN)
                                                          Validation
                             CRC-8(IR) or                 CRC-7(CO) or
    CRC-8(IR)  CRC-8(IR)     CRC-8(IR-DYN)  CRC-7(CO)     CRC-3(CO)
    Failure    Validation    Validation     Verification  Verification
    +--->---+  +-->---->--+  +-->----->--+  +-->---->--+  +-->---->--+
    |       |  |          |  |           |  |          |  |          |
    |       v  |          v  |           v  |          v  |          v
   +-----------------+  +----------------------+  +-------------------+
   | No Context (NC) |  | Initial Context (IC) |  | Full Context (FC) |
   +-----------------+  +----------------------+  +-------------------+
       ^                 | ^ CRC-7(CO)      | ^                 |
       | Static Context  | | Failure or     | | Context Damage  |
       | Damage Detected | | PT not allowed | | Detected        |
       +--<-----<-----<--+ +----<------<----+ +--<-----<-----<--+
   where:
      CRC-8(IR) and/or CRC-8(IR-DYN) validation: successful CRC-8
      validation for the IR header and the IR-DYN header, respectively.
      CRC-7(CO) and/or CRC-3(CO) verification: successful CRC
      verification for the CO header, based on the number of CRC bits
      carried in the CO header.
      CRC-7(CO) failure: failure to CRC verify the decompression of a CO
      header carrying a 7-bit CRC.
      PT not allowed: the decompressor has received a packet type (PT)
      for which the decopressor's current context does not provide
      enough valid state information for that packet to be decompressed.







Pelletier & Sandlund     Expires March 10, 2007                [Page 14]

Internet-Draft               ROHCv2 Profiles              September 2006


      Static Context Damaged Detected: see definition in Section 5.3.2.
      Context Damage Detected: see definition in Section 5.3.2.

5.3.1.1.  No Context (NC) State

   Initially, while working in the No Context (NC) state, the
   decompressor has not yet successfully validated an IR packet.

   Attempting decompression:

      In the NC state, only packets carrying sufficient information on
      the static fields (i.e.  IR packets) can be decompressed.
   Upward transition:

      Upon receiving an IR packet, the decompressor validates the
      integrity of its header using the CRC-8 validation.  If the IR
      packet is successfully validated, the decompressor updates the
      context and use this packet as the reference packet.  Once an IR
      packet has initialized the context, the decompressor can transit
      to the IC state.

   Feedback logic:

      In the No Context state, the decompressor should send a STATIC-
      NACK if a packet of a type other than IR is received, or if an IR
      packet has failed the CRC-8 validation, subject to the feedback
      rate limitation as described in Section 5.3.3.

5.3.1.2.  Initial Context (IC) State

   In the IC state, the decompressor has successfully validated a IR
   packet.

   Attempting decompression:

      In the Initial Context state, only packets carrying sufficient
      information on the dynamic fields covered by an 8-bit CRC (e.g.
      IR and IR-DYN) or CO packets carrying a 7-bit CRC can be
      decompressed.
   Upward transition:

      The decompressor can move to the Full Context (FC) state when the
      CRC verification succeeds for a CO header carrying a 7-bit CRC.
   Downward transition:







Pelletier & Sandlund     Expires March 10, 2007                [Page 15]

Internet-Draft               ROHCv2 Profiles              September 2006


      The decompressor moves back to the NC state if it assumes static
      context damage.

   Feedback logic:

      In the IC state, the decompressor should send a STATIC-NACK when
      CRC-8 validation of an IR/IR-DYN fails, or when a CO header
      carrying a 7-bit CRC fails and if static context damage is
      assumed, subject to the feedback rate limitation as described
      Section 5.3.3.  If any other packet type is received, the
      decompressor should treat it as a CRC verification failure when
      deciding if a NACK is to be sent.

5.3.1.3.  Full Context (FC) State

   In the FC state, the decompressor has successfully verified a CO
   header with a 7-bit CRC.

   Attempting decompression:

      In the Full Context state, decompression can be attempted
      regardless of the type of packet received.
   Downward transition:

      I.

   Feedback logic:

      In the Full Context state, the decompressor should send a NACK
      when CRC-8 validation or CRC verification of any packet type fails
      and if context damage is assumed, subject to the feedback rate
      limitation as described in Section 5.3.3.

5.3.2.  Decompressor Context Management

   All header formats carry a CRC and are context updating.  A packet
   for which the CRC succeeds updates the reference values of all header
   fields, either explicitly (from the information about a field carried
   within the compressed header) or implicitly (fields that are inferred
   from other fields).

   The decompressor may assume that some or the entire context is
   invalid, following one or more failures to validate or verify a
   header using the CRC.  Because the decompressor cannot know the exact
   reason(s) of a CRC failure or what field caused it, the validity of
   the context hence does not refer to what exact context entry is
   deemed valid or not.




Pelletier & Sandlund     Expires March 10, 2007                [Page 16]

Internet-Draft               ROHCv2 Profiles              September 2006


   Validity of the context rather relates to the detection of a problem
   with the context.  The decompressor first assume that the type of
   information that most likely caused the failure(s) is the state that
   normally changes for each packet, i.e. context damage of the dynamic
   part of the context.  Upon repeated failures and unsuccessful
   repairs, the decompressor then assume that the entire context,
   including the static part, needs to be repaired, i.e. static context
   damage.

   Context Damage Detection

      The assumption of context damage means that the decompressor will
      not attemp decompression of a CO headers that carries a 3-bit CRC,
      and only attempt decompression of IR or IR-DYN headers, or CO
      headers protected by a CRC-7.

   Static Context Damage Detection

      The assumption of static context damage means that the
      decompressor refrains from attempting decompression of any type of
      header other than the IR header, as it cannot know what part of
      its context can be relied upon after first assuming context damage
      and failed to repair its context, and as a result of too many
      failures.
   How these assumptions are made, i.e. how context damage is detected,
   is open to implementations.  It can be based on the residual error
   rate, where a low error rate makes the decompressor assume damage
   more often than on a high rate link.

   The decompressor implements these assumptions by selecting the type
   of compressed header for it may attempt decompression.  In other
   words, validity of the context refers to the ability of a
   decompressor to attempt or not decompression of specific packet
   types.

5.3.3.  Feedback logic

   RoHCv2 profiles may be used in environments with or without feedback
   capabilities from decompressor to compressor.  RoHCv2 however assumes
   that if a ROHC feedback channel is available and if this channel is
   used at least once by the decompressor for a specific context, this
   channel will be used during the entire compression operation for that
   context.  If the connection is broken and the feedback channel
   disappears, compression should be restarted.

   The RoHC framework defines 3 types of feedback messages: ACKs, NACKs
   and STATIC-NACKs.  The semantics of each message if defined insection
   5.2.3.1.  [I-D.ietf-rohc-rfc3095bis-framework] What feedback to send



Pelletier & Sandlund     Expires March 10, 2007                [Page 17]

Internet-Draft               ROHCv2 Profiles              September 2006


   is coupled to the context management of the decompressor, i.e. to the
   implementation of the context damage detection algorithms as
   described in Section 5.3.2.

   The decompressor should send a NACK when it assumes context damage,
   and it should send a STATIC-NACK when it assumes static context
   damage.  The decompressor is not strictly expected to send ACK
   feedback upon successful decompression, other than for the purpose of
   improving compression efficiency.

   The decompressor should limit the rate at which it sends feedback ,
   for both ACKs and STATIC-NACK/NACKs, and should avoid sending
   unnecessary duplicates of the same type of feedback message that may
   be associated to the same event.


6.  RoHCv2 Profiles (Normative)

6.1.  Profile Operation, per-context

   RoHCv2 profiles operates differently, per context, depending on how
   the decompressor uses of a feedback channel.  Once the decompressor
   uses the feedback channel for a context, it establishes the feedback
   channel for that CID.

   The compressor always start assuming that the decompressor will not
   send feedback when it initializes a new context (see also , section
   5.1.1.)  [I-D.ietf-rohc-rfc3095bis-framework], i.e. there is no
   established feedback channel for the new context.  There will always
   be a possibility of decompression failure with the optimistic
   approach, because the decompressor may not have received sufficient
   information for correct decompression.  Therefore, until the
   decompressor has established a feedback channel, the compressor
   SHOULD periodically send IR packets.  The periodicity can be based on
   timeouts, on the number of compressed packets sent for the flow, or
   any other strategy the implementer chooses.

   The reception of either positive feedback (ACKs) or negative feedback
   (NACKs) establishes the feedback channel from the decompressor for
   the context (CID) for which the feedback was received.  Once there is
   an established feedback channel for a specific context, the
   compressor can make use of this feedback to estimate the current
   state of the decompressor.  This helps increasing the compression
   efficiency by providing the information needed for the compressor to
   achieve the necessary confidence level.  When the feedback channel is
   established, it becomes superfluous for the compressor to send
   periodic refreshes, and instead it can rely entirely on the
   optimistic approach and feedback from the decompressor.



Pelletier & Sandlund     Expires March 10, 2007                [Page 18]

Internet-Draft               ROHCv2 Profiles              September 2006


   The decompressor MAY send positive feedback (ACKs) to initially
   establish the feedback channel for a particular flow.  Either
   positive feedback (ACKs) or negative feedback (NACKs) establishes
   this channel.  The decompressor is REQUIRED to continue sending
   feedback once it has established a feedback channel for a CID, for
   the lifetime of the context, i.e. until the CID is associated with a
   different profile from the reception of an IR packet, to send error
   recovery requests and (optionally) acknowledgments of significant
   context updates.

   Due to the periodic refreshes and the lack of feedback for initiation
   of error recovery, compression without an established feedback
   channel will be less efficient and have a slightly higher probability
   of loss propagation compared to the decompressor making use of
   feedback.

6.2.  Control Fields

   RoHCv2 defines a number of control fields that are used by the
   decompressor in its interpretation of the packet formats received
   from the compressor.

   A control field is a field that is transmitted from the compressor to
   the decompressor, but is not part of the uncompressed header.  Values
   for control fields can be set up in the context of both the
   compressor and the decompressor.  Once established at the
   decompressor, the values of these fields MUST be kept until updated
   by another packet.

6.2.1.  Master Sequence Number (MSN)

   The Master Sequence Number (MSN) field is either taken from a field
   that already exists in each of the headers of the protocol that the
   profile compresses (e.g.  RTP SN), or alternatively it is created at
   the compressor.

   The MSN field has the following two functions:

   o  Differentiating between packets when sending feedback data.
   o  Inferring the value of incrementing fields (e.g.  IPv4
      Identifier).

   The MSN field is present in every packet sent by the compressor.  The
   MSN is sent in full in IR and IR-DYN packets, while it is sent LSB
   encoded within CO header formats.  The decompressor always sends the
   MSN as part of the feedback information.  The compressor can later
   use the MSN to infer which packet the decompressor is acknowledging.




Pelletier & Sandlund     Expires March 10, 2007                [Page 19]

Internet-Draft               ROHCv2 Profiles              September 2006


   When the MSN is initialized, it is initialized to a random value.
   The compressor should only initialize a new MSN for the initial IR
   packet sent for a new context, i.e. for a CID that corresponds to a
   context that is not already associated with the profile used in the
   IR header.  In other words, if the compressor reuses the same CID
   with the same profile to compress many flows one after the other, the
   MSN is not reinitialized but rather continues to increment
   monotonically.

   For profiles for which the MSN is created by the compressor, the
   following rules applies:

   o  The compressor should only initialize a new MSN for the initial IR
      sent for a CID that corresponds to a context that is not already
      associated with this profile;
   o  When the MSN is initialized, it is initialized to a random value;
   o  The value of the MSN is incremented by one for each packet that
      the compressor sends.

6.2.2.  IP-ID behavior

   The IP-ID field of the IPv4 header can have different change
   patterns: sequential in network byte order, sequential byte-swapped,
   random and constant (a constant value of zero, although not
   conformant with [RFC0791], as been observed in practice).The control
   field for the IP-ID behavior determines which set of packet formats
   will be used.  Note that these control fields are also used to
   determine the contents of the irregular chain item for each IP
   header.

   If more than one level of IP headers is present, RoHCv2 profiles can
   assign a sequential behavior (network byte order or byte-swapped)
   only to the IP-ID of innermost IP header.  This is because only this
   IP-ID can possibly have a sufficiently close correlation with the MSN
   to compress it as a sequentially changing field.  Therefore, a
   compressor MUST assign either the constant zero IP-ID or the random
   IP-ID behavior to tunneling headers.

6.3.  Reconstruction and Verification

   The CRC carried within compressed headers MUST be used to verify
   decompression.  When the decompression is verified and successful,
   the decompressor updates the context with the information received in
   the current header; otherwise if the reconstructed header fails the
   CRC verification, these updates MUST NOT be performed.

   A packet for which the decompression attempt cannot be verified using
   the CRC MUST NOT be delivered to upper layers.



Pelletier & Sandlund     Expires March 10, 2007                [Page 20]

Internet-Draft               ROHCv2 Profiles              September 2006


   Note: Decompressor implementations may attempt corrective or repair
   measures prior to performing the above actions, and the result of any
   decompression attempt MUST be verified using the CRC.

6.4.  Compressed Header Chains

   Some packet types use one or more chains containing sub-header
   information.  The function of a chain is to group fields based on
   similar characteristics, such as static, dynamic or irregular fields.

   Chaining is done by appending an item for each header to the chain in
   their order of appearance in the uncompressed packet, starting from
   the fields in the outermost header.

   Static chain:

      The static chain consists of one item for each header of the chain
      of protocol headers to be compressed, starting from the outermost
      IP header.  In the formal description of the packet formats, this
      static chain item for each header type is labelled
      <protocol_name>_static.  The static chain is only used in IR
      packets.


   Dynamic chain:

      The dynamic chain consists of one item for each header of the
      chain of protocol headers to be compressed, starting from the
      outermost IP header.  In the formal description of the packet
      formats, the dynamic chain item for each header type is labelled
      <protocol_name>_dynamic.  The dynamic chain is used both in IR and
      IR-DYN packet


   Irregular chain:

      The structure of the irregular chain is analogous to the structure
      of the static chain.  For each compressed packet, the irregular
      chain is appended at the specified location in the general format
      of the compressed packets as defined in Section 6.6.  The
      irregular chain is used for all CO packets.
      The format of the irregular chain for the innermost IP header
      differs from the format of the one for the outer IP headers, since
      this header is part of the compressed base header.  What irregular
      chain items to use is determined by the argument "is_innermost",
      which is passed as an argument to the corresponding encoding
      method (ipv4 or ipv6).  The format of the irregular chain item for
      the outer IP headers is also determined using one flag for TTL/Hop



Pelletier & Sandlund     Expires March 10, 2007                [Page 21]

Internet-Draft               ROHCv2 Profiles              September 2006


      Limit and one for TOS/TC.  These flags are defined in the format
      of some of the compressed base headers.
   RoHCv2 profiles compresses extension headers as other headers, and
   thus extension headers have a static chain, a dynamic chain and an
   irregular chain.

   Chains are defined for all headers compressed by RoHCv2 profiles,
   i.e.  RTP [RFC3550], UDP [RFC0768], UDP Lite [RFC3828], IPv4
   [RFC0791], IPv6 [RFC2460], AH [RFC4302], GRE [RFC2784][RFC2890], MINE
   [RFC2004], NULL-encrupted ESP [RFC4303], IPv6 Destination Options
   header[RFC2460], IPv6 Hop-by-hop Options header[RFC2460] and IPv6
   Routing header [RFC2460].

6.5.  Packet Formats and Encoding Methods

   The packet formats used for are defined using the ROHC formal
   notation.  Some of the encoding methods used in the packet formats
   are defined in [I-D.ietf-rohc-formal-notation], while other methods
   are defined in this section.

6.5.1.  baseheader_extension_headers

   In CO packets (see Section 6.6.4), the innermost IP header can be
   combined with other header(s) (i.e.  UDP, UDP Lite, RTP) to create
   the compressed base header.  In such case, the IP header may have a
   number of extension headers between itself and the other headers.

   The base header defines some representation of these extension
   headers, to comply with the syntax of the formal notation; this
   encoding method provides this representation.  The
   baseheader_extension_headers encoding method skips over all fields of
   the extension headers of the innermost IP header, without encoding
   any of the them.  Fields in these extension headers are instead
   encoded in the irregular chain.

6.5.2.  baseheader_outer_headers

   This encoding method, similarly to the baseheader_extension_headers
   encoding method above, is needed to keep the definition of the packet
   formats syntactically correct.  It describe tunneling IP headers and
   their respective extension headers (i.e. all headers located before
   the innermost IP header) for CO headers (see Section 6.6.4).  The
   baseheader_outer_headers encoding method skips over all the fields of
   the extension header(s) that do not belong to the innermost IP
   header, without encoding any of them.  Changed fields in outer
   headers are instead handled by the irregular chain.





Pelletier & Sandlund     Expires March 10, 2007                [Page 22]

Internet-Draft               ROHCv2 Profiles              September 2006


6.5.3.  inferred_udp_length

   The UDP length field is inferred by the decompressor to be the size
   of the UDP payload.  This also means that the compressor MUST make
   sure that the UDP length field is consistent with the length field(s)
   of preceeding subheaders, i.e., there must not be any padding after
   the UDP payload that is covered by the IP Length.

6.5.4.  inferred_ip_v4_header_checksum

   This encoding method compresses the header checksum field of the IPv4
   header.  This checksum is defined in RFC 791 [RFC0791] as follows:

      Header Checksum: 16 bits

         A checksum on the header only.  Since some header fields change
         (e.g., time to live), this is recomputed and verified at each
         point that the internet header is processed.

      The checksum algorithm is:

         The checksum field is the 16 bit one's complement of the one's
         complement sum of all 16 bit words in the header.  For purposes
         of computing the checksum, the value of the checksum field is
         zero.

   As described above, the header checksum protects individual hops from
   processing a corrupted header.  When almost all IP header information
   is compressed away, and when decompression is verified by a CRC
   computed over the original header for every compressed packet, there
   is no point in having this additional checksum; instead it can be
   recomputed at the decompressor side.

   The "inferred_ip_v4_header_checksum" encoding method thus compresses
   the IPv4 header checksum down to a size of zero bit, i.e. no bits are
   transmitted in compressed headers for this field.  Using this
   encoding method, the decompressor infers the value of this field
   using the computation above.

   The compressor MAY use the header checksum to validate the
   correctness of the header before compressing it, to avoid compressing
   a corrupted header.

6.5.5.  inferred_mine_header_checksum

   This encoding method compresses the minimal encapsulation header
   checksum.  This checksum is defined in RFC 2004 [RFC2004] as follows:




Pelletier & Sandlund     Expires March 10, 2007                [Page 23]

Internet-Draft               ROHCv2 Profiles              September 2006


      Header Checksum

         The 16-bit one's complement of the one's complement sum of all
         16-bit words in the minimal forwarding header.  For purposes of
         computing the checksum, the value of the checksum field is 0.
         The IP header and IP payload (after the minimal forwarding
         header) are not included in this checksum computation.

   The "inferred_mine_header_checksum" encoding method compresses the
   minimal encapsulation header checksum down to a size of zero bit,
   i.e. no bits are transmitted in compressed headers for this field.
   Using this encoding method, the decompressor infers the value of this
   field using the above computation.

   The motivations for inferring this checksum are similar to the ones
   explained above in Section 6.5.4.

   The compressor MAY use the minimal encapsulation header checksum to
   validate the correctness of the header before compressing it, to
   avoid compressing a corrupted header.

6.5.6.  inferred_ip_v4_length

   This encoding method compresses the total length field of the IPv4
   header.  The total length field of the IPv4 header is defined in RFC
   791 [RFC0791] as follows:

      Total Length: 16 bits

         Total Length is the length of the datagram, measured in octets,
         including internet header and data.  This field allows the
         length of a datagram to be up to 65,535 octets.

   The "inferred_ip_v4_length" encoding method compresses the IPv4
   header checksum down to a size of zero bit, i.e. no bits are
   transmitted in compressed headers for this field.  Using this
   encoding method, the decompressor infers the value of this field by
   counting in octets the length of the entire packet after
   decompression.

6.5.7.  inferred_ip_v6_length

   This encoding method compresses the payload length field in the IPv6
   header.  This length field is defined in RFC 2460 [RFC2460] as
   follows:






Pelletier & Sandlund     Expires March 10, 2007                [Page 24]

Internet-Draft               ROHCv2 Profiles              September 2006


      Payload Length: 16-bit unsigned integer

         Length of the IPv6 payload, i.e., the rest of the packet
         following this IPv6 header, in octets.  (Note that any
         extension headers present are considered part of the payload,
         i.e., included in the length count.)

   The "inferred_ip_v6_length" encoding method compresses the payload
   length field of the IPv6 header down to a size of zero bit, i.e. no
   bits are transmitted in compressed headers for this field.  Using
   this encoding method, the decompressor infers the value of this field
   by counting in octets the length of the entire packet after
   decompression.

6.5.8.  Scaled RTP Timestamp Encoding

   The RTP timestamp usually increases by a multiple of the RTP Sequence
   Number's increase and is therefore a suitable candidate for scaled
   encoding.  The scaling factor is decided by the compressor by
   observing the increase in Timestamp compared to the RTP Sequence
   Number.  This scaling factor is labeled ts_stride in the definition
   of the profile in ROHC-FNSection 6.6.

   For the compressor to use the scaled timestamps, it MUST first
   explicitly transmit the value of ts_stride to the decompressor, using
   one of the packet types that can carry this information.  Once the
   value of the scaling factor is established, before using this scaled
   encoding the compressor must have enough confidence that the
   decompressor has successfully calculated the residue (ts_offset) of
   the scaling function for the timestamp.  This is done by sending
   unscaled timestamp values to allow the compressor to establish the
   residue based on the ts_stride established.

   Once the compressor has gained enough confidence that both the value
   of the scaling factor and the value of the residue have been
   established in the decompressor, the compressor can start compressing
   packets using the scaled representation of the timestamp.  The
   compressor MUST NOT use the scaled timestamp encoding with the value
   of the ts_stride is set to zero.

   If the compressor notices that the residue (ts_offset) value changes,
   the compressor cannot use scaled timestamp packet formats until it
   has re-established the residue as described above.

   When the value of the timestamp field wraps around, the value of the
   residue of the scaling function is likely to change.  When this
   occurs, the compressor re-establishes the new residue value, e.g.
   using the unscaled representation of the field as described above.



Pelletier & Sandlund     Expires March 10, 2007                [Page 25]

Internet-Draft               ROHCv2 Profiles              September 2006


   The compressor MAY use the scaled timestamp encoding; what value it
   will use as the scaling factor is up to the compressor
   implementation, but to achive any gains from the scaling, the
   ts_stride should be set to the value of the expected incease in
   timestamp between consecutive sequence numbers.

   When scaled timestamp encoding is used for packet formats that do not
   transmit any LSB-encoded timestamp bits at all, the Section 6.5.9 is
   used for encoding the timestamp.

6.5.9.  inferred_scaled_field

   The "inferred_scaled_field" encoding method is used to encode a field
   that is defined as changing in relation to the MSN but for each
   increase is scaled by an established scaling factor.  This encoding
   method is to be used in the case when a packet format contains MSN
   bits, but does not contain any bits for the scaled field.  In this
   case, the new value for the field being scaled is calculated
   according to the following formula:
      unscaled_value = delta_msn * stride + previous_unscaled_value
   Where "delta_msn" is the difference is MSN between the previous value
   of MSN in the context and the value of the MSN decompressed from this
   packet, "previous_unscaled_value" is the value of the field being
   scaled in the context, and "stride" is the scaling value for this
   field.

   For example, when this encoding method is applied to the RTP
   timestamp in the RTP profile, the calculation above becomes:
      timestamp = delta_msn * ts_stride + previous_timestamp

6.5.10.  control_crc3

   Some control fields that can be transmit by the co_common packet type
   of each profile might not be used when decompressing this packet, and
   therefore will not be covered by the included 7-bit CRC.  If such a
   control field has been corrupted on the link between compressor and
   decompressor, the decompressor might send an ACK for this packet
   which would be interpreted by the compressor as if the control fields
   included in this packet were successfully decompressed.  To avoid
   such a situation, an additional 3-bit CRC is included in the
   co_common packets.

   This 3-bit CRC uses the same polynomial as the crc3 encoding method
   defined in the formal notation, but has a different coverage.  This
   CRC should be calculated over the following field, in the order that
   they are listed below:





Pelletier & Sandlund     Expires March 10, 2007                [Page 26]

Internet-Draft               ROHCv2 Profiles              September 2006


   o  reorder_ratio, padded by 6 MSB of zeroes
   o  ts_stride, 16 bits (if applicable for this profile)

6.5.11.  inferred_sequential_ip_id

   This encoding method is used when a sequential IP-ID behavior is used
   (sequential or sequential byte-swapped) and no coded IP-ID bits are
   present in the compressed header.  When these packet types are used,
   the IP-ID offset from the MSN will be constant, and therefore, the
   IP-ID will increase by the same amount as the MSN increases by
   (similar to the inferred_scaled_field encoding method).

   Therefore, the new value for the IP-ID is calculated according to the
   following formula:
      IP-ID = delta_msn + previous_IP_ID_value
   Where "delta_msn" is the difference is MSN between the previous value
   of MSN in the context and the value of the MSN decompressed from this
   packet, "previous_IP_ID_value" is the value of the IP-ID in the
   context.

   If the IP-ID behavior is random or zero, this encoding method does
   not update any fields.

6.5.12.  list_csrc(cc_value)

   This encoding method describes how the list of CSRC identifiers can
   be compressed using list compression.  This list compression operates
   by establishing content for the different CSRC identifiers (items)
   and list describing the order that they appear.

   The argument to this encoding method (cc_value) is the CC field from
   the RTP header which the compressor passes to this encoding method.
   The decompressor is reuired to bind the value of this argument to the
   number of items in the list, which will allow the decompressor to
   corectly reconstruct the CC field.

6.5.12.1.  List Compression

   The CSRC identifiers in the uncompressed packet can be represented as
   an ordered list, whose order and presence are usually constant
   between packets.  The generic structure of such a list is as follows:

            +--------+--------+--...--+--------+
      list: | item 1 | item 2 |       | item n |
            +--------+--------+--...--+--------+

   When performing list compression on a CSRC list, each item is the
   uncompressed value of one CSRC identifier.



Pelletier & Sandlund     Expires March 10, 2007                [Page 27]

Internet-Draft               ROHCv2 Profiles              September 2006


   The basic principles of list-based compression are the following:

      1) When a context is being initialized, a complete representation
      of the compressed list of options is transmitted.  All items that
      have any content are present in the compressed list of items sent
      by the compressor.

   Then, once the context has been initialized:

      2) When the structure of the list is unchanged no information
      about the list is sent in compressed headers.
      3) When the structure of the list changes, a compressed list is
      sent in the compressed header, including a representation of its
      structure and order.  Previously unknown items are sent
      uncompressed in the list, while previously known items are only
      represented by an index pointing to the context.

6.5.12.2.  Table-based Item Compression

   The Table-based item compression compresses individual items sent in
   compressed lists.  The compressor assigns a unique identifier,
   "Index", to each item "Item" of a list.

   Compressor Logic

      The compressor conceptually maintains an Item Table containing all
      items, indexed using "Index".  The (Index, Item) pair is sent
      together in compressed lists until the compressor gains enough
      confidence that the decompressor has observed the mapping between
      items and their respective index.  Confidence is obtained from the
      reception of an acknowledgment from the decompressor, or by
      sending (Index, Item) pairs using the optimistic approach.  Once
      confidence is obtained, the index alone is sent in compressed
      lists to indicate the presence of the item corresponding to this
      index.

      The compressor may reassign an existing index to a new item, by
      re-establishing the mapping using the procedure described above.

   Decompressor Logic

      The decompressor conceptually maintains an Item Table that
      contains all (Index, Item) pairs received.  The Item Table is
      updated whenever an (Index, Item) pair is received and
      decompression is successfully verified using the CRC.  The
      decompressor retrieves the item from the table whenever an Index
      without an accompanying Item is received.




Pelletier & Sandlund     Expires March 10, 2007                [Page 28]

Internet-Draft               ROHCv2 Profiles              September 2006


      If an index without an accompanying item is received and the
      decompressor does not have any context for this index, the packet
      MUST NOT be delivered to upper layers.

6.5.12.3.  Encoding of Compressed Lists

   Each item present in a compressed list is represented by:

   o  an index into the table of items, and
   o  a presence bit indicating if a compressed representation of the
      item is present in the list.
   o  an item (if the presence bit is set)

   If the presence bit is not set, the item must already be known by the
   decompressor.

   A compressed list of items uses the following encoding:

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      | Reserved  |PS |       m       |
      +---+---+---+---+---+---+---+---+
      |        XI_1, ..., XI_m        | m octets, or m * 4 bits
      /                --- --- --- ---/
      |               :    Padding    : if PS = 0 and m is odd
      +---+---+---+---+---+---+---+---+
      |                               |
      /      item_1, ..., item_n      / variable
      |                               |
      +---+---+---+---+---+---+---+---+

      Reserved: Must be set to zero.

      PS: Indicates size of XI fields:
         PS = 0 indicates 4-bit XI fields;
         PS = 1 indicates 8-bit XI fields.

      m: Number of XI item(s) in the compressed list.  Also the value of
      the cc_value argument.

      XI_1, ..., XI_m: m XI items.  Each XI represents one item in the
      list of item of the uncompressed header, in the same order as they
      appear in the uncompressed header.








Pelletier & Sandlund     Expires March 10, 2007                [Page 29]

Internet-Draft               ROHCv2 Profiles              September 2006




         The format of an XI item is as follows:

                 +---+---+---+---+
         PS = 0: | X |   Index   |
                 +---+---+---+---+

                   0   1   2   3   4   5   6   7
                 +---+---+---+---+---+---+---+---+
         PS = 1: | X | Reserved  |     Index     |
                 +---+---+---+---+---+---+---+---+

         X: Indicates whether the item present in the list:

            X = 1 indicates that the item corresponding to the Index is
            sent in the item_1, ..., item_n list;
            X = 0 indicates that the item corresponding to the Index is
            not sent.

         Reserved: Set to zero when sending, ignored when received.

         Index: An index into the item table.  See Section 6.5.12.4


         When 4-bit XI items are used and, the XI items are placed in
         octets in the following manner:

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

      Padding: A 4-bit padding field is present when PS = 0 and the
      number of XIs is odd.  The Padding field is set to zero when
      sending and ignored when receiving.

      Item 1, ..., item n: Each item corresponds to an XI with X = 1 in
      XI 1, ..., XI m.  Each entry in the item list is the uncompressed
      representation of one CSRC identifier.

6.5.12.4.  Item Table Mappings

   The item table for list compression is limited to 16 different items,
   since the RTP header can only carry at most 15 simultaneous CSRC
   identifiers.  The effect of having more than 16 items will only cause
   a slight overhead to the compressor when items are swappen in/out of
   the item table.



Pelletier & Sandlund     Expires March 10, 2007                [Page 30]

Internet-Draft               ROHCv2 Profiles              September 2006


6.5.12.5.  Compressed Lists in Dynamic Chain

   A compressed list that is part of the dynamic chain (e.g. in IR or
   IR-DYN packets) must have all its list items present, i.e. all X-bits
   in the XI list MUST be set.

6.6.  Packet Formats

   ROHCv2 profiles use two different packet types: the Initialization
   and Refresh (IR) packet type, and the Compressed packet type (CO).

   Each packet type defines a number of packet formats: two packet
   formats are defined for the IR type, and two sets base header formats
   are defined for the CO type with one additional format that is common
   to both sets.

   When the number of bits available in compressed header fields exceeds
   the number of bits in the value, the most significant field is padded
   with zeroes in its most significant bits.

   Updating Properties: all packet types carry a CRC and are context
   updating.  Packets update the entire context besides the fields for
   which they explicitly convey information for, since the context can
   be expressed as the collection of the reference value of each field
   together with the function established with respect to the MSN.

6.6.1.  Initialization and Refresh Packet (IR)

   The IR packet format uses the structure of the ROHC IR packet as
   defined in [I-D.ietf-rohc-rfc3095bis-framework], section 5.2.2.1.

   Packet type: IR

      This packet type communicates the static part and the dynamic part
      of the context.
















Pelletier & Sandlund     Expires March 10, 2007                [Page 31]

Internet-Draft               ROHCv2 Profiles              September 2006


   The ROHCv2 IR packet 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   1 | IR type octet
      +---+---+---+---+---+---+---+---+
      :                               :
      /       0-2 octets of CID       / 1-2 octets if for large CIDs
      :                               :
      +---+---+---+---+---+---+---+---+
      |            Profile            | 1 octet
      +---+---+---+---+---+---+---+---+
      |              CRC              | 1 octet
      +---+---+---+---+---+---+---+---+
      |                               |
      /         Static chain          / variable length
      |                               |
       - - - - - - - - - - - - - - - -
      |                               |
      /         Dynamic chain         / variable length
      |                               |
       - - - - - - - - - - - - - - - -
      |                               |
      /            Payload            / variable length
      |                               |
       - - - - - - - - - - - - - - - -

      Static chain: See Section 6.4.


      Dynamic chain: See Section 6.4.


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

6.6.2.  IR  Packet Payload Discard (IR-PD)

   The IR-PD packet format uses the structure of the ROHC IR packet as
   defined in [I-D.ietf-rohc-rfc3095bis-framework], section 5.2.2.1.

   Packet type: IR-PD







Pelletier & Sandlund     Expires March 10, 2007                [Page 32]

Internet-Draft               ROHCv2 Profiles              September 2006


      This packet type communicates the static part and the dynamic part
      of the context, but without the payload of the original packet for
      which it carries the header information.

   The ROHCv2 IR packet 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   0 | IR type octet
      +---+---+---+---+---+---+---+---+
      :                               :
      /       0-2 octets of CID       / 1-2 octets if for large CIDs
      :                               :
      +---+---+---+---+---+---+---+---+
      |            Profile            | 1 octet
      +---+---+---+---+---+---+---+---+
      |              CRC              | 1 octet
      +---+---+---+---+---+---+---+---+
      |                               |
      /         Static chain          / variable length
      |                               |
       - - - - - - - - - - - - - - - -
      |                               |
      /         Dynamic chain         / variable length
      |                               |
       - - - - - - - - - - - - - - - -

      Static chain: See Section 6.4.


      Dynamic chain: See Section 6.4.

6.6.3.  IR Dynamic Packet (IR-DYN)

   The IR-DYN packet format uses the structure of the ROHC IR-DYN packet
   as defined in [I-D.ietf-rohc-rfc3095bis-framework], section 5.2.2.2.

   Packet type: IR-DYN

      This packet type communicates the dynamic chains of the header(s)
      that it compresses.








Pelletier & Sandlund     Expires March 10, 2007                [Page 33]

Internet-Draft               ROHCv2 Profiles              September 2006


   The RoHCv2 IR-DYN packet 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   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
      +---+---+---+---+---+---+---+---+
      |                               |
      /         Dynamic chain         / variable length
      |                               |
       - - - - - - - - - - - - - - - -
      |                               |
      /            Payload            / variable length
      |                               |
       - - - - - - - - - - - - - - - -

      Dynamic chain: See Section 6.4.

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

6.6.4.  Compressed Packet Formats (CO)

6.6.4.1.  Design rationale for compressed base headers

   The compressed packet formats are defined as two separate sets for
   each profile: one set for the packets where the innermost IP header
   contains a sequential IP-ID (either network byte order or byte
   swapped), and one set for the packets without sequential IP-ID
   (either random, zero, or no IP-ID).

   The design of the packet formats is derived from the field behavior
   analysis found in Appendix A.

   All of the compressed base headers transmit LSB-encoded MSN bits and
   a CRC.  In addition, each base header in the sequential packet format
   set contains LSB encoded IP-ID bits.

   The following packet formats exist in both the sequential and random



Pelletier & Sandlund     Expires March 10, 2007                [Page 34]

Internet-Draft               ROHCv2 Profiles              September 2006


   packet format sets:

   o  Format 1: This packet format transmits changes [Author's note:
      TBW]

   o  Format 2: This packet format transmits changes [Author's note:
      TBW]

   o  Common packet format: The common packet format can be used
      indenpendently of the type of IP-ID behavior.  It should also be
      useful when some of the more rarely changing fields in the IP
      header changes.  Since this packet format modify the value of the
      control fields that determine how the decompressor interprets
      different compressed header format, it carries a 7-bit CRC to
      reduce the probability of context corruption.  This packet can
      change most of the dynamic fields in the IP header, and it uses a
      large set of flags to provide information about which fields are
      present in the packet format.

6.6.4.2.  General CO Header Format

   The CO packets communicate irregularities in the packet header.  All
   CO packets carry a CRC and can update the context.

   The general format for a compressed header is as follows:
     0   1   2   3   4   5   6   7
    --- --- --- --- --- --- --- ---
   :         Add-CID octet         : if for small CIDs and CID 1-15
   +---+---+---+---+---+---+---+---+
   |  first octet of base header   | (with type indication)
   +---+---+---+---+---+---+---+---+
   :                               :
   /   0, 1, or 2 octets of CID    / 1-2 octets if large CIDs
   :                               :
   +---+---+---+---+---+---+---+---+
   /   remainder of base header    / variable number of octets
   +---+---+---+---+---+---+---+---+
   :                               :
   /        Irregular Chain        / variable
   :                               :
    --- --- --- --- --- --- --- ---

   The base header in the figure above is the compressed representation
   of the innermost IP header and other header(s), if any, in the
   uncompressed packet.

   Upon receiving other types of packet, the decompressor will
   decompress it.  The decompressor MUST verify the correctness of the



Pelletier & Sandlund     Expires March 10, 2007                [Page 35]

Internet-Draft               ROHCv2 Profiles              September 2006


   decompressed packet by CRC check.  If this verification succeeds, the
   decompressor passes the decompressed packet to the system's network
   layer.  The decompressor will then use this packet as the reference
   packet.

   The entire set of base headers are described in the remainder of this
   section.

   ////////////////////////////////////////////
   // Constants
   ////////////////////////////////////////////

   // IP-ID behavior constants
   IP_ID_BEHAVIOR_SEQUENTIAL         = 0;
   IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED = 1;
   IP_ID_BEHAVIOR_RANDOM             = 2;
   IP_ID_BEHAVIOR_ZERO               = 3;

   // UDP-lite checksum coverage behavior constants
   UDP_LITE_COVERAGE_INFERRED  = 0;
   UDP_LITE_COVERAGE_STATIC    = 1;
   UDP_LITE_COVERAGE_IRREGULAR = 2;
   UDP_LITE_COVERAGE_RESERVED  = 3;

   // Variable reordering offset
   REORDERING_NONE          = 0;
   REORDERING_QUARTER       = 1;
   REORDERING_HALF          = 2;
   REORDERING_THREEQUARTERS = 3;

   // Profile names and versions
   PROFILE_RTP_0101     = 1;
   PROFILE_UDP_0102     = 2;
   PROFILE_ESP_0103     = 3;
   PROFILE_IP_0104      = 4;
   PROFILE_RTP_0107     = 7; // With UDP-LITE
   PROFILE_UDPLITE_0108 = 8; // Without RTP

   ////////////////////////////////////////////
   // Global control fields
   ////////////////////////////////////////////

   CONTROL {
     msn                 [ 16 ];
     reorder_ratio       [  2 ];
   }

   ///////////////////////////////////////////////



Pelletier & Sandlund     Expires March 10, 2007                [Page 36]

Internet-Draft               ROHCv2 Profiles              September 2006


   // Encoding methods not specified in FN syntax:
   ///////////////////////////////////////////////

   baseheader_extension_headers   "defined in Section X.Y.Z";
   baseheader_outer_headers       "defined in Section X.Y.Z";
   inferred_udp_length            "defined in Section X.Y.Z";
   inferred_ip_v4_header_checksum "defined in Section X.Y.Z";
   inferred_mine_header_checksum  "defined in Section X.Y.Z";
   inferred_ip_v4_length          "defined in Section X.Y.Z";
   inferred_ip_v6_length          "defined in Section X.Y.Z";
   list_csrc(cc_value)            "defined in Section X.Y.Z";
   inferred_scaled_field          "defined in Section X.Y.Z";
   inferred_sequential_ip_id      "defined in Section X.Y.Z";
   control_crc3                   "defined in Section X.Y.Z";

   ////////////////////////////////////////////
   // General encoding methods
   ////////////////////////////////////////////

   reorder_ratio_choice
   {
     UNCOMPRESSED {
       ratio [ 2 ];
     }

     DEFAULT {
       ratio =:= irregular(2);
     }

     COMPRESSED none {
       ratio [ 2 ];
       ENFORCE(ratio.UVALUE == REORDERING_NONE);
     }

     COMPRESSED quarter {
       ratio [ 2 ];
       ENFORCE(ratio.UVALUE == REORDERING_QUARTER);
     }

     COMPRESSED half {
       ratio [ 2 ];
       ENFORCE(ratio.UVALUE == REORDERING_HALF);
     }

     COMPRESSED three_quarters {
       ratio [ 2 ];
       ENFORCE(ratio.UVALUE == REORDERING_THREEQUARTERS);
     }



Pelletier & Sandlund     Expires March 10, 2007                [Page 37]

Internet-Draft               ROHCv2 Profiles              September 2006


   }

   static_or_irreg(flag, width)
   {
     UNCOMPRESSED {
       field [ width ];
     }

     COMPRESSED irreg_enc {
       field =:= irregular(width) [ width ];
       ENFORCE(flag == 1);
     }

     COMPRESSED static_enc {
       field =:= static [ 0 ];
       ENFORCE(flag == 0);
     }
   }

   optional32(flag)
   {
     UNCOMPRESSED {
       item [ 0, 32 ];
     }

     COMPRESSED present {
       item =:= irregular(32) [ 32 ];
       ENFORCE(flag == 1);
     }

     COMPRESSED not_present {
       item =:= compressed_value(0, 0) [ 0 ];
       ENFORCE(flag == 0);
     }
   }

   // Self-describing variable length encoding
   sdvl(field_width)
   {
     UNCOMPRESSED {
       field [ field_width ];
     }

     COMPRESSED lsb7 {
       discriminator =:= '0' [ 1 ];
       field =:= lsb(7, 63)  [ 7 ];
     }




Pelletier & Sandlund     Expires March 10, 2007                [Page 38]

Internet-Draft               ROHCv2 Profiles              September 2006


     COMPRESSED lsb14 {
       discriminator =:= '10'   [ 2 ];
       field =:= lsb(14, 16383) [ 14 ];
     }

     COMPRESSED lsb21 {
       discriminator =:= '110'  [ 3 ];
       field =:= lsb(21, 65535) [ 21 ];
     }

     COMPRESSED lsb29 {
       discriminator =:= '110'  [ 3 ];
       field =:= lsb(29, 65535) [ 29 ];
     }
   }

   optional_stride(flag, value)
   {
     UNCOMPRESSED {
       field [ 32 ];
     }

     COMPRESSED present {
       field =:= sdvl(32);
       ENFORCE(flag == 1);
     }

     COMPRESSED not_present {
       field =:= static;
       ENFORCE(flag == 0);
     }
   }

   optional_scaled_timestamp(tss_flag, tsc_flag)
   {
     UNCOMPRESSED {
       timestamp [ 32 ];
     }

     COMPRESSED present {
       timestamp =:= sdvl(32);
       ENFORCE((tss_flag == 0) && (tsc_flag == 1));
     }

     COMPRESSED not_present {
       ENFORCE(((tss_flag == 1) && (tsc_flag == 0)) ||
               ((tss_flag == 0) && (tsc_flag == 0)));
     }



Pelletier & Sandlund     Expires March 10, 2007                [Page 39]

Internet-Draft               ROHCv2 Profiles              September 2006


   }

   optional_unscaled_timestamp(tss_flag, tsc_flag)
   {
     UNCOMPRESSED {
       timestamp [ 32 ];
     }

     COMPRESSED present {
       timestamp =:= sdvl(32);
       ENFORCE(((tss_flag == 1) && (tsc_flag == 0)) ||
               ((tss_flag == 0) && (tsc_flag == 0)));
     }

     COMPRESSED not_present {
       ENFORCE((tss_flag == 0) && (tsc_flag == 1));
     }
   }

   lsb_7_or_31
   {
     UNCOMPRESSED {
       item [ 32 ];
     }

     COMPRESSED lsb_7 {
       discriminator =:= '0'       [ 1 ];
       item          =:= lsb(7, 8) [ 7 ];
     }

     COMPRESSED lsb_31 {
       discriminator =:= '1'          [ 1 ];
       item          =:= lsb(31, 256) [ 31 ];
     }
   }

   opt_lsb_7_or_31(flag)
   {
     UNCOMPRESSED {
       item [ 0, 32 ];
     }

     COMPRESSED present {
       item =:= lsb_7_or_31 [ 8, 32 ];
       ENFORCE(flag == 1);
     }

     COMPRESSED not_present {



Pelletier & Sandlund     Expires March 10, 2007                [Page 40]

Internet-Draft               ROHCv2 Profiles              September 2006


       item =:= compressed_value(0, 0) [ 0 ];
       ENFORCE(flag == 0);
     }
   }

   crc3(data_value, data_length)
   {
     UNCOMPRESSED {
     }

     COMPRESSED {
       crc_value =:=
         crc(3, 0x06, 0x07, data_value, data_length) [ 3 ];
     }
   }

   crc7(data_value, data_length)
   {
     UNCOMPRESSED {
     }

     COMPRESSED {
       crc_value =:=
         crc(7, 0x79, 0x7f, data_value, data_length) [ 7 ];
     }
   }

   optional_pt(flag)
   {
     UNCOMPRESSED {
       payload_type [ 7 ];
     }

     COMPRESSED not_present {
       payload_type =:= static [ 0 ];
       ENFORCE(flag == 0);
     }

     COMPRESSED present {
       reserved     =:= compressed_value(1, 0) [ 1 ];
       payload_type =:= irregular(7)           [ 7 ];
       ENFORCE(flag == 1);
     }
   }

   csrc_list_presence(presence, cc_value)
   {
     UNCOMPRESSED {



Pelletier & Sandlund     Expires March 10, 2007                [Page 41]

Internet-Draft               ROHCv2 Profiles              September 2006


       csrc_list;
     }

     COMPRESSED no_list {
       csrc_list =:= static [ 0 ];
       ENFORCE(presence == 0);
     }

     COMPRESSED list_present {
       csrc_list =:= list_csrc(cc_value) [ VARIABLE ];
       ENFORCE(presence == 1);
     }
   }

   // Variable reordering offset used for MSN
   msn_lsb(k)
   {
     UNCOMPRESSED {
       master [ 16 ];
     }

     COMPRESSED none {
       master =:= lsb(k, -1);
       ENFORCE(reorder_ratio.UVALUE == REORDERING_NONE);
     }

     COMPRESSED quarter {
       master =:= lsb(k, ((2^k) / 4) - 1);
       ENFORCE(reorder_ratio.UVALUE == REORDERING_QUARTER);
     }

     COMPRESSED half {
       master =:= lsb(k, ((2^k) / 2) - 1);
       ENFORCE(reorder_ratio.UVALUE == REORDERING_HALF);
     }

     COMPRESSED threequarters {
       master =:= lsb(k, (((2^k) * 3) / 4) - 1);
       ENFORCE(reorder_ratio.UVALUE == REORDERING_THREEQUARTERS);
     }
   }

   // Encoding method for updating a scaled field and its associated
   // control fields. Should be used both when the value is scaled
   // or unscaled in a compressed format.
   field_scaling(stride_value, scaled_value, unscaled_value)
   {
     UNCOMPRESSED {



Pelletier & Sandlund     Expires March 10, 2007                [Page 42]

Internet-Draft               ROHCv2 Profiles              September 2006


       residue_field [ 32 ];
     }

     COMPRESSED no_scaling {
       ENFORCE(stride_value == 0);
       ENFORCE(residue_field.UVALUE == unscaled_value);
       ENFORCE(scaled_value == 0);
     }

     COMPRESSED scaling_used {
       ENFORCE(stride_value != 0);
       ENFORCE(residue_field.UVALUE == (unscaled_value % stride_value));
       ENFORCE(unscaled_value ==
               scaled_value * stride_value + residue_field.UVALUE);
     }
   }

   ////////////////////////////////////////////
   // IPv6 Destination options header
   ////////////////////////////////////////////

   ip_dest_opt
   {
     UNCOMPRESSED {
       next_header [ 8 ];
       length      [ 8 ];
       value       [ VARIABLE ];
     }

     DEFAULT {
       length      =:= static;
       next_header =:= static;
       value       =:= static;
     }

     COMPRESSED dest_opt_static {
       next_header =:= irregular(8) [ 8 ];
       length      =:= irregular(8) [ 8 ];
     }

     COMPRESSED dest_opt_dynamic {
       value =:= irregular(length.UVALUE * 64 + 48) [ VARIABLE ];
     }
   }

   ////////////////////////////////////////////
   // IPv6 Hop-by-Hop options header
   ////////////////////////////////////////////



Pelletier & Sandlund     Expires March 10, 2007                [Page 43]

Internet-Draft               ROHCv2 Profiles              September 2006


   ip_hop_opt
   {
     UNCOMPRESSED {
       next_header [ 8 ];
       length      [ 8 ];
       value       [ VARIABLE ];
     }

     DEFAULT {
       length      =:= static;
       next_header =:= static;
       value       =:= static;
     }

     COMPRESSED hop_opt_static {
       next_header =:= irregular(8) [ 8 ];
       length      =:= irregular(8) [ 8 ];
     }

     COMPRESSED hop_opt_dynamic {
       value =:= irregular(length.UVALUE*64+48) [ VARIABLE ];
     }
   }

   ////////////////////////////////////////////
   // IPv6 Routing header
   ////////////////////////////////////////////

   ip_rout_opt
   {
     UNCOMPRESSED {
       next_header [ 8 ];
       length      [ 8 ];
       value       [ VARIABLE ];
     }

     DEFAULT {
       length      =:= static;
       next_header =:= static;
       value       =:= static;
     }

     COMPRESSED rout_opt_static {
       next_header =:= irregular(8)                   [ 8 ];
       length      =:= irregular(8)                   [ 8 ];
       value       =:= irregular(length.UVALUE*64+48) [ VARIABLE ];
     }




Pelletier & Sandlund     Expires March 10, 2007                [Page 44]

Internet-Draft               ROHCv2 Profiles              September 2006


     COMPRESSED rout_opt_dynamic {
     }
   }

   ////////////////////////////////////////////
   // GRE Header
   ////////////////////////////////////////////

   optional_checksum(flag_value)
   {
     UNCOMPRESSED {
       value     [ 0, 16 ];
       reserved1 [ 0, 16 ];
     }

     COMPRESSED cs_present {
       value     =:= irregular(16)             [ 16 ];
       reserved1 =:= uncompressed_value(16, 0) [ 0 ];
       ENFORCE(flag_value == 1);
     }

     COMPRESSED not_present {
       value     =:= compressed_value(0, 0) [ 0 ];
       reserved1 =:= compressed_value(0, 0) [ 0 ];
       ENFORCE(flag_value == 0);
     }
   }

   gre_proto
   {
     UNCOMPRESSED {
       protocol [ 16 ];
     }

     COMPRESSED ether_v4 {
       discriminator =:= compressed_value(1, 0) [ 1 ];
       protocol      =:= uncompressed_value(16, 0x0800);
     }

     COMPRESSED ether_v6 {
       discriminator =:= compressed_value(1, 1) [ 1 ];
       protocol      =:= uncompressed_value(16, 0x86DD);
     }
   }

   gre
   {
     UNCOMPRESSED {



Pelletier & Sandlund     Expires March 10, 2007                [Page 45]

Internet-Draft               ROHCv2 Profiles              September 2006


       c_flag                                 [ 1 ];
       r_flag    =:= uncompressed_value(1, 0) [ 1 ];
       k_flag                                 [ 1 ];
       s_flag                                 [ 1 ];
       reserved0 =:= uncompressed_value(9, 0) [ 9 ];
       version   =:= uncompressed_value(3, 0) [ 3 ];
       protocol                               [ 16 ];
       checksum_and_res                       [ 0, 32 ];
       key                                    [ 0, 32 ];
       sequence_number                        [ 0, 32 ];
     }

     DEFAULT {
       c_flag           =:= static;
       k_flag           =:= static;
       s_flag           =:= static;
       protocol         =:= static;
       key              =:= static;
       sequence_number  =:= static;
     }

     COMPRESSED gre_static {
       protocol =:= gre_proto                 [ 1 ];
       c_flag   =:= irregular(1)              [ 1 ];
       k_flag   =:= irregular(1)              [ 1 ];
       s_flag   =:= irregular(1)              [ 1 ];
       padding  =:= compressed_value(4, 0)    [ 4 ];
       key      =:= optional32(k_flag.UVALUE) [ 0, 32 ];
     }

     COMPRESSED gre_dynamic {
       checksum_and_res =:=
         optional_checksum(c_flag.UVALUE)             [ 0, 16 ];
       sequence_number  =:= optional32(s_flag.UVALUE) [ 0, 32 ];
     }

     COMPRESSED gre_irregular {
       checksum_and_res =:=
         optional_checksum(c_flag.UVALUE) [ 0, 16 ];
       sequence_number  =:=
         opt_lsb_7_or_31(s_flag.UVALUE)   [ 0, 8, 32 ];
     }
   }

   /////////////////////////////////////////////
   // MINE header
   /////////////////////////////////////////////




Pelletier & Sandlund     Expires March 10, 2007                [Page 46]

Internet-Draft               ROHCv2 Profiles              September 2006


   mine
   {
     UNCOMPRESSED {
       next_header [ 8 ];
       s_bit       [ 1 ];
       res_bits    [ 7 ];
       checksum    [ 16 ];
       orig_dest   [ 32 ];
       orig_src    [ 0, 32 ];
     }

     DEFAULT {
       next_header =:= static;
       s_bit       =:= static;
       res_bits    =:= static;
       checksum    =:= inferred_mine_header_checksum;
       orig_dest   =:= static;
       orig_src    =:= static;
     }

     COMPRESSED mine_static {
       next_header =:= irregular(8)             [ 8 ];
       s_bit       =:= irregular(1)             [ 1 ];
       // Reserved are included - no benefit in removing them
       res_bits    =:= irregular(7)             [ 7 ];
       orig_dest   =:= irregular(32)            [ 32 ];
       orig_src    =:= optional32(s_bit.UVALUE) [ 0, 32 ];
     }

     COMPRESSED mine_dynamic {
     }
   }

   /////////////////////////////////////////////
   // Authentication Header (AH)
   /////////////////////////////////////////////

   ah
   {
     UNCOMPRESSED {
       next_header     [ 8 ];
       length          [ 8 ];
       res_bits        [ 16 ];
       spi             [ 32 ];
       sequence_number [ 32 ];
       auth_data       [ VARIABLE ];
     }




Pelletier & Sandlund     Expires March 10, 2007                [Page 47]

Internet-Draft               ROHCv2 Profiles              September 2006


     DEFAULT {
       next_header     =:= static;
       length          =:= static;
       res_bits        =:= static;
       spi             =:= static;
       sequence_number =:= static;
     }

     COMPRESSED ah_static {
       next_header =:= irregular(8)  [ 8 ];
       length      =:= irregular(8)  [ 8 ];
       spi         =:= irregular(32) [ 32 ];
     }

     COMPRESSED ah_dynamic {
       res_bits        =:= irregular(16) [ 16 ];
       sequence_number =:= irregular(32) [ 32 ];
       auth_data       =:=
         irregular(length.UVALUE*32-32)  [ VARIABLE ];
     }

     COMPRESSED ah_irregular {
       sequence_number =:= lsb_7_or_31  [ 8, 32 ];
       auth_data       =:=
         irregular(length.UVALUE*32-32) [ VARIABLE ];
     }
   }

   /////////////////////////////////////////////
   // ESP header (NULL encrypted)
   /////////////////////////////////////////////

   // Since the "next header" field is located in the packet trailer
   // and ROHC-FN requires all UNCOMPRESSED fields to be contiguous,
   // the values of the next header field is passed as a parameter.
   // To avoid forcing the decompression to access the trailer part of
   // the packet, the next header is istead handled with a control field
   esp_null(next_header_value)
   {
     UNCOMPRESSED {
       spi             [ 32 ];
       sequence_number [ 32 ];
     }

     CONTROL {
       nh_field [ 8 ];
     }




Pelletier & Sandlund     Expires March 10, 2007                [Page 48]

Internet-Draft               ROHCv2 Profiles              September 2006


     DEFAULT {
       spi             =:= static;
       sequence_number =:= static;
       nh_field        =:= static;
     }

     COMPRESSED esp_static {
       nh_field =:= compressed_value(8, next_header_value) [ 8 ];
       spi      =:= irregular(32)                          [ 32 ];
     }

     COMPRESSED esp_dynamic {
       sequence_number =:= irregular(32) [ 32 ];
     }

     COMPRESSED esp_irregular {
       sequence_number =:= lsb_7_or_31 [ 8, 32 ];
     }
   }

   /////////////////////////////////////////////
   // IPv6 Header
   /////////////////////////////////////////////

   fl_enc
   {
     UNCOMPRESSED {
       flow_label [ 20 ];
     }

     COMPRESSED fl_zero {
       discriminator =:= '0'                       [ 1 ];
       flow_label    =:= uncompressed_value(20, 0) [ 0 ];
       reserved      =:= '0000'                    [ 4 ];
     }

     COMPRESSED fl_non_zero {
       discriminator =:= '1'           [ 1 ];
       flow_label    =:= irregular(20) [ 20 ];
     }
   }

   // The is_innermost flag should be true if this is the innermost
   // IP header to be compressed.
   // If extracting the irregular chain for an compressed packet,
   // the TTL&TOS arguments must have the same value as it had when
   // processing co_baseheader. If extracting any other chain
   // items, this argument is not used.



Pelletier & Sandlund     Expires March 10, 2007                [Page 49]

Internet-Draft               ROHCv2 Profiles              September 2006


   ipv6(profile, is_innermost,
        ttl_irregular_chain_flag, tos_irregular_chain_flag)
   {
     UNCOMPRESSED {
       version         =:= uncompressed_value(4, 6) [ 4 ];
       tos_tc                                       [ 8 ];
       flow_label                                   [ 20 ];
       payload_length                               [ 16 ];
       next_header                                  [ 8 ];
       ttl_hopl                                     [ 8 ];
       src_addr                                     [ 128 ];
       dst_addr                                     [ 128 ];
     }

     DEFAULT {
       tos_tc         =:= static;
       flow_label     =:= static;
       payload_length =:= inferred_ip_v6_length;
       next_header    =:= static;
       ttl_hopl       =:= static;
       src_addr       =:= static;
       dst_addr       =:= static;
     }

     COMPRESSED ipv6_static {
       version_flag =:= '1'            [ 1 ];
       reserved     =:= '00'           [ 2 ];
       flow_label   =:= fl_enc         [ 5, 21 ];
       next_header  =:= irregular(8)   [ 8 ];
       src_addr     =:= irregular(128) [ 128 ];
       dst_addr     =:= irregular(128) [ 128 ];
     }

     COMPRESSED ipv6_endpoint_dynamic {
       tos_tc        =:= irregular(8)           [ 8 ];
       ttl_hopl      =:= irregular(8)           [ 8 ];
       reserved      =:= compressed_value(6, 0) [ 6 ];
       reorder_ratio =:= reorder_choice         [ 2 ];
       ENFORCE((is_innermost == true) &&
               (profile == PROFILE_IP_0104));
     }

     COMPRESSED ipv6_regular_dynamic {
       tos_tc       =:= irregular(8) [ 8 ];
       ttl_hopl     =:= irregular(8) [ 8 ];
       ENFORCE((is_innermost == false) ||
               (profile != PROFILE_IP_0104));
     }



Pelletier & Sandlund     Expires March 10, 2007                [Page 50]

Internet-Draft               ROHCv2 Profiles              September 2006


     COMPRESSED ipv6_outer_irregular {
       tos_tc       =:=
           static_or_irreg(tos_irregular_chain_flag) [ 0, 8 ];
       ttl_hopl     =:=
           static_or_irreg(ttl_irregular_chain_flag) [ 0, 8 ];
       ENFORCE(is_innermost == false);
     }

     COMPRESSED ipv6_innermost_irregular {
       ENFORCE(is_innermost == true);
     }
   }

   /////////////////////////////////////////////
   // IPv4 Header
   /////////////////////////////////////////////

   ip_id_enc_dyn(behavior)
   {
     UNCOMPRESSED {
       ip_id [ 16 ];
     }

     COMPRESSED ip_id_seq {
       ip_id =:= irregular(16) [ 16 ];
       ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
               (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED) ||
               (behavior == IP_ID_BEHAVIOR_RANDOM));
     }

     COMPRESSED ip_id_zero {
       ip_id =:= uncompressed_value(16, 0) [ 0 ];
       ENFORCE(behavior == IP_ID_BEHAVIOR_ZERO);
     }
   }


   ip_id_enc_irreg(behavior)
   {
     UNCOMPRESSED {
       ip_id [ 16 ];
     }

     COMPRESSED ip_id_seq {
       ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL);
     }

     COMPRESSED ip_id_seq_swapped {



Pelletier & Sandlund     Expires March 10, 2007                [Page 51]

Internet-Draft               ROHCv2 Profiles              September 2006


       ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED);
     }

     COMPRESSED ip_id_rand {
       ip_id =:= irregular(16) [ 16 ];
       ENFORCE(behavior == IP_ID_BEHAVIOR_RANDOM);
     }

     COMPRESSED ip_id_zero {
       ip_id =:= uncompressed_value(16, 0) [ 0 ];
       ENFORCE(behavior == IP_ID_BEHAVIOR_ZERO);
     }
   }

   ip_id_behavior_choice
   {
     UNCOMPRESSED {
       behavior [ 2 ];
     }

     DEFAULT {
       behavior =:= irregular(2);
     }

     COMPRESSED sequential {
       behavior [ 2 ];
       ENFORCE(behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL);
     }

     COMPRESSED sequential_swapped {
       behavior [ 2 ];
       ENFORCE(behavior.UVALUE ==
               IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED);
     }

     COMPRESSED random {
       behavior [ 2 ];
       ENFORCE(behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM);
     }

     COMPRESSED zero {
       behavior [ 2 ];
       ENFORCE(behavior.UVALUE == IP_ID_BEHAVIOR_ZERO);
     }
   }

   // The is_innermost flag should be true if this is the innermost
   // IP header to be compressed.



Pelletier & Sandlund     Expires March 10, 2007                [Page 52]

Internet-Draft               ROHCv2 Profiles              September 2006


   // If extracting the irregular chain for an compressed packet,
   // the TTL&TOS arguments must have the same value as it had when
   // processing co_baseheader. If extracting any other chain
   // items, this argument is not used.
   ipv4(profile, is_innermost,
        ttl_irregular_chain_flag, tos_irregular_chain_flag)
   {
     UNCOMPRESSED {
       version        =:= uncompressed_value(4, 4)  [ 4 ];
       hdr_length     =:= uncompressed_value(4, 5)  [ 4 ];
       tos_tc                                       [ 8 ];
       length                                       [ 16 ];
       ip_id                                        [ 16 ];
       rf             =:= uncompressed_value(1, 0)  [ 1 ];
       df                                           [ 1 ];
       mf             =:= uncompressed_value(1, 0)  [ 1 ];
       frag_offset    =:= uncompressed_value(13, 0) [ 13 ];
       ttl_hopl                                     [ 8 ];
       protocol                                     [ 8 ];
       checksum                                     [ 16 ];
       src_addr                                     [ 32 ];
       dst_addr                                     [ 32 ];
     }

     CONTROL {
       ip_id_behavior [ 2 ];
     }

     DEFAULT {
       tos_tc         =:= static;
       length         =:= inferred_ip_v4_length;
       df             =:= static;
       ttl_hopl       =:= static;
       protocol       =:= static;
       checksum       =:= inferred_ip_v4_header_checksum;
       src_addr       =:= static;
       dst_addr       =:= static;
       ip_id_behavior =:= static;
     }

     COMPRESSED ipv4_static {
       version_flag =:= '0'           [ 1 ];
       reserved     =:= '0000000'     [ 7 ];
       protocol     =:= irregular(8)  [ 8 ];
       src_addr     =:= irregular(32) [ 32 ];
       dst_addr     =:= irregular(32) [ 32 ];
     }




Pelletier & Sandlund     Expires March 10, 2007                [Page 53]

Internet-Draft               ROHCv2 Profiles              September 2006


     COMPRESSED ipv4_endpoint_dynamic {
       reserved       =:= '000'               [ 5 ];
       reorder_ratio =:= reorder_choice       [ 2 ];
       df             =:= irregular(1)        [ 1 ];
       ip_id_behavior =:= ip_id_behavior_choice [ 2 ];
       tos_tc         =:= irregular(8)        [ 8 ];
       ttl_hopl       =:= irregular(8)        [ 8 ];
       ip_id          =:=
         ip_id_enc_dyn(ip_id_behavior.UVALUE) [ 0, 16 ];
       ENFORCE((is_innermost == true) &&
               (profile == PROFILE_IP_0104));
     }

     COMPRESSED ipv4_regular_dynamic {
       reserved       =:= '00000'             [ 5 ];
       df             =:= irregular(1)        [ 1 ];
       ip_id_behavior =:= ip_id_behavior_choice [ 2 ];
       tos_tc         =:= irregular(8)        [ 8 ];
       ttl_hopl       =:= irregular(8)        [ 8 ];
       ip_id          =:=
         ip_id_enc_dyn(ip_id_behavior.UVALUE) [ 0, 16 ];
       ENFORCE((is_innermost == false) ||
               (profile != PROFILE_IP_0104));
     }

     COMPRESSED ipv4_outer_irregular {
       ip_id        =:=
         ip_id_enc_irreg(ip_id_behavior.UVALUE) [ 0, 16 ];
       tos_tc       =:=
           static_or_irreg(tos_irregular_chain_flag) [ 0, 8 ];
       ttl_hopl     =:=
           static_or_irreg(ttl_irregular_chain_flag) [ 0, 8 ];
       ENFORCE(is_innermost == false);
     }

     COMPRESSED ipv4_innermost_irregular {
       ip_id          =:=
         ip_id_enc_irreg(ip_id_behavior.UVALUE) [ 0, 16 ];
       ENFORCE(is_innermost == true);
     }
   }

   /////////////////////////////////////////////
   // UDP Header
   /////////////////////////////////////////////

   udp(profile)
   {



Pelletier & Sandlund     Expires March 10, 2007                [Page 54]

Internet-Draft               ROHCv2 Profiles              September 2006


     UNCOMPRESSED {
       src_port   [ 16 ];
       dst_port   [ 16 ];
       udp_length [ 16 ];
       checksum   [ 16 ];
       ENFORCE((profile == PROFILE_RTP_0101) ||
               (profile == PROFILE_UDP_0102));
     }

     DEFAULT {
       src_port   =:= static;
       dst_port   =:= static;
       udp_length =:= inferred_udp_length;
       checksum   =:= irregular(16);
     }

     COMPRESSED udp_static {
       src_port   =:= irregular(16) [ 16 ];
       dst_port   =:= irregular(16) [ 16 ];
     }

     COMPRESSED udp_endpoint_dynamic {
       checksum [ 16 ];
       msn =:= irregular(16) [ 16 ];
       reserved      =:= uncompressed_value(6, 0);
       reorder_ratio =:= reorder_choice [ 2 ];
       ENFORCE(profile == PROFILE_UDP_0102);
     }

     COMPRESSED udp_regular_dynamic {
       checksum [ 16 ];
     }

     COMPRESSED udp_zero_checksum_irregular {
       ENFORCE(checksum.UVALUE == 0);
       checksum =:= uncompressed_value(16, 0);
     }

     COMPRESSED udp_with_checksum_irregular {
       ENFORCE(checksum.UVALUE == 1);
       checksum [ 16 ];
     }
   }

   /////////////////////////////////////////////
   // RTP Header
   /////////////////////////////////////////////




Pelletier & Sandlund     Expires March 10, 2007                [Page 55]

Internet-Draft               ROHCv2 Profiles              September 2006


   csrc_list_dynchain(presence, cc_value)
   {
     UNCOMPRESSED {
       csrc_list;
     }

     COMPRESSED no_list {
       csrc_list =:= uncompressed_value(0, 0) [ 0 ];
       ENFORCE(cc_value == 0);
       ENFORCE(presence == 0);
     }

     COMPRESSED list_present {
       csrc_list =:= list_csrc(cc_value) [ VARIABLE ];
       ENFORCE(presence == 1);
     }
   }

   rtp(profile, ts_stride_value)
   {
     UNCOMPRESSED {
       rtp_version =:= uncompressed_value(2, 0) [  2 ];
       pad_bit                                  [  1 ];
       extension                                [  1 ];
       cc                                       [  4 ];
       marker                                   [  1 ];
       payload_type                             [  7 ];
       sequence_number                          [ 16 ];
       timestamp                                [ 32 ];
       ssrc                                     [ 32 ];
       csrc_list                                [ VARIABLE ];
       ENFORCE((profile == PROFILE_RTP_0101) ||
               (profile == PROFILE_RTP_0107));
     }

     CONTROL {
       // The ts_stride has an initial UVALUE=1, which means that it
       // can be encoded with 'static' even if it has not been
       // previously established in the context.
       ts_stride                           [ 32 ];
       ts_scaled                           [ 32 ];
       ts_offset =:=
           field_scaling(ts_stride.UVALUE, ts_scaled.UVALUE,
                         timestamp.UVALUE) [ 32 ];
     }

     DEFAULT {
       pad_bit         =:= static;



Pelletier & Sandlund     Expires March 10, 2007                [Page 56]

Internet-Draft               ROHCv2 Profiles              September 2006


       extension       =:= static;
       cc              =:= static;
       marker          =:= static;
       payload_type    =:= static;
       sequence_number =:= static;
       timestamp       =:= static;
       ssrc            =:= static;
       csrc_list       =:= static;
     }

     COMPRESSED rtp_static {
       ssrc            =:= irregular(32)  [ 32 ];
     }

     COMPRESSED rtp_dynamic {
       reserved        =:= compressed_value(1, 0)       [  1 ];
       reorder_ratio   =:= reorder_choice               [  2 ];
       list_present    =:= irregular(1)                 [  1 ];
       tss_indicator   =:= irregular(1)                 [  1 ];
       pad_bit         =:= irregular(1)                 [  1 ];
       extension       =:= irregular(1)                 [  1 ];
       marker          =:= irregular(1)                 [  1 ];
       payload_type    =:= irregular(7)                 [  7 ];
       sequence_number =:= irregular(16)                [ 16 ];
       timestamp       =:= irregular(32)                [ 32 ];
       ts_stride       =:=
           optional_stride(tss_indicator,
                           ts_stride_value)       [ VARIABLE ];
       csrc_list       =:=
           csrc_list_dynchain(list_present, cc.UVALUE)  [ VARIABLE ];
     }

     COMPRESSED rtp_irregular {
     }
   }

   /////////////////////////////////////////////
   // UDP-Lite Header
   /////////////////////////////////////////////

   checksum_coverage_dynchain(behavior)
   {
     UNCOMPRESSED {
       checksum_coverage [ 16 ];
     }

     COMPRESSED inferred_coverage {
       checksum_coverage =:= inferred_udp_length [  0 ];



Pelletier & Sandlund     Expires March 10, 2007                [Page 57]

Internet-Draft               ROHCv2 Profiles              September 2006


       ENFORCE(behavior == UDP_LITE_COVERAGE_INFERRED);
     }

     COMPRESSED static_coverage {
       checksum_coverage =:= irregular(16)       [ 16 ];
       ENFORCE(behavior == UDP_LITE_COVERAGE_STATIC);
     }

     COMPRESSED irregular_coverage {
       checksum_coverage =:= irregular(16)       [ 16 ];
       ENFORCE(behavior == UDP_LITE_COVERAGE_IRREGULAR);
     }
   }

   checksum_coverage_irregular(behavior)
   {
     UNCOMPRESSED {
       checksum_coverage [ 16 ];
     }

     COMPRESSED inferred_coverage {
       checksum_coverage =:= inferred_udp_length [  0 ];
       ENFORCE(behavior == UDP_LITE_COVERAGE_INFERRED);
     }

     COMPRESSED static_coverage {
       checksum_coverage =:= static              [  0 ];
       ENFORCE(behavior == UDP_LITE_COVERAGE_STATIC);
     }

     COMPRESSED irregular_coverage {
       checksum_coverage =:= irregular(16)       [ 16 ];
       ENFORCE(behavior == UDP_LITE_COVERAGE_IRREGULAR);
     }
   }

   udp_lite(profile)
   {
     UNCOMPRESSED {
       src_port          [ 16 ];
       dst_port          [ 16 ];
       checksum_coverage [ 16 ];
       checksum          [ 16 ];
       ENFORCE((profile == PROFILE_RTP_0107) ||
               (profile == PROFILE_UDPLITE_0108));
     }

     CONTROL {



Pelletier & Sandlund     Expires March 10, 2007                [Page 58]

Internet-Draft               ROHCv2 Profiles              September 2006


       coverage_behavior [ 2 ];
     }

     DEFAULT {
       src_port          =:= static;
       dst_port          =:= static;
       checksum_coverage =:= irregular(16);
       checksum          =:= irregular(16);
     }

     COMPRESSED udp_lite_static {
       src_port   =:= irregular(16) [ 16 ];
       dst_port   =:= irregular(16) [ 16 ];
     }

     COMPRESSED udp_lite_endpoint_dynamic {
       reserved =:= compressed_value(4, 0)      [  4 ];
       coverage_behavior =:= irregular(2)       [  2 ];
       reorder_ratio     =:= reorder_choice     [  2 ];
       checksum_coverage =:=
           checksum_coverage_dynchain(coverage_behavior.UVALUE) [ 16 ];
       checksum                                 [ 16 ];
       msn =:= irregular(16)                    [ 16 ];
       ENFORCE(profile == PROFILE_UDPLITE_0108);
     }

     COMPRESSED udp_lite_regular_dynamic {
       coverage_behavior =:= irregular(2)       [  2 ];
       reserved =:= compressed_value(6, 0)      [  6 ];
       checksum_coverage =:=
           checksum_coverage_dynchain(coverage_behavior.UVALUE) [ 16 ];
       checksum                                 [ 16 ];
     }

     COMPRESSED udp_lite_irregular {
       checksum_coverage =:=
        checksum_coverage_dynchain(coverage_behavior.UVALUE) [ 0, 16 ];
       checksum          [ 16 ];
     }
   }

   /////////////////////////////////////////////
   // ESP Header (Non-NULL encrypted
   // i.e. only used for the ESP profile
   /////////////////////////////////////////////

   esp(profile)
   {



Pelletier & Sandlund     Expires March 10, 2007                [Page 59]

Internet-Draft               ROHCv2 Profiles              September 2006


     UNCOMPRESSED {
       spi             [ 32 ];
       sequence_number [ 32 ];
       ENFORCE(profile == PROFILE_ESP_0103);
     }

     DEFAULT {
       spi             =:= static;
       sequence_number =:= static;
     }

     COMPRESSED esp_static {
       spi =:= irregular(32) [ 32 ];
     }

     COMPRESSED esp_dynamic {
       sequence_number =:= irregular(32)             [ 32 ];
       msn             =:= irregular(16)             [ 16 ];
       reserved        =:= uncompressed_value(6, 0)  [  6 ];
       reorder_ratio   =:= reorder_choice            [  2 ];
     }

     COMPRESSED esp_irregular {
     }
   }

   ///////////////////////////////////////////////////
   // Encoding methods used in the profiles' CO packets
   ///////////////////////////////////////////////////

   ip_id_lsb(behavior, k, p)
   {
     UNCOMPRESSED {
       ip_id [ 16 ];
     }

     CONTROL {
       ip_id_offset [ 16 ];
       ip_id_nbo    [ 16 ];
     }

     COMPRESSED nbo {
       ip_id_offset =:= lsb(k, p) [ VARIABLE ];
       ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL);
       ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE);
     }

     COMPRESSED non_nbo {



Pelletier & Sandlund     Expires March 10, 2007                [Page 60]

Internet-Draft               ROHCv2 Profiles              September 2006


       ip_id_offset =:= lsb(k, p) [ VARIABLE ];
       ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED);
       ENFORCE(ip_id_nbo.UVALUE ==
               (ip_id.UVALUE / 256) + (ip_id.UVALUE % 256) * 256);
       ENFORCE(ip_id_nbo.ULENGTH == 16);
       ENFORCE(ip_id_offset.UVALUE == ip_id_nbo.UVALUE - msn.UVALUE);
     }
   }

   optional_ip_id_lsb(behavior, indicator)
   {
     UNCOMPRESSED {
       ip_id [ 16 ];
     }

     COMPRESSED short {
       ip_id =:= ip_id_lsb(behavior, 8, 3) [ 8 ];
       ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
               (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
       ENFORCE(indicator == 0);
     }

     COMPRESSED long {
       ip_id =:= irregular(16)  [ 16 ];
       ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
               (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
       ENFORCE(indicator == 1);
     }

     COMPRESSED not_present {
       ENFORCE((behavior == IP_ID_BEHAVIOR_RANDOM) ||
               (behavior == IP_ID_BEHAVIOR_ZERO));
     }
   }

   dont_fragment(version)
   {
     UNCOMPRESSED {
       df [ 1 ];
     }

     COMPRESSED v4 {
       df =:= irregular(1) [ 1 ];
       ENFORCE(version == 4);
     }

     COMPRESSED v6 {
       df =:= compressed_value(1, 0) [ 1 ];



Pelletier & Sandlund     Expires March 10, 2007                [Page 61]

Internet-Draft               ROHCv2 Profiles              September 2006


       ENFORCE(version == 6);
     }
   }

   ////////////////////////////////////////////
   // RTP profile
   ////////////////////////////////////////////

   // ttl_irregular_chain_flag is set by the user if the TTL/Hop Limit
   // of an outer header. The same value must be passed as an argument
   // to the ipv4/ipv6 encoding methods when extracting the irregular
   // chain items. The same applies to the tos_irregular_chain_flag
   rtp_baseheader(profile, ts_stride_value,
                  ttl_irregular_chain_flag, tos_irregular_chain_flag)
   {
     UNCOMPRESSED v4 {
       outer_headers  =:= baseheader_outer_headers  [ VARIABLE ];
       version        =:= uncompressed_value(4, 4)  [ 4 ];
       header_length  =:= uncompressed_value(4, 5)  [ 4 ];
       tos_tc                                       [ 8 ];
       length                                       [ 16 ];
       ip_id                                        [ 16 ];
       rf             =:= uncompressed_value(1, 0)  [ 1 ];
       df                                           [ 1 ];
       mf             =:= uncompressed_value(1, 0)  [ 1 ];
       frag_offset    =:= uncompressed_value(13, 0) [ 13 ];
       ttl_hopl                                     [ 8 ];
       next_header                                  [ 8 ];
       checksum                                     [ 16 ];
       src_addr                                     [ 32 ];
       dest_addr                                    [ 32 ];
       extension_headers =:= baseheader_extension_headers [ VARIABLE ];
       src_port                                     [ 16 ];
       dst_port                                     [ 16 ];
       udp_length                                   [ 16 ];
       checksum                                     [ 16 ];
       rtp_version =:= uncompressed_value(2, 0)     [  2 ];
       pad_bit                                      [  1 ];
       extension                                    [  1 ];
       cc                                           [  4 ];
       marker                                       [  1 ];
       payload_type                                 [  7 ];
       sequence_number                              [ 16 ];
       timestamp                                    [ 32 ];
       ssrc                                         [ 32 ];
       csrc_list                                    [ VARIABLE ];
       ENFORCE(msn.UVALUE == sequence_number.UVALUE);
     }



Pelletier & Sandlund     Expires March 10, 2007                [Page 62]

Internet-Draft               ROHCv2 Profiles              September 2006


     UNCOMPRESSED v6 {
       outer_headers  =:= baseheader_outer_headers  [ VARIABLE ];
       version =:= uncompressed_value(4, 6)         [ 4 ];
       tos_tc                                       [ 8 ];
       flow_label                                   [ 20 ];
       payload_length                               [ 16 ];
       next_header                                  [ 8 ];
       ttl_hopl                                     [ 8 ];
       src_addr                                     [ 128 ];
       dest_addr                                    [ 128 ];
       extension_headers =:= baseheader_extension_headers [ VARIABLE ];
       src_port                                     [ 16 ];
       dst_port                                     [ 16 ];
       udp_length                                   [ 16 ];
       checksum                                     [ 16 ];
       rtp_version =:= uncompressed_value(2, 0)     [  2 ];
       pad_bit                                      [  1 ];
       extension                                    [  1 ];
       cc                                           [  4 ];
       marker                                       [  1 ];
       payload_type                                 [  7 ];
       sequence_number                              [ 16 ];
       timestamp                                    [ 32 ];
       ssrc                                         [ 32 ];
       csrc_list                                    [ VARIABLE ];
       ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM);
       ENFORCE(msn.UVALUE == sequence_number.UVALUE);
     }

     CONTROL {
       // The ts_stride has an initial UVALUE=1, which means that it
       // can be encoded with 'static' even if it has not been
       // previously established in the context.
       ts_stride                           [ 32 ];
       ts_scaled                           [ 32 ];
       ts_offset =:=
           field_scaling(ts_stride.UVALUE, ts_scaled.UVALUE,
                         timestamp.UVALUE) [ 32 ];
       ip_id_behavior [  2 ];
       ENFORCE(ts_stride.UVALUE == ts_stride_value);
       ENFORCE(profile == PROFILE_RTP_0101);
     }

     DEFAULT {
       tos_tc          =:= static;
       dest_addr       =:= static;
       version         =:= static;
       ttl_hopl        =:= static;



Pelletier & Sandlund     Expires March 10, 2007                [Page 63]

Internet-Draft               ROHCv2 Profiles              September 2006


       src_addr        =:= static;
       df              =:= static;
       ip_id_behavior  =:= static;
       payload_length  =:= inferred_ip_v6_length;
       checksum        =:= inferred_ip_v4_header_checksum;
       length          =:= inferred_ip_v4_length;
       flow_label      =:= static;
       next_header     =:= static;
       src_port        =:= static;
       dst_port        =:= static;
       udp_length      =:= inferred_udp_length;
       checksum        =:= irregular(16);
       pad_bit         =:= static;
       extension       =:= static;
       cc              =:= static;
       // When marker not present in packets, it is assumed 0
       marker          =:= uncompressed_value(1, 0);
       payload_type    =:= static;
       sequence_number =:= static;
       timestamp       =:= static;
       ssrc            =:= static;
       csrc_list       =:= static;

       ENFORCE(ttl_irregular_chain_flag == 0);
       ENFORCE(tos_irregular_chain_flag == 0);
     }

     // Replacement for UOR-2-ext3
     COMPRESSED co_common {
       discriminator        =:= '1111101'               [ 7 ];
       marker               =:= irregular(1)            [ 1 ];
       header_crc   =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       ip_id_indicator      =:= irregular(1)            [ 1 ];
       ip_id_behavior       =:= ip_id_behavior_choice   [ 2 ];
       reorder_ratio        =:= reorder_choice          [ 2 ];
       df           =:= dont_fragment(version.UVALUE)   [ 1 ];
       control_crc3         =:= control_crc3            [ 3 ];
       ttl_hopl_outer_flag  =:= irregular(1)            [ 1 ];
       ttl_hopl_present     =:= irregular(1)            [ 1 ];
       tos_tc_outer_flag    =:= irregular(1)            [ 1 ];
       tos_tc_present       =:= irregular(1)            [ 1 ];
       ts_indicator         =:= irregular(1)            [ 1 ];
       tss_indicator        =:= irregular(1)            [ 1 ];
       pt_present           =:= irregular(1)            [ 1 ];
       list_present         =:= irregular(1)            [ 1 ];
       pad_bit              =:= irregular(1)            [ 1 ];
       extension            =:= irregular(1)            [ 1 ];
       reserved             =:= compressed_value(6, 0)  [ 6 ];



Pelletier & Sandlund     Expires March 10, 2007                [Page 64]

Internet-Draft               ROHCv2 Profiles              September 2006


       ip_id                =:=
         optional_ip_id_lsb(ip_id_behavior.UVALUE,
                            ip_id_indicator.CVALUE) [ 0, 8, 16 ];
       tos_tc               =:=
         tos_tc_enc(tos_tc_present.CVALUE)              [ 0, 8 ];
       ttl_hopl             =:=
         static_or_irreg(ttl_hopl_present.CVALUE,
                         ttl_hopl.ULENGTH)              [ 0, 8 ];
       sequence_number =:= sdvl(sequence_number.ULENGTH) [ 8, 16 ];
       // Either scaled or unscaled timestamp
       ts_scaled            =:=
           optional_scaled_timestamp(tss_indicator,
                                     tsc_indicator)     [ VARIABLE ];
       ts_scaled            =:=
           optional_scaled_timestamp(tss_indicator,
                                     tsc_indicator)     [ VARIABLE ];
       payload_type         =:= optional_pt(pt_present) [ 0, 8 ];
       ts_stride            =:=
           optional_stride(tss_indicator,
                           ts_stride_value)             [ VARIABLE ];
       csrc_list            =:= list_csrc(cc.UVALUE)    [ VARIABLE ];

       ENFORCE(ttl_irregular_chain_flag == ttl_hopl_outer_flag.UVALUE);
       ENFORCE(tos_irregular_chain_flag == tos_tc_outer_flag.UVALUE);
     }

     // UO-0
     COMPRESSED pt_0_crc3 {
       discriminator =:= '0'                             [ 1 ];
       msn           =:= msn_lsb(4, 4)                   [ 4 ];
       header_crc    =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
       timestamp     =:= inferred_scaled_field           [ 0 ];
       ip_id         =:= inferred_sequential_ip_id       [ 0 ];
     }

     // New format, Type 0 with strong CRC and more SN bits
     COMPRESSED pt_0_crc7 {
       discriminator =:= '100'                           [ 3 ];
       msn           =:= msn_lsb(6, 16)                  [ 6 ];
       header_crc    =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       timestamp     =:= inferred_scaled_field           [ 0 ];
       ip_id         =:= inferred_sequential_ip_id       [ 0 ];
     }

     // UO-1 replacement
     COMPRESSED pt_1_rnd {
       discriminator =:= '101'                           [ 3 ];
       msn           =:= msn_lsb(5, 8)                   [ 5 ];



Pelletier & Sandlund     Expires March 10, 2007                [Page 65]

Internet-Draft               ROHCv2 Profiles              September 2006


       marker        =:= irregular(1)                    [ 1 ];
       ts_scaled     =:= lsb(4, 3)                       [ 4 ];
       header_crc    =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
               (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
     }

     // UO-1-ID replacement
     COMPRESSED pt_1_seq_id {
       discriminator =:= '1010'                          [ 4 ];
       header_crc    =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
       msn           =:= msn_lsb(5, 8)                   [ 5 ];
       ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4, 3)  [ 4 ];
       timestamp     =:= inferred_scaled_field           [ 0 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
               (ip_id_behavior.UVALUE ==
                IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
     }

     // UO-1-TS replacement
     COMPRESSED pt_1_seq_ts {
       discriminator =:= '1011'                          [ 4 ];
       marker        =:= irregular(1)                    [ 1 ];
       header_crc    =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
       msn           =:= msn_lsb(4, 4)                   [ 4 ];
       ts_scaled     =:= lsb(4, 3)                       [ 4 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
               (ip_id_behavior.UVALUE ==
                IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
     }

     // UOR-2 replacement
     COMPRESSED pt_2_rnd {
       discriminator =:= '110'                           [ 3 ];
       msn           =:= msn_lsb(7, 32)                  [ 7 ];
       ts_scaled     =:= lsb(6, 15)                      [ 6 ];
       marker        =:= irregular(1)                    [ 1 ];
       header_crc    =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
               (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
     }

     // UOR-2-ID replacement
     COMPRESSED pt_2_seq_id {
       discriminator =:= '1100'                          [ 4 ];
       msn           =:= msn_lsb(7, 32)                  [ 7 ];
       ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 6, 3)  [ 6 ];
       header_crc    =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];



Pelletier & Sandlund     Expires March 10, 2007                [Page 66]

Internet-Draft               ROHCv2 Profiles              September 2006


       timestamp     =:= inferred_scaled_field           [ 0 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
               (ip_id_behavior.UVALUE ==
                IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
     }

     // UOR-2-TS replacement
     COMPRESSED pt_2_seq_ts {
       discriminator =:= '1101'                          [ 4 ];
       msn           =:= msn_lsb(7, 32)                  [ 7 ];
       ts_scaled     =:= lsb(5, 7)                       [ 5 ];
       marker        =:= irregular(1)                    [ 1 ];
       header_crc    =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
               (ip_id_behavior.UVALUE ==
                IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
     }
   }

   ////////////////////////////////////////////
   // UDP profile
   ////////////////////////////////////////////

   // ttl_irregular_chain_flag is set by the user if the TTL/Hop Limit
   // of an outer header. The same value must be passed as an argument
   // to the ipv4/ipv6 encoding methods when extracting the irregular
   // chain items. The same applies to the tos_irregular_chain_flag
   udp_baseheader(profile,
                  ttl_irregular_chain_flag, tos_irregular_chain_flag)
   {
     UNCOMPRESSED v4 {
       outer_headers  =:= baseheader_outer_headers  [ VARIABLE ];
       version        =:= uncompressed_value(4, 4)  [ 4 ];
       header_length  =:= uncompressed_value(4, 5)  [ 4 ];
       tos_tc                                       [ 8 ];
       length                                       [ 16 ];
       ip_id                                        [ 16 ];
       rf             =:= uncompressed_value(1, 0)  [ 1 ];
       df                                           [ 1 ];
       mf             =:= uncompressed_value(1, 0)  [ 1 ];
       frag_offset    =:= uncompressed_value(13, 0) [ 13 ];
       ttl_hopl                                     [ 8 ];
       next_header                                  [ 8 ];
       checksum                                     [ 16 ];
       src_addr                                     [ 32 ];
       dest_addr                                    [ 32 ];
       extension_headers =:= baseheader_extension_headers [ VARIABLE ];
       src_port                                     [ 16 ];



Pelletier & Sandlund     Expires March 10, 2007                [Page 67]

Internet-Draft               ROHCv2 Profiles              September 2006


       dst_port                                     [ 16 ];
       udp_length                                   [ 16 ];
       checksum                                     [ 16 ];
     }

     UNCOMPRESSED v6 {
       outer_headers  =:= baseheader_outer_headers  [ VARIABLE ];
       version =:= uncompressed_value(4, 6)         [ 4 ];
       version                                      [ 4 ];
       tos_tc                                       [ 8 ];
       flow_label                                   [ 20 ];
       payload_length                               [ 16 ];
       next_header                                  [ 8 ];
       ttl_hopl                                     [ 8 ];
       src_addr                                     [ 128 ];
       dest_addr                                    [ 128 ];
       extension_headers =:= baseheader_extension_headers [ VARIABLE ];
       src_port                                     [ 16 ];
       dst_port                                     [ 16 ];
       udp_length                                   [ 16 ];
       checksum                                     [ 16 ];
       ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM);
     }

     CONTROL {
       ip_id_behavior [ 2 ];
       ENFORCE(profile == PROFILE_UDP_0102);
     }

     DEFAULT {
       tos_tc         =:= static;
       dest_addr      =:= static;
       version        =:= static;
       ttl_hopl       =:= static;
       src_addr       =:= static;
       df             =:= static;
       ip_id_behavior =:= static;
       payload_length =:= inferred_ip_v6_length;
       checksum       =:= inferred_ip_v4_header_checksum;
       length         =:= inferred_ip_v4_length;
       flow_label     =:= static;
       next_header    =:= static;
       src_port       =:= static;
       dst_port       =:= static;
       udp_length     =:= inferred_udp_length;
       checksum       =:= irregular(16);
       ENFORCE(ttl_irregular_chain_flag == 0);
       ENFORCE(tos_irregular_chain_flag == 0);



Pelletier & Sandlund     Expires March 10, 2007                [Page 68]

Internet-Draft               ROHCv2 Profiles              September 2006


     }

     // Replacement for UOR-2-ext3
     COMPRESSED co_common {
       discriminator        =:= '1111101'                [ 7 ];
       ip_id_indicator      =:= irregular(1)             [ 1 ];
       reorder_ratio        =:= reorder_choice           [ 2 ];
       msn                  =:= msn_lsb(6, 16)           [ 6 ];
       df           =:= dont_fragment(version.UVALUE)    [ 1 ];
       header_crc   =:= crc7(THIS.UVALUE, THIS.ULENGTH)  [ 7 ];
       ttl_hopl_outer_flag  =:= irregular(1)             [ 1 ];
       ttl_hopl_present     =:= irregular(1)             [ 1 ];
       tos_tc_outer_flag    =:= irregular(1)             [ 1 ];
       ip_id_behavior       =:= ip_id_behavior_choice    [ 2 ];
       control_crc3 =:= control_crc3                     [ 3 ];
       tos_tc_present       =:= irregular(1)             [ 1 ];
       reserved             =:= compressed_value(7, 0)   [ 7 ];
       ip_id                =:=
         optional_ip_id_lsb(ip_id_behavior.UVALUE,
                            ip_id_indicator.CVALUE)  [ 0, 8, 16 ];
       tos_tc               =:=
         tos_tc_enc(tos_tc_present.CVALUE)               [ 0, 8 ];
       ttl_hopl             =:=
         static_or_irreg(ttl_hopl_present.CVALUE,
                         ttl_hopl.ULENGTH)               [ 0, 8 ];

       ENFORCE(ttl_irregular_chain_flag == ttl_hopl_outer_flag.UVALUE);
       ENFORCE(tos_irregular_chain_flag == tos_tc_outer_flag.UVALUE);
     }

     // UO-0
     COMPRESSED pt_0_crc3 {
       discriminator =:= '0'                             [ 1 ];
       msn           =:= msn_lsb(4, 4)                   [ 4 ];
       header_crc    =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
       ip_id         =:= inferred_sequential_ip_id       [ 0 ];
     }

     // New format, Type 0 with strong CRC and more SN bits
     COMPRESSED pt_0_crc7 {
       discriminator =:= '100'                           [ 3 ];
       msn           =:= msn_lsb(6, 16)                  [ 6 ];
       header_crc    =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       ip_id         =:= inferred_sequential_ip_id       [ 0 ];
     }

     // UO-1-ID replacement (PT-1 only used for sequential)
     COMPRESSED pt_1_seq_id {



Pelletier & Sandlund     Expires March 10, 2007                [Page 69]

Internet-Draft               ROHCv2 Profiles              September 2006


       discriminator =:= '101'                           [ 3 ];
       header_crc    =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
       msn           =:= msn_lsb(6, 16)                  [ 6 ];
       ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4, 3)  [ 4 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
               (ip_id_behavior.UVALUE ==
                IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
     }

     // UOR-2 replacement
     COMPRESSED pt_2_rnd {
       discriminator =:= '110'                           [ 3 ];
       msn           =:= msn_lsb(6, 16)                  [ 6 ];
       header_crc    =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
               (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
     }

     // UOR-2-ID replacement
     COMPRESSED pt_2_seq_id {
       discriminator =:= '1100'                          [ 4 ];
       ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5, 3)  [ 5 ];
       header_crc    =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       msn           =:= msn_lsb(8, 64)                  [ 8 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
               (ip_id_behavior.UVALUE ==
                IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
     }
   }

   ////////////////////////////////////////////
   // ESP profile
   ////////////////////////////////////////////

   // ttl_irregular_chain_flag is set by the user if the TTL/Hop Limit
   // of an outer header. The same value must be passed as an argument
   // to the ipv4/ipv6 encoding methods when extracting the irregular
   // chain items. The same applies to the tos_irregular_chain_flag
   esp_baseheader(profile,
                  ttl_irregular_chain_flag, tos_irregular_chain_flag)
   {
     UNCOMPRESSED v4 {
       outer_headers  =:= baseheader_outer_headers  [ VARIABLE ];
       version        =:= uncompressed_value(4, 4)  [ 4 ];
       header_length  =:= uncompressed_value(4, 5)  [ 4 ];
       tos_tc                                       [ 8 ];
       length                                       [ 16 ];
       ip_id                                        [ 16 ];



Pelletier & Sandlund     Expires March 10, 2007                [Page 70]

Internet-Draft               ROHCv2 Profiles              September 2006


       rf             =:= uncompressed_value(1, 0)  [ 1 ];
       df                                           [ 1 ];
       mf             =:= uncompressed_value(1, 0)  [ 1 ];
       frag_offset    =:= uncompressed_value(13, 0) [ 13 ];
       ttl_hopl                                     [ 8 ];
       next_header                                  [ 8 ];
       checksum                                     [ 16 ];
       src_addr                                     [ 32 ];
       dest_addr                                    [ 32 ];
       extension_headers =:= baseheader_extension_headers [ VARIABLE ];
       spi             [ 32 ];
       sequence_number [ 32 ];
       ENFORCE(msn.UVALUE == sequence_number.UVALUE);
     }

     UNCOMPRESSED v6 {
       outer_headers  =:= baseheader_outer_headers  [ VARIABLE ];
       version =:= uncompressed_value(4, 6) [ 4 ];
       version                              [ 4 ];
       tos_tc                               [ 8 ];
       flow_label                           [ 20 ];
       payload_length                       [ 16 ];
       next_header                          [ 8 ];
       ttl_hopl                             [ 8 ];
       src_addr                             [ 128 ];
       dest_addr                            [ 128 ];
       extension_headers =:= baseheader_extension_headers [ VARIABLE ];
       spi             [ 32 ];
       sequence_number [ 32 ];
       ENFORCE(msn.UVALUE == (sequence_number.UVALUE % 65536));
       ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM);
     }

     CONTROL {
       ip_id_behavior [ 2 ];
       ENFORCE(profile == PROFILE_ESP_0103);
     }

     DEFAULT {
       tos_tc          =:= static;
       dest_addr       =:= static;
       version         =:= static;
       ttl_hopl        =:= static;
       src_addr        =:= static;
       df              =:= static;
       ip_id_behavior  =:= static;
       payload_length  =:= inferred_ip_v6_length;
       checksum        =:= inferred_ip_v4_header_checksum;



Pelletier & Sandlund     Expires March 10, 2007                [Page 71]

Internet-Draft               ROHCv2 Profiles              September 2006


       length          =:= inferred_ip_v4_length;
       flow_label      =:= static;
       next_header     =:= static;
       spi             =:= static;
       sequence_number =:= static;
       ENFORCE(ttl_irregular_chain_flag == 0);
       ENFORCE(tos_irregular_chain_flag == 0);
     }

     // Replacement for UOR-2-ext3
     COMPRESSED co_common {
       discriminator        =:= '1111101'               [ 7 ];
       ip_id_indicator      =:= irregular(1)            [ 1 ];
       df           =:= dont_fragment(version.UVALUE)   [ 1 ];
       header_crc   =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       ttl_hopl_outer_flag  =:= irregular(1)            [ 1 ];
       ttl_hopl_present     =:= irregular(1)            [ 1 ];
       tos_tc_outer_flag    =:= irregular(1)            [ 1 ];
       tos_tc_present       =:= irregular(1)            [ 1 ];
       reorder_ratio        =:= reorder_choice          [ 2 ];
       ip_id_behavior       =:= ip_id_behavior_choice   [ 2 ];
       control_crc3 =:= control_crc3                    [ 3 ];
       reserved             =:= compressed_value(5, 0)  [ 5 ];
       sequence_number =:=
           sdvl(sequence_number.ULENGTH) [ 8, 16, 24, 32 ];
       ip_id                =:=
         optional_ip_id_lsb(ip_id_behavior.UVALUE,
                            ip_id_indicator.CVALUE) [ 0, 8, 16 ];
       tos_tc               =:=
         tos_tc_enc(tos_tc_present.CVALUE)              [ 0, 8 ];
       ttl_hopl             =:=
         static_or_irreg(ttl_hopl_present.CVALUE,
                         ttl_hopl.ULENGTH)              [ 0, 8 ];
       ENFORCE(ttl_irregular_chain_flag == ttl_hopl_outer_flag.UVALUE);
       ENFORCE(tos_irregular_chain_flag == tos_tc_outer_flag.UVALUE);
     }

     // UO-0
     COMPRESSED pt_0_crc3 {
       discriminator =:= '0'                             [ 1 ];
       msn           =:= msn_lsb(4, 4)                   [ 4 ];
       header_crc    =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
       ip_id         =:= inferred_sequential_ip_id       [ 0 ];
     }

     // New format, Type 0 with strong CRC and more SN bits
     COMPRESSED pt_0_crc7 {
       discriminator =:= '100'                           [ 3 ];



Pelletier & Sandlund     Expires March 10, 2007                [Page 72]

Internet-Draft               ROHCv2 Profiles              September 2006


       msn           =:= msn_lsb(6, 16)                  [ 6 ];
       header_crc    =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       ip_id         =:= inferred_sequential_ip_id       [ 0 ];
     }

     // UO-1-ID replacement (PT-1 only used for sequential)
     COMPRESSED pt_1_seq_id {
       discriminator =:= '101'                           [ 3 ];
       header_crc    =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
       msn           =:= msn_lsb(6, 16)                  [ 6 ];
       ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4, 3)  [ 4 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
               (ip_id_behavior.UVALUE ==
                IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
     }

     // UOR-2 replacement
     COMPRESSED pt_2_rnd {
       discriminator =:= '110'                           [ 3 ];
       msn           =:= msn_lsb(6, 16)                  [ 6 ];
       header_crc    =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
               (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
     }

     // UOR-2-ID replacement
     COMPRESSED pt_2_seq_id {
       discriminator =:= '1100'                          [ 4 ];
       ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5, 3)  [ 5 ];
       header_crc    =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       msn           =:= msn_lsb(8, 64)                  [ 8 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
               (ip_id_behavior.UVALUE ==
                IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
     }
   }

   ////////////////////////////////////////////
   // IP-only profile
   ////////////////////////////////////////////

   // ttl_irregular_chain_flag is set by the user if the TTL/Hop Limit
   // of an outer header. The same value must be passed as an argument
   // to the ipv4/ipv6 encoding methods when extracting the irregular
   // chain items. The same applies to the tos_irregular_chain_flag
   iponly_baseheader(profile,
                     ttl_irregular_chain_flag, tos_irregular_chain_flag)
   {



Pelletier & Sandlund     Expires March 10, 2007                [Page 73]

Internet-Draft               ROHCv2 Profiles              September 2006


     UNCOMPRESSED v4 {
       outer_headers  =:= baseheader_outer_headers  [ VARIABLE ];
       version        =:= uncompressed_value(4, 4)  [ 4 ];
       header_length  =:= uncompressed_value(4, 5)  [ 4 ];
       tos_tc                                       [ 8 ];
       length                                       [ 16 ];
       ip_id                                        [ 16 ];
       rf             =:= uncompressed_value(1, 0)  [ 1 ];
       df                                           [ 1 ];
       mf             =:= uncompressed_value(1, 0)  [ 1 ];
       frag_offset    =:= uncompressed_value(13, 0) [ 13 ];
       ttl_hopl                                     [ 8 ];
       next_header                                  [ 8 ];
       checksum                                     [ 16 ];
       src_addr                                     [ 32 ];
       dest_addr                                    [ 32 ];
       extension_headers =:= baseheader_extension_headers [ VARIABLE ];
     }

     UNCOMPRESSED v6 {
       outer_headers  =:= baseheader_outer_headers        [ VARIABLE ];
       version =:= uncompressed_value(4, 6)               [ 4 ];
       version                                            [ 4 ];
       tos_tc                                             [ 8 ];
       flow_label                                         [ 20 ];
       payload_length                                     [ 16 ];
       next_header                                        [ 8 ];
       ttl_hopl                                           [ 8 ];
       src_addr                                           [ 128 ];
       dest_addr                                          [ 128 ];
       extension_headers =:= baseheader_extension_headers [ VARIABLE ];
       ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM);
     }

     CONTROL {
       ip_id_behavior [ 2 ];
       ENFORCE(profile == PROFILE_IP_0104);
     }

     DEFAULT {
       tos_tc         =:= static;
       dest_addr      =:= static;
       version        =:= static;
       ttl_hopl       =:= static;
       src_addr       =:= static;
       df             =:= static;
       ip_id_behavior =:= static;
       payload_length =:= inferred_ip_v6_length;



Pelletier & Sandlund     Expires March 10, 2007                [Page 74]

Internet-Draft               ROHCv2 Profiles              September 2006


       checksum       =:= inferred_ip_v4_header_checksum;
       length         =:= inferred_ip_v4_length;
       flow_label     =:= static;
       next_header    =:= static;
       ENFORCE(ttl_irregular_chain_flag == 0);
       ENFORCE(tos_irregular_chain_flag == 0);
     }

     // Replacement for UOR-2-ext3
     COMPRESSED co_common {
       discriminator        =:= '1111101'               [ 7 ];
       ip_id_indicator      =:= irregular(1)            [ 1 ];
       reorder_ratio        =:= reorder_choice          [ 2 ];
       msn                  =:= msn_lsb(6, 16)          [ 6 ];
       df           =:= dont_fragment(version.UVALUE)   [ 1 ];
       header_crc   =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       ttl_hopl_outer_flag  =:= irregular(1)            [ 1 ];
       ttl_hopl_present     =:= irregular(1)            [ 1 ];
       tos_tc_outer_flag    =:= irregular(1)            [ 1 ];
       ip_id_behavior       =:= ip_id_behavior_choice   [ 2 ];
       control_crc3 =:= control_crc3                    [ 3 ];
       tos_tc_present       =:= irregular(1)            [ 1 ];
       reserved             =:= compressed_value(7, 0)  [ 7 ];
       ip_id                =:=
         optional_ip_id_lsb(ip_id_behavior.UVALUE,
                            ip_id_indicator.CVALUE) [ 0, 8, 16 ];
       tos_tc               =:=
         tos_tc_enc(tos_tc_present.CVALUE)              [ 0, 8 ];
       ttl_hopl             =:=
         static_or_irreg(ttl_hopl_present.CVALUE,
                         ttl_hopl.ULENGTH)              [ 0, 8 ];

       ENFORCE(ttl_irregular_chain_flag == ttl_hopl_outer_flag.UVALUE);
       ENFORCE(tos_irregular_chain_flag == tos_tc_outer_flag.UVALUE);
     }

     // UO-0
     COMPRESSED pt_0_crc3 {
       discriminator =:= '0'                             [ 1 ];
       msn           =:= msn_lsb(4, 4)                   [ 4 ];
       header_crc    =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
       ip_id         =:= inferred_sequential_ip_id       [ 0 ];
     }

     // New format, Type 0 with strong CRC and more SN bits
     COMPRESSED pt_0_crc7 {
       discriminator =:= '100'                           [ 3 ];
       msn           =:= msn_lsb(6, 16)                  [ 6 ];



Pelletier & Sandlund     Expires March 10, 2007                [Page 75]

Internet-Draft               ROHCv2 Profiles              September 2006


       header_crc    =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       ip_id         =:= inferred_sequential_ip_id       [ 0 ];
     }

     // UO-1-ID replacement (PT-1 only used for sequential)
     COMPRESSED pt_1_seq_id {
       discriminator =:= '101'                           [ 3 ];
       header_crc    =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
       msn           =:= msn_lsb(6, 16)                  [ 6 ];
       ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4, 3)  [ 4 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
               (ip_id_behavior.UVALUE ==
                IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
     }

     // UOR-2 replacement
     COMPRESSED pt_2_rnd {
       discriminator =:= '110'                           [ 3 ];
       msn           =:= msn_lsb(6, 16)                  [ 6 ];
       header_crc    =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
               (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
     }

     // UOR-2-ID replacement
     COMPRESSED pt_2_seq_id {
       discriminator =:= '1100'                          [ 4 ];
       ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5, 3)  [ 5 ];
       header_crc    =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       msn           =:= msn_lsb(8, 64)                  [ 8 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
               (ip_id_behavior.UVALUE ==
                IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
     }
   }

   ////////////////////////////////////////////
   // UDP-lite/RTP profile
   ////////////////////////////////////////////

   // ttl_irregular_chain_flag is set by the user if the TTL/Hop Limit
   // of an outer header. The same value must be passed as an argument
   // to the ipv4/ipv6 encoding methods when extracting the irregular
   // chain items. The same applies to the tos_irregular_chain_flag
   udplite_rtp_baseheader(profile, ts_stride_value,
                  ttl_irregular_chain_flag, tos_irregular_chain_flag)
   {
     UNCOMPRESSED v4 {



Pelletier & Sandlund     Expires March 10, 2007                [Page 76]

Internet-Draft               ROHCv2 Profiles              September 2006


       outer_headers  =:= baseheader_outer_headers  [ VARIABLE ];
       version        =:= uncompressed_value(4, 4)  [ 4 ];
       header_length  =:= uncompressed_value(4, 5)  [ 4 ];
       tos_tc                                       [ 8 ];
       length                                       [ 16 ];
       ip_id                                        [ 16 ];
       rf             =:= uncompressed_value(1, 0)  [ 1 ];
       df                                           [ 1 ];
       mf             =:= uncompressed_value(1, 0)  [ 1 ];
       frag_offset    =:= uncompressed_value(13, 0) [ 13 ];
       ttl_hopl                                     [ 8 ];
       next_header                                  [ 8 ];
       checksum                                     [ 16 ];
       src_addr                                     [ 32 ];
       dest_addr                                    [ 32 ];
       extension_headers =:= baseheader_extension_headers [ VARIABLE ];
       src_port                             [ 16 ];
       dst_port                             [ 16 ];
       checksum_coverage                    [ 16 ];
       checksum                             [ 16 ];
       version =:= uncompressed_value(2, 0) [  2 ];
       pad_bit                              [  1 ];
       extension                            [  1 ];
       cc                                   [  4 ];
       marker                               [  1 ];
       payload_type                         [  7 ];
       sequence_number                      [ 16 ];
       timestamp                            [ 32 ];
       ssrc                                 [ 32 ];
       csrc_list                            [ VARIABLE ];
       ENFORCE(msn.UVALUE == sequence_number.UVALUE);
     }

     UNCOMPRESSED v6 {
       outer_headers  =:= baseheader_outer_headers  [ VARIABLE ];
       version =:= uncompressed_value(4, 6) [ 4 ];
       version                              [ 4 ];
       tos_tc                               [ 8 ];
       flow_label                           [ 20 ];
       payload_length                       [ 16 ];
       next_header                          [ 8 ];
       ttl_hopl                             [ 8 ];
       src_addr                             [ 128 ];
       dest_addr                            [ 128 ];
       extension_headers =:= baseheader_extension_headers [ VARIABLE ];
       src_port                             [ 16 ];
       dst_port                             [ 16 ];
       checksum_coverage                    [ 16 ];



Pelletier & Sandlund     Expires March 10, 2007                [Page 77]

Internet-Draft               ROHCv2 Profiles              September 2006


       checksum                             [ 16 ];
       version =:= uncompressed_value(2, 0) [  2 ];
       pad_bit                              [  1 ];
       extension                            [  1 ];
       cc                                   [  4 ];
       marker                               [  1 ];
       payload_type                         [  7 ];
       sequence_number                      [ 16 ];
       timestamp                            [ 32 ];
       ssrc                                 [ 32 ];
       csrc_list                            [ VARIABLE ];
       ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM);
     }

     CONTROL {
       ip_id_behavior    [  2 ];
       coverage_behavior [  2 ];
       ts_stride                           [ 32 ];
       ts_scaled                           [ 32 ];
       ts_offset =:=
           field_scaling(ts_stride.UVALUE, ts_scaled.UVALUE,
                         timestamp.UVALUE) [ 32 ];
       ENFORCE(ts_stride.UVALUE == ts_stride_value);
       ENFORCE(profile == PROFILE_RTP_0107);
     }

     DEFAULT {
       tos_tc            =:= static;
       dest_addr         =:= static;
       version           =:= static;
       ttl_hopl          =:= static;
       src_addr          =:= static;
       df                =:= static;
       ip_id_behavior    =:= static;
       payload_length    =:= inferred_ip_v6_length;
       checksum          =:= inferred_ip_v4_header_checksum;
       length            =:= inferred_ip_v4_length;
       flow_label        =:= static;
       next_header       =:= static;
       src_port          =:= static;
       dst_port          =:= static;
       checksum_coverage =:= irregular(16);
       checksum          =:= irregular(16);
       pad_bit           =:= static;
       extension         =:= static;
       cc                =:= static;
       // When marker not present in packets, it is assumed 0
       marker            =:= uncompressed_value(1, 0);



Pelletier & Sandlund     Expires March 10, 2007                [Page 78]

Internet-Draft               ROHCv2 Profiles              September 2006


       payload_type      =:= static;
       sequence_number   =:= static;
       timestamp         =:= static;
       ssrc              =:= static;
       csrc_list         =:= static;
       ENFORCE(ttl_irregular_chain_flag == 0);
       ENFORCE(tos_irregular_chain_flag == 0);
     }

     // Replacement for UOR-2-ext3
     COMPRESSED co_common {
       discriminator        =:= '1111101'               [ 7 ];
       marker               =:= irregular(1)            [ 1 ];
       header_crc   =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       ip_id_indicator      =:= irregular(1)            [ 1 ];
       ip_id_behavior       =:= ip_id_behavior_choice   [ 2 ];
       reorder_ratio        =:= reorder_choice          [ 2 ];
       df           =:= dont_fragment(version.UVALUE)   [ 1 ];
       control_crc3 =:= control_crc3                    [ 3 ];
       ttl_hopl_outer_flag  =:= irregular(1)            [ 1 ];
       ttl_hopl_present     =:= irregular(1)            [ 1 ];
       tos_tc_outer_flag    =:= irregular(1)            [ 1 ];
       tos_tc_present       =:= irregular(1)            [ 1 ];
       ts_indicator         =:= irregular(2)            [ 2 ];
       tss_indicator        =:= irregular(2)            [ 2 ];
       pt_present           =:= irregular(1)            [ 1 ];
       list_present         =:= irregular(1)            [ 1 ];
       pad_bit              =:= irregular(1)            [ 1 ];
       extension            =:= irregular(1)            [ 1 ];
       coverage_behavior    =:= irregular(2)            [ 2 ];
       reserved             =:= compressed_value(4, 0)  [ 4 ];
       sequence_number =:= sdvl(sequence_number.ULENGTH) [ 8, 16 ];
       ip_id                =:=
         optional_ip_id_lsb(ip_id_behavior.UVALUE,
                            ip_id_indicator.CVALUE) [ 0, 8, 16 ];
       tos_tc               =:=
         tos_tc_enc(tos_tc_present.CVALUE)              [ 0, 8 ];
       ttl_hopl             =:=
         static_or_irreg(ttl_hopl_present.CVALUE,
                         ttl_hopl.ULENGTH)              [ 0, 8 ];
       // Either scaled or unscaled timestamp
       ts_scaled            =:=
           optional_scaled_timestamp(tss_indicator,
                                     tsc_indicator)     [ VARIABLE ];
       ts_scaled            =:=
           optional_scaled_timestamp(tss_indicator,
                                     tsc_indicator)     [ VARIABLE ];
       payload_type         =:= optional_pt(pt_present) [ 0, 8 ];



Pelletier & Sandlund     Expires March 10, 2007                [Page 79]

Internet-Draft               ROHCv2 Profiles              September 2006


       ts_stride            =:=
           optional_stride(tss_indicator,
                           ts_stride_value)             [ VARIABLE ];
       csrc_list            =:= list_csrc(cc.UVALUE)    [ VARIABLE ];

       ENFORCE(ttl_irregular_chain_flag == ttl_hopl_outer_flag.UVALUE);
       ENFORCE(tos_irregular_chain_flag == tos_tc_outer_flag.UVALUE);
     }

     // UO-0
     COMPRESSED pt_0_crc3 {
       discriminator =:= '0'                             [ 1 ];
       msn           =:= msn_lsb(4, 4)                   [ 4 ];
       header_crc    =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
       timestamp     =:= inferred_scaled_field           [ 0 ];
       ip_id         =:= inferred_sequential_ip_id       [ 0 ];
     }

     // New format, Type 0 with strong CRC and more SN bits
     COMPRESSED pt_0_crc7 {
       discriminator =:= '100'                           [ 3 ];
       msn           =:= msn_lsb(6, 16)                  [ 6 ];
       header_crc    =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       timestamp     =:= inferred_scaled_field           [ 0 ];
       ip_id         =:= inferred_sequential_ip_id       [ 0 ];
     }

     // UO-1 replacement
     COMPRESSED pt_1_rnd {
       discriminator =:= '101'                           [ 3 ];
       msn           =:= msn_lsb(5, 8)                   [ 5 ];
       marker        =:= irregular(1)                    [ 1 ];
       ts_scaled     =:= lsb(4, 3)                       [ 4 ];
       header_crc    =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
               (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
     }

     // UO-1-ID replacement
     COMPRESSED pt_1_seq_id {
       discriminator =:= '1010'                          [ 4 ];
       header_crc    =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
       msn           =:= msn_lsb(5, 8)                   [ 5 ];
       ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4, 3)  [ 4 ];
       timestamp     =:= inferred_scaled_field           [ 0 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
               (ip_id_behavior.UVALUE ==
                IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));



Pelletier & Sandlund     Expires March 10, 2007                [Page 80]

Internet-Draft               ROHCv2 Profiles              September 2006


     }

     // UO-1-TS replacement
     COMPRESSED pt_1_seq_ts {
       discriminator =:= '1011'                          [ 4 ];
       marker        =:= irregular(1)                    [ 1 ];
       header_crc    =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
       msn           =:= msn_lsb(4, 4)                   [ 4 ];
       ts_scaled     =:= lsb(4, 3)                       [ 4 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
               (ip_id_behavior.UVALUE ==
                IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
     }

     // UOR-2 replacement
     COMPRESSED pt_2_rnd {
       discriminator =:= '110'                           [ 3 ];
       msn           =:= msn_lsb(7, 32)                  [ 7 ];
       ts_scaled     =:= lsb(6, 15)                      [ 6 ];
       marker        =:= irregular(1)                    [ 1 ];
       header_crc    =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||
               (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
     }

     // UOR-2-ID replacement
     COMPRESSED pt_2_seq_id {
       discriminator =:= '1100'                          [ 4 ];
       msn           =:= msn_lsb(7, 32)                  [ 7 ];
       ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 6, 3)  [ 6 ];
       header_crc    =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       timestamp     =:= inferred_scaled_field           [ 0 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
               (ip_id_behavior.UVALUE ==
                IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
     }

     // UOR-2-TS replacement
     COMPRESSED pt_2_seq_ts {
       discriminator =:= '1101'                          [ 4 ];
       msn           =:= msn_lsb(7, 32)                  [ 7 ];
       ts_scaled     =:= lsb(5, 7)                       [ 5 ];
       marker        =:= irregular(1)                    [ 1 ];
       header_crc    =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
               (ip_id_behavior.UVALUE ==
                IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
     }



Pelletier & Sandlund     Expires March 10, 2007                [Page 81]

Internet-Draft               ROHCv2 Profiles              September 2006


   }

   ////////////////////////////////////////////
   // UDP-lite profile
   ////////////////////////////////////////////

   // ttl_irregular_chain_flag is set by the user if the TTL/Hop Limit
   // of an outer header. The same value must be passed as an argument
   // to the ipv4/ipv6 encoding methods when extracting the irregular
   // chain items. The same applies to the tos_irregular_chain_flag
   udplite_baseheader(profile,
                  ttl_irregular_chain_flag, tos_irregular_chain_flag)
   {
     UNCOMPRESSED v4 {
       outer_headers  =:= baseheader_outer_headers  [ VARIABLE ];
       version        =:= uncompressed_value(4, 4)  [ 4 ];
       header_length  =:= uncompressed_value(4, 5)  [ 4 ];
       tos_tc                                       [ 8 ];
       length                                       [ 16 ];
       ip_id                                        [ 16 ];
       rf             =:= uncompressed_value(1, 0)  [ 1 ];
       df                                           [ 1 ];
       mf             =:= uncompressed_value(1, 0)  [ 1 ];
       frag_offset    =:= uncompressed_value(13, 0) [ 13 ];
       ttl_hopl                                     [ 8 ];
       next_header                                  [ 8 ];
       checksum                                     [ 16 ];
       src_addr                                     [ 32 ];
       dest_addr                                    [ 32 ];
       extension_headers =:= baseheader_extension_headers [ VARIABLE ];
       src_port                                     [ 16 ];
       dst_port                                     [ 16 ];
       checksum_coverage                            [ 16 ];
       checksum                                     [ 16 ];
     }

     UNCOMPRESSED v6 {
       outer_headers  =:= baseheader_outer_headers  [ VARIABLE ];
       version =:= uncompressed_value(4, 6) [ 4 ];
       version                              [ 4 ];
       tos_tc                               [ 8 ];
       flow_label                           [ 20 ];
       payload_length                       [ 16 ];
       next_header                          [ 8 ];
       ttl_hopl                             [ 8 ];
       src_addr                             [ 128 ];
       dest_addr                            [ 128 ];
       extension_headers =:= baseheader_extension_headers [ VARIABLE ];



Pelletier & Sandlund     Expires March 10, 2007                [Page 82]

Internet-Draft               ROHCv2 Profiles              September 2006


       src_port                             [ 16 ];
       dst_port                             [ 16 ];
       checksum_coverage                    [ 16 ];
       checksum                             [ 16 ];
       ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM);
     }

     CONTROL {
       ip_id_behavior    [ 2 ];
       coverage_behavior [ 2 ];
       ENFORCE(profile == PROFILE_UDPLITE_0108);
     }

     DEFAULT {
       tos_tc            =:= static;
       dest_addr         =:= static;
       version           =:= static;
       ttl_hopl          =:= static;
       src_addr          =:= static;
       df                =:= static;
       ip_id_behavior    =:= static;
       payload_length    =:= inferred_ip_v6_length;
       checksum          =:= inferred_ip_v4_header_checksum;
       length            =:= inferred_ip_v4_length;
       flow_label        =:= static;
       next_header       =:= static;
       src_port          =:= static;
       dst_port          =:= static;
       checksum_coverage =:= irregular(16);
       checksum          =:= irregular(16);
       ENFORCE(ttl_irregular_chain_flag == 0);
       ENFORCE(tos_irregular_chain_flag == 0);
     }

     // Replacement for UOR-2-ext3
     COMPRESSED co_common {
       discriminator        =:= '1111101'               [ 7 ];
       ip_id_indicator      =:= irregular(1)            [ 1 ];
       reorder_ratio        =:= reorder_choice          [ 2 ];
       msn                  =:= msn_lsb(6, 16)          [ 6 ];
       df            =:= dont_fragment(version.UVALUE)  [ 1 ];
       header_crc   =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       ttl_hopl_outer_flag  =:= irregular(1)            [ 1 ];
       ttl_hopl_present     =:= irregular(1)            [ 1 ];
       tos_tc_outer_flag    =:= irregular(1)            [ 1 ];
       ip_id_behavior       =:= ip_id_behavior_choice   [ 2 ];
       control_crc3 =:= control_crc3                    [ 3 ];
       tos_tc_present       =:= irregular(1)            [ 1 ];



Pelletier & Sandlund     Expires March 10, 2007                [Page 83]

Internet-Draft               ROHCv2 Profiles              September 2006


       coverage_behavior    =:= irregular(2)            [ 2 ];
       reserved             =:= compressed_value(5, 0)  [ 5 ];
       ip_id                =:=
         optional_ip_id_lsb(ip_id_behavior.UVALUE,
                            ip_id_indicator.CVALUE) [ 0, 8, 16 ];
       tos_tc               =:=
         tos_tc_enc(tos_tc_present.CVALUE)              [ 0, 8 ];
       ttl_hopl             =:=
         static_or_irreg(ttl_hopl_present.CVALUE,
                         ttl_hopl.ULENGTH)              [ 0, 8 ];

       ENFORCE(ttl_irregular_chain_flag == ttl_hopl_outer_flag.UVALUE);
       ENFORCE(tos_irregular_chain_flag == tos_tc_outer_flag.UVALUE);
     }

     // UO-0
     COMPRESSED pt_0_crc3 {
       discriminator =:= '0'                             [ 1 ];
       msn           =:= msn_lsb(4, 4)                   [ 4 ];
       header_crc    =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
       ip_id         =:= inferred_sequential_ip_id       [ 0 ];
     }

     // New format, Type 0 with strong CRC and more SN bits
     COMPRESSED pt_0_crc7 {
       discriminator =:= '100'                           [ 3 ];
       msn           =:= msn_lsb(6, 16)                  [ 6 ];
       header_crc    =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       ip_id         =:= inferred_sequential_ip_id       [ 0 ];
     }

     // UO-1-ID replacement (PT-1 only used for sequential)
     COMPRESSED pt_1_seq_id {
       discriminator =:= '101'                           [ 3 ];
       header_crc    =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ];
       msn           =:= msn_lsb(6, 16)                  [ 6 ];
       ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4, 3)  [ 4 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
               (ip_id_behavior.UVALUE ==
                IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
     }

     // UOR-2 replacement
     COMPRESSED pt_2_rnd {
       discriminator =:= '110'                           [ 3 ];
       msn           =:= msn_lsb(6, 16)                  [ 6 ];
       header_crc    =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) ||



Pelletier & Sandlund     Expires March 10, 2007                [Page 84]

Internet-Draft               ROHCv2 Profiles              September 2006


               (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO));
     }

     // UOR-2-ID replacement
     COMPRESSED pt_2_seq_id {
       discriminator =:= '1100'                          [ 4 ];
       ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5, 3)  [ 5 ];
       header_crc    =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ];
       msn           =:= msn_lsb(8, 64)                  [ 8 ];
       ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) ||
               (ip_id_behavior.UVALUE ==
                IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
     }
   }

6.7.  Feedback Formats and Options

6.7.1.  Feedback Formats

   This section describes the feedback format for ROHCv2 profiles, using
   the formats described in section 5.2.3 of
   [I-D.ietf-rohc-rfc3095bis-framework].

   All feedback formats carry a field labelled MSN, which contain LSBs
   of the MSN described in Section 6.2.1.  The sequence number to use is
   the MSN corresponding to the last header that was successfully CRC-8
   validated or CRC verified.

   FEEDBACK-1

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

      MSN: The lsb-encoded master sequence number.

   A FEEDBACK-1 is an ACK.  In order to send a NACK or a STATIC-NACK,
   FEEDBACK-2 must be used.












Pelletier & Sandlund     Expires March 10, 2007                [Page 85]

Internet-Draft               ROHCv2 Profiles              September 2006


   FEEDBACK-2

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      |Acktype|          MSN          |
      +---+---+---+---+---+---+---+---+
      |              MSN              |
      +---+---+---+---+---+---+---+---+
      |              CRC              |
      +---+---+---+---+---+---+---+---+
      /       Feedback options        /
      +---+---+---+---+---+---+---+---+

      Acktype:

         0 = ACK
         1 = NACK
         2 = STATIC-NACK
         3 is reserved (MUST NOT be used for parsability)

      MSN: The lsb-encoded master sequence number.

      CRC: 8-bit CRC computed over the entire feedback payload including
      any CID fields but excluding the packet type, the 'Size' field and
      the 'Code' octet, using the polynomial defined in
      [I-D.ietf-rohc-rfc3095bis-framework].  If the CID is given with an
      Add-CID octet, the Add-CID octet immediately precedes the
      FEEDBACK-1 or FEEDBACK-2 format.  For purposes of computing the
      CRC, the CRC field is zero.

      Feedback options: A variable number of feedback options, see
      Section 6.7.2.  Options may appear in any order.


   A FEEDBACK-2 of type NACK or STATIC-NACK is always implicitely an
   acknowlegement for a successfully decompressed packet, which packet
   corresponds to the MSN of the feedback element, unless the MSN-NOT-
   VALID option Section 6.7.2.2 appears in the feedback element.

   The FEEDBACK-2 format always carry a CRC and is thus more robust than
   the FEEDBACK-1 format.  When receiving FEEDBACK-2, the compressor
   MUST verify the information by computing the CRC and comparing the
   result with the CRC carried in the feedback format.  If the two are
   not identical, the feedback element MUST be discarded.







Pelletier & Sandlund     Expires March 10, 2007                [Page 86]

Internet-Draft               ROHCv2 Profiles              September 2006


6.7.2.  Feedback Options

   A feedback option has variable length and the following general
   format:

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      |   Opt Type    |    Opt Len    |
      +---+---+---+---+---+---+---+---+
      /          option data          /  Opt Length (octets)
      +---+---+---+---+---+---+---+---+

   The CRC option contains an 8-bit CRC computed over the entire
   feedback payload including any CID fields but excluding the packet
   type, the 'Size' field and the 'Code' octet, using the polynomial of
   [I-D.ietf-rohc-rfc3095bis-framework], section 5.3.1.1.

6.7.2.1.  The REJECT option

   The REJECT option informs the compressor that the decompressor does
   not have sufficient resources to handle the flow.

      +---+---+---+---+---+---+---+---+
      |  Opt Type = 2 |  Opt Len = 0  |
      +---+---+---+---+---+---+---+---+

   When receiving a REJECT option, the compressor MUST stop compressing
   the packet flow, and SHOULD refrain from attempting to increase the
   number of compressed packet flows for some time.  Any FEEDBACK packet
   carrying a REJECT option MUST also carry a CRC option.  The REJECT
   option MUST NOT appear more than once in the FEEDBACK-2 format,
   otherwise the decompressor MUST discard the entire feedback element.

6.7.2.2.  The MSN-NOT-VALID option

   The MSN-NOT-VALID option indicates that the MSN of the feedback is
   not valid.

      +---+---+---+---+---+---+---+---+
      |  Opt Type = 3 |  Opt Len = 0  |
      +---+---+---+---+---+---+---+---+

   A compressor MUST NOT use the MSN of the feedback to find the
   corresponding sent header when this option is present.  Consequently,
   a NACK or a STATIC-NACK feedback type sent with the MSN-NOT-VALID
   option is equivalent to a STATIC-NACK with respect to the type of
   context repair requested by the decompressor.




Pelletier & Sandlund     Expires March 10, 2007                [Page 87]

Internet-Draft               ROHCv2 Profiles              September 2006


   The MSN-NOT-VALID option MUST NOT appear more than once in the
   FEEDBACK-2 format and MUST NOT appear in the same feedback element as
   the MSN option, otherwise the decompressor MUST discard the entire
   feedback element.

6.7.2.3.  The MSN option

   The MSN option provides 8 additional bits of MSN.

      +---+---+---+---+---+---+---+---+
      |  Opt Type = 4 |  Opt Len = 1  |
      +---+---+---+---+---+---+---+---+
      |              MSN              |
      +---+---+---+---+---+---+---+---+

   the bits in the MSN option are concatenated with the MSN bits in the
   FEEDBACK-2 format, with the bits in the FEEDBACK-2 format being the
   most significant bits.  The MSN option MAY appear more than once in
   the FEEDBACK-2 format, in which case the MSN is given by
   concatenating the MSN fields of each occurance of the MSN option.

   The MSN option MUST NOT appear in the same feedback element as the
   MSN-NOT-VALID option, otherwise the decompressor MUST discard the
   entire feedback element.

6.7.2.4.  The CONTEXT_MEMORY Feedback Option

   The CONTEXT_MEMORY option informs the compressor that the
   decompressor does not have sufficient memory resources to handle the
   context of the packet flow, as the flow is currently compressed.

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      |  Opt Type = 9 |  Opt Len = 0  |
      +---+---+---+---+---+---+---+---+

   When receiving a CONTEXT_MEMORY option, the compressor SHOULD take
   actions to compress the packet flow in a way that requires less
   decompressor memory resources, or stop compressing the packet flow.
   The CONTEXT_MEMORY option MUST NOT appear more than once in the
   FEEDBACK-2 format, otherwise the decompressor MUST discard the entire
   feedback element.

6.7.2.5.  Unknown option types

   If an option type unknown to the compressor is encountered, it must
   continue parsing the rest of the FEEDBACK packet, which is possible
   since the length of the option is explicit, but MUST otherwise ignore



Pelletier & Sandlund     Expires March 10, 2007                [Page 88]

Internet-Draft               ROHCv2 Profiles              September 2006


   the unknown option.


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.
   However, for those cases where encryption of data (and not headers)
   is sufficient, RTP does specify an alternative encryption method in
   which only the RTP payload is encrypted and the headers are left in
   the clear.  That would still allow header compression to be applied.

   ROHC compression is transparent with regard to the RTP Sequence
   Number and RTP Timestamp fields, so the values of those fields can be
   used as the basis of payload encryption schemes (e.g., for
   computation of an initialization vector).

   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 IP, UDP and RTP headers and
   possibly also valid UDP checksums.  Such corruption may be detected
   with end-to-end authentication and integrity mechanisms which will
   not be affected by the compression.  Moreover, this header
   compression scheme uses an internal checksum for verification of
   reconstructed headers.  This 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, IR-PD 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

   The ROHC profile identifiers 0x00XX <# Editor's Note: To be replaced
   before publication #> has been reserved by the IANA for the profile
   defined in this document.

   <# Editor's Note: To be removed before publication #>

   A ROHC profile identifier must be reserved by the IANA for the
   updated profiles defined in this document.  Profiles 0x0000-0x0004
   have previously been reserved, and since there is no changes to



Pelletier & Sandlund     Expires March 10, 2007                [Page 89]

Internet-Draft               ROHCv2 Profiles              September 2006


   profile 0x0000, this document should thus update profiles 0x0001-
   0x0004.  As for previous ROHC profiles, profile numbers 0xnnXX must
   also be reserved for future updates of this profile.  A suggested
   registration in the "RObust Header Compression (ROHC) Profile
   Identifiers" name space would then be:

     Profile           Usage                 Reference
     0x0000            ROHC uncompressed     RFC 3095
     0x0001            ROHC RTP              RFC 3095
     0x0101            ROHCv2 RTP            [RFCXXXX (this)]
     0xn101 - 0xn2nn   Reserved
     0x0002            ROHC UDP              RFC 3095
     0x0102            ROHCv2 UDP            [RFCXXXX (this)]
     0xn102 - 0xn2nn   Reserved
     0x0003            ROHC ESP              RFC 3095
     0x0103            ROHCv2 ESP            [RFCXXXX (this)]
     0xn103 - 0xn2nn   Reserved
     0x0004            ROHC IP               RFC 3843
     0x0104            ROHCv2 IP             [RFCXXXX (this)]
     0xn104 - 0xn7nn   Reserved
     0x0005            ROHC LLA              RFC 3242
     0x0105            ROHC LLA with R-mode  RFC 3408
     0xn105 - 0xn7nn   Reserved
     0x0007            ROHC RTP/UDP-Lite     RFC 4019
     0x0107            ROHCv2 RTP/UDP-Lite   [RFCXXXX (this)]
     0xn107 - 0xn2nn   Reserved
     0x0008            ROHC UDP-Lite         RFC 4019
     0x0108            ROHCv2 UDP-Lite       [RFCXXXX (this)]
     0xn108 - 0xn2nn   Reserved

   Author's note: The list above is incorrect and incomplete.
                  It must be updated before sending to IANA.


9.  Acknowledgements

   The authors would like to thank the many people who have contributed
   to the ROHC specifications.  The sample Perl implementation of
   Appendix A was written by Carsten Bormann.


10.  References

10.1.  Normative References

   [I-D.ietf-rohc-formal-notation]
              Pelletier, G. and R. Finking, "Formal Notation for Robust
              Header Compression (ROHC-FN)",



Pelletier & Sandlund     Expires March 10, 2007                [Page 90]

Internet-Draft               ROHCv2 Profiles              September 2006


              draft-ietf-rohc-formal-notation-09 (work in progress),
              June 2005.

   [I-D.ietf-rohc-rfc3095bis-framework]
              Jonsson, L., Pelletier, G., and K. Sandlund, "The RObust
              Header Compression (ROHC) Framework",
              draft-ietf-rohc-rfc3095bis-framework-01 (work in
              progress), December 2005.

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

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

   [RFC2004]  Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
              October 1996.

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

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

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC2890]  Dommety, G., "Key and Sequence Number Extensions to GRE",
              RFC 2890, September 2000.

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

   [RFC3828]  Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
              G. Fairhurst, "The Lightweight User Datagram Protocol
              (UDP-Lite)", RFC 3828, July 2004.

   [RFC4019]  Pelletier, G., "RObust Header Compression (ROHC): Profiles
              for User Datagram Protocol (UDP) Lite", RFC 4019,
              April 2005.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              December 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.



Pelletier & Sandlund     Expires March 10, 2007                [Page 91]

Internet-Draft               ROHCv2 Profiles              September 2006


10.2.  Informative References

   [I-D.ietf-rohc-rfc3095bis-improvements]
              Jonsson, L., "Improvements for the ROHC Profile Set
              Update", draft-ietf-rohc-rfc3095bis-improvements-02 (work
              in progress), March 2006.

   [I-D.ietf-rohc-rtp-impl-guide]
              Jonsson, L., Pelletier, G., and K. Sandlund, "RObust
              Header Compression (ROHC): Corrections and Clarifications
              to RFC 3095", May 2006.

   [I-D.ietf-rohc-tcp]
              Pelletier, G., Sandlund, K., and M. West, "RObust Header
              Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)",
              draft-ietf-rohc-tcp-11 (work in progress), January 2006.

   [RFC3095]  Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
              Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
              K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
              Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
              Compression (ROHC): Framework and four profiles: RTP, UDP,
              ESP, and uncompressed", RFC 3095, July 2001.

   [RFC3843]  Jonsson, L-E. and G. Pelletier, "RObust Header Compression
              (ROHC): A Compression Profile for IP", RFC 3843,
              June 2004.

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


Appendix A.  Detailed classification of header fields

   Header compression is possible thanks to the fact that most header
   fields do not vary randomly from packet to packet.  Many of the
   fields exhibit static behavior or change in a more or less
   predictable way.  When designing a header compression scheme, it is
   of fundamental importance to understand the behavior of the fields in
   detail.

   In this appendix, all IP, UDP, UDP-Lite and RTP header fields are
   classified and analyzed in two steps.  First, we have a general
   classification in [REF] where the fields are classified on the basis
   of stable knowledge and assumptions.  The general classification does
   not take into account the change characteristics of changing fields
   because those will vary more or less depending on the implementation



Pelletier & Sandlund     Expires March 10, 2007                [Page 92]

Internet-Draft               ROHCv2 Profiles              September 2006


   and on the application used.  A less stable but more detailed
   analysis of the change characteristics is then done in [REF].
   Finally, [REF] summarizes this appendix with conclusions about how
   the various header fields should be handled by the header compression
   scheme to optimize compression and functionality.

Appendix A.1.  General classification

   INFERRED These fields contain values that can be inferred from other
   values, for example the size of the frame carrying the packet, and
   thus do not have to be handled at all by the compression scheme.

   STATIC These fields are expected to be constant throughout the
   lifetime of the packet stream.  Static information must in some way
   be communicated once.

   STATIC-DEF STATIC fields whose values define a packet stream.  They
   are in general handled as STATIC.

   STATIC-KNOWN These STATIC fields are expected to have well-known
   values and therefore do not need to be communicated at all.

   CHANGING These fields are expected to vary in some way: randomly,
   within a limited value set or range, or in some other manner.

   In this section, each of the IP, UDP and RTP header fields is
   assigned to one of these classes.  For all fields except those
   classified as CHANGING, the motives for the classification are also
   stated.  In section A.2, CHANGING fields are further examined and
   classified on the basis of their expected change behavior.

Appendix A.1.1.  IPv4 header fields



















Pelletier & Sandlund     Expires March 10, 2007                [Page 93]

Internet-Draft               ROHCv2 Profiles              September 2006


   +---------------------+-------------+----------------+
   | Field               | Size (bits) | Class          |
   +---------------------+-------------+----------------+
   | Version             | 4           | STATIC-KNOWN   |
   | Header Length       | 4           | STATIC-KNOWN   |
   | Type Of Service     | 8           | CHANGING       |
   | Packet Length       | 16          | INFERRED       |
   | Identification      | 16          | CHANGING       |
   | Reserved flag       | 1           | STATIC-KNOWN   |
   | Don't Fragment flag | 1           | CHANGING       |
   | More Fragments flag | 1           | STATIC-KNOWN   |
   | Fragment Offset     | 13          | STATIC-KNOWN   |
   | Time To Live        | 8           | CHANGING       |
   | Protocol            | 8           | STATIC         |
   | Header Checksum     | 16          | INFERRED       |
   | Source Address      | 32          | STATIC-DEF     |
   | Destination Address | 32          | STATIC-DEF     |
   +---------------------+-------------+----------------+

   Version

      The version field states which IP version is used.  Packets with
      different values in this field must be handled by different IP
      stacks.  All packets of a packet stream must therefore be of the
      same IP version.  Accordingly, the field is classified as STATIC.

   Header Length

      As long no options are present in the IP header, the header length
      is constant and well known.  If there are options, the fields
      would be STATIC, but it is assumed here that there are no options.
      The field is therefore classified as STATIC-KNOWN.

   Packet Length

      Information about packet length is expected to be provided by the
      link layer.  The field is therefore classified as INFERRED.

   Flags

      The Reserved flag must be set to zero and is therefore classified
      as STATIC-KNOWN.  The Don't Fragment (DF) flag will changes rarely
      and is therefore classified as CHANGING.  Finally, the More
      Fragments (MF) flag is expected to be zero because fragmentation
      is NOT expected, due to the small packet size expected.  The More
      Fragments flag is therefore classified as STATIC-KNOWN.

   Fragment Offset



Pelletier & Sandlund     Expires March 10, 2007                [Page 94]

Internet-Draft               ROHCv2 Profiles              September 2006


      Under the assumption that no fragmentation occurs, the fragment
      offset is always zero.  The field is therefore classified as
      STATIC-KNOWN.

   Protocol

      This field will have the same value in all packets of a packet
      stream.  It encodes the type of the subsequent header.

   Header Checksum

      The header checksum protects individual hops from processing a
      corrupted header.  When almost all IP header information is
      compressed away, there is no point in having this additional
      checksum; instead it can be regenerated at the decompressor side.
      The field is therefore classified as INFERRED.

   Source and Destination addresses

      These fields are part of the definition of a stream and must thus
      be constant for all packets in the stream.  The fields are
      therefore classified as STATIC-DEF.

Appendix A.1.2.  IPv6 header fields

   +---------------------+-------------+----------------+
   | Field               | Size (bits) | Class          |
   +---------------------+-------------+----------------+
   | Version             | 4           | STATIC-KNOWN   |
   | Traffic Class       | 8           | CHANGING       |
   | Flow Label          | 20          | STATIC-DEF     |
   | Payload Length      | 16          | INFERRED       |
   | Next Header         | 8           | STATIC         |
   | Hop Limit           | 8           | CHANGING       |
   | Source Address      | 128         | STATIC-DEF     |
   | Destination Address | 128         | STATIC-DEF     |
   +---------------------+-------------+----------------+

   Version

      The version field states which IP version is used.  Packets with
      different values in this field must be handled by different IP
      stacks.  All packets of a packet stream must therefore be of the
      same IP version.  Accordingly, the field is classified as STATIC.

   Flow Label





Pelletier & Sandlund     Expires March 10, 2007                [Page 95]

Internet-Draft               ROHCv2 Profiles              September 2006


      This field may be used to identify packets belonging to a specific
      packet stream.  If not used, the value should be set to zero.
      Otherwise, all packets belonging to the same stream must have the
      same value in this field, it being one of the fields that define
      the stream.  The field is therefore classified as STATIC-DEF.

   Payload Length

      Information about packet length (and, consequently, payload
      length) is expected to be provided by the link layer.  The field
      is therefore classified as INFERRED.

   Next Header

      This field will have the same value in all packets of a packet
      stream.  It encodes the type of the subsequent header.

   Source and Destination addresses

      These fields are part of the definition of a stream and must thus
      be constant for all packets in the stream.  The fields are
      therefore classified as STATIC-DEF.

Appendix A.1.3.  UDP header fields

   +------------------+-------------+-------------+
   | Field            | Size (bits) | Class       |
   +------------------+-------------+-------------+
   | Source Port      | 16          | STATIC-DEF  |
   | Destination Port | 16          | STATIC-DEF  |
   | Length           | 16          | INFERRED    |
   | Checksum         | 16          | CHANGING    |
   +------------------+-------------+-------------+

   Source and Destination ports

      These fields are part of the definition of a stream and must thus
      be constant for all packets in the stream.  The fields are
      therefore classified as STATIC-DEF.

   Length

      This field is redundant and is therefore classified as INFERRED.

Appendix A.1.4.  UDP-Lite header fields






Pelletier & Sandlund     Expires March 10, 2007                [Page 96]

Internet-Draft               ROHCv2 Profiles              September 2006


   +-------------------+-------------+-------------+
   | Field             | Size (bits) | Class       |
   +-------------------+-------------+-------------+
   | Source Port       | 16          | STATIC-DEF  |
   | Destination Port  | 16          | STATIC-DEF  |
   | Checksum Coverage | 16          | INFERRED    |
   |                   |             | STATIC      |
   |                   |             | CHANGING    |
   | Checksum          | 16          | CHANGING    |
   +-------------------+-------------+-------------+

   Source and Destination Port

      Same as for UDP Appendix A.1.3.

   Source and Destination ports

      Same as for UDP Appendix A.1.3.

   Checksum Coverage

      This field specifies which part of the UDP-Lite datagram is
      covered by the checksum.  It may have a value of zero or be equal
      to the datagram length if the checksum covers the entire datagram,
      or it may have any value between eight octets and the length of
      the datagram to specify the number of octets protected by the
      checksum, calculated from the first octet of the UDP-Lite header.
      The value of this field may vary for each packet, and this makes
      the value unpredictable from a header-compression perspective.

   Checksum

      The information used for the calculation of the UDP-Lite checksum
      is governed by the value of the checksum coverage and minimally
      includes the UDP-Lite header.  The checksum is a changing field
      that must always be sent as-is.

Appendix A.1.5.  RTP header fields













Pelletier & Sandlund     Expires March 10, 2007                [Page 97]

Internet-Draft               ROHCv2 Profiles              September 2006


   +-----------------+-------------+----------------+
   | Field           | Size (bits) | Class          |
   +-----------------+-------------+----------------+
   | Version         | 2           | STATIC-KNOWN   |
   | Padding         | 1           | CHANGING       |
   | Extension       | 1           | CHANGING       |
   | CSRC Counter    | 4           | CHANGING       |
   | Marker          | 1           | CHANGING       |
   | Payload Type    | 7           | CHANGING       |
   | Sequence Number | 16          | CHANGING       |
   | Timestamp       | 32          | CHANGING       |
   | SSRC            | 32          | STATIC-DEF     |
   | CSRC            | 0(-480)     | CHANGING       |
   +-----------------+-------------+----------------+

   Version

      Only one working RTP version exists, namely version 2.  The field
      is therefore classified as STATIC-KNOWN.

   Padding

      The use of this field is application-dependent, but when payload
      padding is used it is likely to be present in most or all packets.
      The field is classified as CHANGING to allow for the rare case
      where this field is updated.

   Extension

      If RTP extensions are used by the application, these extensions
      are likely to be present in all packets (but the use of extensions
      is very uncommon).  However, for safety's sake this field is
      classified as CHANGING to allow for the rare case where this field
      is changed during the flow.

   SSRC

      This field is part of the definition of a stream and must thus be
      constant for all packets in the stream.  The field is therefore
      classified as STATIC-DEF.

Appendix A.2.  Analysis of change patterns of header fields

   To design suitable mechanisms for efficient compression of all header
   fields, their change patterns must be analyzed.  For this reason, an
   extended classification is done based on the general classification
   in A.1, considering the fields which were labeled CHANGING in that
   classification.  Different applications will use the fields in



Pelletier & Sandlund     Expires March 10, 2007                [Page 98]

Internet-Draft               ROHCv2 Profiles              September 2006


   different ways, which may affect their behavior.  For the fields
   whose behavior is variable, typical behavior for conversational audio
   and video will be discussed.

   The CHANGING fields are separated into five different subclasses:
      STATIC These are fields that were classified as CHANGING on a
      general basis, but are classified as STATIC here due to certain
      additional assumptions.
      SEMISTATIC These fields are STATIC most of the time.  However,
      occasionally the value changes but will revert to its original
      value.
      RARELY-CHANGING (RC) These are fields that change their values
      occasionally and then keep their new values.
      ALTERNATING These fields alternate between a small number of
      different values.
      IRREGULAR These, finally, are the fields for which no useful
      change pattern can be identified.

   When the classification is done, other details are also stated
   regarding possible additional knowledge about the field values and/or
   field deltas, according to the classification.  For fields classified
   as STATIC or SEMISTATIC, the case could be that the value of the
   field is not only STATIC but also well KNOWN a priori (two states for
   SEMISTATIC fields).  For fields with non-irregular change behavior,
   it could be known that changes usually are within a LIMITED range
   compared to the maximal change for the field.  For other fields, the
   values are completely UNKNOWN.

   Table A.1 classifies all the CHANGING fields on the basis of their
   expected change patterns, especially for conversational audio and
   video.

   +------------------------+-------------+-------------+-------------+
   | Field                  | Value/Delta | Class       | Knowledge   |
   +========================+=============+=============+=============+
   |             Sequential | Delta       | RC          | LIMITED     |
   |             -----------+-------------+-------------+-------------+
   | IPv4 Id:    Seq. swap  | Delta       | RC          | LIMITED     |
   |             -----------+-------------+-------------+-------------+
   |             Random     | Value       | IRREGULAR   | UNKNOWN     |
   |             -----------+-------------+-------------+-------------+
   |             Zero       | Value       | IRREGULAR   | UNKNOWN     |
   +------------------------+-------------+-------------+-------------+
   | IP TOS / Tr. Class     | Value       | RC          | UNKNOWN     |
   +------------------------+-------------+-------------+-------------+
   | IP TTL / Hop Limit     | Value       | ALTERNATING | LIMITED     |
   +------------------------+-------------+-------------+-------------+
   | IP Don't Fragment      | Value       | RC          | KNOWN       |



Pelletier & Sandlund     Expires March 10, 2007                [Page 99]

Internet-Draft               ROHCv2 Profiles              September 2006


   +------------------------+-------------+-------------+-------------+
   |               Disabled | Value       | STATIC      | KNOWN       |
   | UDP Checksum: ---------+-------------+-------------+-------------+
   |               Enabled  | Value       | IRREGULAR   | UNKNOWN     |
   +------------------------+-------------+-------------+-------------+
   | UDP-Lite Checksum      | Value       | IRREGULAR   | UNKNOWN     |
   +------------------------+-------------+-------------+-------------+
   |                Case #1 | Value       | CHANGING    | INFERRED    |
   | UDP-Lite     ----------+-------------+-------------+-------------+
   | Checksum:      Case #2 | Value       | RC          | UNKNOWN     |
   | Coverage     ----------+-------------+-------------+-------------+
   |                Case #3 | Value       | IRREGULAR   | UNKNOWN     |
   +------------------------+-------------+-------------+-------------+
   |                 No mix | Value       | STATIC      | KNOWN       |
   | RTP CSRC Count: -------+-------------+-------------+-------------+
   |                 Mixed  | Value       | RC          | LIMITED     |
   +------------------------+-------------+-------------+-------------+
   | RTP Marker             | Value       | SEMISTATIC  | KNOWN/KNOWN |
   +------------------------+-------------+-------------+-------------+
   | RTP Payload Type       | Value       | RC          | UNKNOWN     |
   +------------------------+-------------+-------------+-------------+
   | RTP Extension          | Value       | RC          | UNKNOWN     |
   +------------------------+-------------+-------------+-------------+
   | RTP Padding            | Value       | RC          | UNKNOWN     |
   +------------------------+-------------+-------------+-------------+
   | RTP Sequence Number    | Delta       | STATIC      | KNOWN       |
   +------------------------+-------------+-------------+-------------+
   | RTP Timestamp          | Delta       | RC          | LIMITED     |
   +------------------------+-------------+-------------+-------------+
   |                 No mix | -           | -           | -           |
   | RTP CSRC List:  -------+-------------+-------------+-------------+
   |                 Mixed  | Value       | RC          | UNKNOWN     |
   +------------------------+-------------+-------------+-------------+
   Table A.1 : Classification of CHANGING header fields

   The following subsections discuss the various header fields in
   detail.  Note that table A.1 and the discussions below do not
   consider changes caused by loss or reordering before the compression
   point.

Appendix A.2.1.  IPv4 Identification

   The Identification field (IP ID) of the IPv4 header is there to
   identify which fragments constitute a datagram when reassembling
   fragmented datagrams.  The IPv4 specification does not specify
   exactly how this field is to be assigned values, only that each
   packet should get an IP ID that is unique for the source-destination
   pair and protocol for the time the datagram (or any of its fragments)



Pelletier & Sandlund     Expires March 10, 2007               [Page 100]

Internet-Draft               ROHCv2 Profiles              September 2006


   could be alive in the network.  This means that assignment of IP ID
   values can be done in various ways, which we have separated into
   three classes.

   Sequential

      In this behavior, the IP-ID is expected to increment by one for
      most packets, but may increment by a value larger than one,
      depending on the behavior of the transmitting IPv4 stack.

   Sequential Swapped

      When using this behavior, the IP-ID behaves as in the Sequential
      bahvior, but the two bytes of IP-ID are byte swapped.  Therefore,
      the IP-ID can be swapped before compression to make it behave
      exactly as the Sequential behavior.

   Random

      Some IP stacks assign IP ID values using a pseudo-random number
      generator.  There is thus no correlation between the ID values of
      subsequent datagrams, and therefore there is no way to predict the
      IP ID value for the next datagram.  For header compression
      purposes, this means that the IP ID field needs to be sent
      uncompressed with each datagram, resulting in two extra octets of
      header.

   Zero

      This behavior, although not a legal implementation of IPv4 is
      sometimes seen in existing IPv4 stacks.  When this behavior is
      used, all IP packets have the IP-ID value set to zero.

Appendix A.2.2.  IP Traffic Class / Type-Of-Service

   The Traffic-Class (IPv6) or Type-Of-Service (IPv4) field is expected
   to be constant during the lifetime of a packet stream or to change
   relatively seldom.

Appendix A.2.3.  IP Hop-limit / Time-To-Live

   The Hop-Limit (IPv6) or Time-To-Live (IPv4) field is expected to be
   constant during the lifetime of a packet stream or to alternate
   between a limited number of values due to route changes.







Pelletier & Sandlund     Expires March 10, 2007               [Page 101]

Internet-Draft               ROHCv2 Profiles              September 2006


Appendix A.2.4.  IPv4 Don't Fragment

   The Don't Fragment flag in IPv4 will seldom change, and is therefore
   classified as RC.

Appendix A.2.5.  UDP Checksum

   The UDP checksum is optional.  If disabled, its value is constantly
   zero and could be compressed away.  If enabled, its value depends on
   the payload, which for compression purposes is equivalent to it
   changing randomly with every packet.

Appendix A.2.6.  UDP-Lite Checksum Coverage

   The Checksum Coverage field may behave in different ways: it may have
   a value of zero, it may be equal to the datagram length, or it may
   have any value between eight octets and the length of the datagram.
   From a compression perspective, this field is expected to either be
   entirely predictable (for the cases where it follows the same
   behavior as the UDP Length field or where it takes on a constant
   value) or either to change randomly for each packet (making the value
   unpredictable from a header-compression perspective).  For all cases,
   the behavior itself is not expected to change for this field during
   the lifetime of a packet flow, or to change relatively seldom.

Appendix A.2.7.  UDP-Lite Checksum

   As opposed to the UDP checksum, the UDP-Lite checksum is not optional
   and it cannot be disabled.  Its value depends on the payload and on
   the checksum coverage field, which for compression purposes is
   equivalent to it changing randomly with every packet.

Appendix A.2.8.  RTP CSRC Counter

   This is a counter indicating the number of CSRC items present in the
   CSRC list.  This number is expected to be almost constant on a
   packet-to-packet basis and change by small amounts.  As long as no
   RTP mixer is used, the value of this field is zero.

Appendix A.2.9.  RTP Marker

   For audio the marker bit should be set only in the first packet of a
   talkspurt, while for video it should be set in the last packet of
   every picture.  This means that in both cases the RTP marker is
   classified as SEMISTATIC with well-known values for both states.






Pelletier & Sandlund     Expires March 10, 2007               [Page 102]

Internet-Draft               ROHCv2 Profiles              September 2006


Appendix A.2.10.  RTP Padding

   If padding is used, it is expected to be present in most packets, but
   is classified as RC to allow efficient compression even when this
   field changes.

Appendix A.2.11.  RTP Extension

   If extensions are used, it is expected to be used in most packets,
   but is classified as RC to allow efficient compression even when this
   field changes.

Appendix A.2.12.  RTP Payload Type

   Changes of the RTP payload type within a packet stream are expected
   to be rare.  Applications could adapt to congestion by changing
   payload type and/or frame sizes, but that is not expected to happen
   frequently.

Appendix A.2.13.  RTP Sequence Number

   The RTP Sequence Number will be incremented by one for each packet
   sent.

Appendix A.2.14.  RTP Timestamp

   In the audio case:

      As long as there are no pauses in the audio stream, the RTP
      Timestamp will be incremented by a constant delta, corresponding
      to the number of samples in the speech frame.  It will thus mostly
      follow the RTP Sequence Number.  When there has been a silent
      period and a new talkspurt begins, the timestamp will jump in
      proportion to the length of the silent period.  However, the
      increment will probably be within a relatively limited range.

   In the video case:

      Between two consecutive packets, the timestamp will either be
      unchanged or increase by a multiple of a fixed value corresponding
      to the picture clock frequency.  The timestamp can also decrease
      by a multiple of the fixed value for certain coding schemes.  The
      delta interval, expressed as a multiple of the picture clock
      frequency, is in most cases very limited.







Pelletier & Sandlund     Expires March 10, 2007               [Page 103]

Internet-Draft               ROHCv2 Profiles              September 2006


Appendix A.2.15.  RTP Contributing Sources (CSRC)

   The participants in a session, which are identified by the CSRC
   fields, are expected to be almost the same on a packet-to-packet
   basis with relatively few additions and removals.  As long as RTP
   mixers are not used, no CSRC fields are present at all.

Appendix A.3.  Header compression strategies

   This section elaborates on what has been done in previous sections.
   On the basis of the classifications, recommendations are given on how
   to handle the various fields in the header compression process.
   Seven different actions are possible; these are listed together with
   the fields to which each action applies.

Appendix A.3.1.  Do not send at all

   The fields that have well known values a priori do not have to be
   sent at all.  These are:
   o  IPv6 Payload Length
   o  IPv4 Header Length
   o  IPv4 Reserved Flag
   o  IPv4 Last Fragment Flag
   o  IPv4 Fragment Offset

   o  UDP Checksum (if disabled)
   o  RTP Version

Appendix A.3.2.  Transmit only initially

   The fields that are constant throughout the lifetime of the packet
   stream have to be transmitted and correctly delivered to the
   decompressor only once.  These are:
   o  IP Version
   o  IPv6 Next Header
   o  IPv4 Protocol
   o  IP Source Address
   o  IP Destination Address
   o  IPv6 Flow Label
   o  UDP Source Port
   o  UDP Destination Port
   o  UDP-Lite Source Port
   o  UDP-Lite Destination Port
   o  RTP SSRC







Pelletier & Sandlund     Expires March 10, 2007               [Page 104]

Internet-Draft               ROHCv2 Profiles              September 2006


Appendix A.3.3.  Transmit initially, be prepared to update

   The fields that are changing only occasionally must be transmitted
   initially but there must also be a way to update these fields with
   new values if they change.  These fields are:
   o  IPv6 Traffic Class
   o  IPv4 Don't Fragment Flag
   o  IPv6 Hop Limit
   o  IPv4 Type Of Service (TOS)
   o  IPv4 Time To Live (TTL)
   o  UDP-Lite Checksum Coverage (if constant or assigned to datagram
      length)
   o  RTP CSRC Counter
   o  RTP Padding Flag
   o  RTP Extension Flag
   o  RTP Payload Type
   o  RTP CSRC List

Appendix A.3.4.  Be prepared to update, or send as-is frequently

   For fields that normally either are constant or have values deducible
   from some other field, but that frequently diverge from that
   behavior, there must be an efficient way to update the field value or
   send it as-is in some packets.  These fields are:
   o  IPv4 Identification (if not sequentially assigned)
   o  RTP Marker
   o  RTP Timestamp

Appendix A.3.5.  Guarantee continuous robustness

   For fields that behave like a counter with a fixed delta for ALL
   packets, the only requirement on the transmission encoding is that
   packet losses between compressor and decompressor must be tolerable.
   If several such fields exist, all these can be communicated together.
   Such fields can also be used to interpret the values for fields
   listed in the previous section.  Fields that have this counter
   behavior are:
   o  IPv4 Identification (if sequentially assigned)
   o  RTP Sequence Number

Appendix A.3.6.  Transmit as-is in all packets

   Fields that have completely random values for each packet must be
   included as-is in all compressed headers.  Those fields are:
   o  IPv4 Identification (if randomly assigned)
   o  UDP Checksum (if enabled)





Pelletier & Sandlund     Expires March 10, 2007               [Page 105]

Internet-Draft               ROHCv2 Profiles              September 2006


   o  UDP-Lite Checksum
   o  UDP-Lite Checksum Coverage (if randomly assigned)

Appendix A.3.7.  Establish and be prepared to update delta

   Finally, there is a field that is usually increasing by a fixed delta
   and is correlated to another field.  For this field it would make
   sense to make that delta part of the context state.  The delta must
   then be initiated and updated in the same way as the fields listed in
   A.3.3.  The field to which this applies is:
   o  RTP Timestamp


Appendix B.  Differences between RoHCv2 and RFC3095 profiles

   To be Written

   Profiles defined in RFC3095 were designed with the assumption that
   the channel between compressor and decompressor maintains packet
   ordering, i.e., that the decompressor always receive packets in the
   same order as the compressor sent them.  RoHCv2 profiles does not
   make this assumption, i.e. reordering before and after the
   compression point is handled as part of the compression algorithm
   itself.


Appendix C.  Sample CRC algorithm

      #!/usr/bin/perl -w
      use strict;
      #=================================
      #
      # ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02
      #
      # This little demo shows the three types of CRC in use in
      # RFC3095, the RoHC Framework and ROHC profiles that
      # specificy robust header compression.
      # Type your data in hexadecimal form and then
      # press Control+D.
      #
      #---------------------------------
      #
      # utility
      #
      sub dump_bytes($) {
          my $x = shift;
          my $i;
          for ($i = 0; $i < length($x); ) {



Pelletier & Sandlund     Expires March 10, 2007               [Page 106]

Internet-Draft               ROHCv2 Profiles              September 2006


        printf("%02x ", ord(substr($x, $i, 1)));
        printf("\n") if (++$i % 16 == 0);
          }
          printf("\n") if ($i % 16 != 0);
      }

      #---------------------------------
      #
      # The CRC calculation algorithm.
      #
      sub do_crc($$$) {
          my $nbits = shift;
          my $poly = shift;
          my $string = shift;

          my $crc = ($nbits == 32 ? 0xffffffff : (1 << $nbits) - 1);
          for (my $i = 0; $i < length($string); ++$i) {
            my $byte = ord(substr($string, $i, 1));
            for( my $b = 0; $b < 8; $b++ ) {
              if (($crc & 1) ^ ($byte & 1)) {
                $crc >>= 1;
                $crc ^= $poly;
              } else {
              $crc >>= 1;
              }
              $byte >>= 1;
            }
          }
          printf "%2d bits, ", $nbits;
          printf "CRC: %02x\n", $crc;
      }

      #---------------------------------
      #
      # Test harness
      #
      $/ = undef;
      $_ = <>;         # read until EOF
      my $string = ""; # extract all that looks hex:
      s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg;
      dump_bytes($string);

      #---------------------------------
      #
      # 32-bit segmentation CRC
      # Note that the text implies this is complemented like for PPP
      # (this differs from 8, 7, and 3-bit CRC)
      #



Pelletier & Sandlund     Expires March 10, 2007               [Page 107]

Internet-Draft               ROHCv2 Profiles              September 2006


      #      C(x) = 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
      #
      do_crc(32, 0xedb88320, $string);

      #---------------------------------
      #
      # 8-bit IR/IR-DYN CRC
      #
      #      C(x) = x^0 + x^1 + x^2 + x^8
      #
      do_crc(8, 0xe0, $string);

      #---------------------------------
      #
      # 7-bit FO/SO CRC
      #
      #      C(x) = x^0 + x^1 + x^2 + x^3 + x^6 + x^7
      #
      do_crc(7, 0x79, $string);

      #---------------------------------
      #
      # 3-bit FO/SO CRC
      #
      #      C(x) = x^0 + x^1 + x^3
      #
      do_crc(3, 0x6, $string);



Authors' Addresses

   Ghyslain Pelletier
   Ericsson
   Box 920
   Lulea  SE-971 28
   Sweden

   Phone: +46 (0) 8 404 29 43
   Email: ghyslain.pelletier@ericsson.com










Pelletier & Sandlund     Expires March 10, 2007               [Page 108]

Internet-Draft               ROHCv2 Profiles              September 2006


   Kristofer Sandlund
   Ericsson
   Box 920
   Lulea  SE-971 28
   Sweden

   Phone: +46 (0) 8 404 41 58
   Email: kristofer.sandlund@ericsson.com











































Pelletier & Sandlund     Expires March 10, 2007               [Page 109]

Internet-Draft               ROHCv2 Profiles              September 2006


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

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Pelletier & Sandlund     Expires March 10, 2007               [Page 110]


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