tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3095

 
 
 

RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed

Part 3 of 7, p. 39 to 65
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 39 
5.  The protocol

5.1.  Data structures

   The ROHC protocol is based on a number of parameters that form part
   of the negotiated channel state and the per-context state.  This
   section describes some of this state information in an abstract way.
   Implementations can use a different structure for and representation
   of this state.  In particular, negotiation protocols that set up the
   per-channel state need to establish the information that constitutes
   the negotiated channel state, but it is not necessary to exchange it
   in the form described here.

5.1.1.  Per-channel parameters

   MAX_CID: Nonnegative integer; highest context ID number to be used by
   the compressor (note that this parameter is not coupled to, but in
   effect further constrained by, LARGE_CIDS).

Top      Up      ToC       Page 40 
   LARGE_CIDS: Boolean; if false, the short CID representation (0 bytes
   or 1 prefix byte, covering CID 0 to 15) is used; if true, the
   embedded CID representation (1 or 2 embedded CID bytes covering CID 0
   to 16383) is used.

   PROFILES: Set of nonnegative integers, each integer indicating a
   profile supported by the decompressor.  The compressor MUST NOT
   compress using a profile not in PROFILES.

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

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

5.1.2.  Per-context parameters, profiles

   Per-context parameters are established with IR headers (see section
   5.2.3).  An IR header contains a profile identifier, which determines
   how the rest of the header is to be interpreted.  Note that the
   profile parameter determines the syntax and semantics of the packet
   type identifiers and packet types used in conjunction with a specific
   context.  This document describes profiles 0x0000, 0x0001, 0x0002,
   and 0x0003; further profiles may be defined when ROHC is extended in
   the future.

   Profile 0x0000 is for sending uncompressed IP packets.  See section
      5.10.

   Profile 0x0001 is for RTP/UDP/IP compression, see sections 5.3
      through 5.9.

   Profile 0x0002 is for UDP/IP compression, i.e., compression of the
      first 12 octets of the UDP payload is not attempted.  See section
      5.11.

   Profile 0x0003 is for ESP/IP compression, i.e., compression of the
      header chain up to and including the first ESP header, but not
      subsequent subheaders.  See section 5.12.

   Initially, all contexts are in no context state, i.e., all packets
   referencing this context except IR packets are discarded.  If defined
   by a "ROHC over X" document, per-channel negotiation can be used to
   pre-establish state information for a context (e.g., negotiating

Top      Up      ToC       Page 41 
   profile 0x0000 for CID 15).  Such state information can also be
   marked read-only in the negotiation, which would cause the
   decompressor to discard any IR packet attempting to modify it.

5.1.3.  Contexts and context identifiers

   Associated with each compressed flow is a context, which is the state
   compressor and decompressor maintain in order to correctly compress
   or decompress the headers of the packet stream.  Contexts are
   identified by a context identifier, CID, which is sent along with
   compressed headers and feedback information.

   The CID space is distinct for each channel, i.e., CID 3 over channel
   A and CID 3 over channel B do not refer to the same context, even if
   the endpoints of A and B are the same nodes.  In particular, CIDs for
   any pairs of forward and reverse channels are not related (forward
   and reverse channels need not even have CID spaces of the same size).

   Context information is conceptually kept in a table.  The context
   table is indexed using the CID which is sent along with compressed
   headers and feedback information.  The CID space can be negotiated to
   be either small, which means that CIDs can take the values 0 through
   15, or large, which means that CIDs take values between 0 and 2^14 -
   1 = 16383.  Whether the CID space is large or small is negotiated no
   later than when a channel is established.

   A small CID with the value 0 is represented using zero bits.  A small
   CID with a value from 1 to 15 is represented by a four-bit field in
   place of a packet type field (Add-CID) plus four more bits.  A large
   CID is represented using the encoding scheme of section 4.5.6,
   limited to two octets.

5.2.  ROHC packets and packet types

   The packet type indication scheme for ROHC has been designed under
   the following constraints:

   a) it must be possible to use only a limited number of packet sizes;
   b) it must be possible to send feedback information in separate ROHC
      packets as well as piggybacked on forward packets;
   c) it is desirable to allow elimination of the CID for one packet
      stream when few packet streams share a channel;
   d) it is anticipated that some packets with large headers may be
      larger than the MTU of very constrained lower layers.

Top      Up      ToC       Page 42 
   These constraints have led to a design which includes

   - optional padding,
   - a feedback packet type,
   - an optional Add-CID octet which provides 4 bits of CID, and
   - a simple segmentation and reassembly mechanism.

   A ROHC packet has the following general format (in the diagram,
   colons ":" indicate that the part is optional):

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

   Padding is any number (zero or more) of padding octets.  Either of
   Feedback or Header must be present.

   Feedback elements always start with a packet type indication.
   Feedback elements carry internal CID information.  Feedback is
   described in section 5.2.2.

   Header is either a profile-specific header or an IR or IR-DYN header
   (see sections 5.2.3 and 5.2.4).  Header either

   1) does not carry any CID information (indicating CID zero), or
   2) includes one Add-CID Octet (see below), or
   3) contains embedded CID information of length one or two octets.

   Alternatives 1) and 2) apply only to compressed headers in channels
   where the CID space is small.  Alternative 3) applies only to
   compressed headers in channels where the CID space is large.

   Padding Octet

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

Top      Up      ToC       Page 43 
   Add-CID Octet

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

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

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

   Header either starts with a packet type indication or has a packet
   type indication immediately following an Add-CID Octet.  All Header
   packet types have the following general format (in the diagram,
   slashes "/" indicate variable length):

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

   The large CID, if present, is encoded according to section 4.5.6.

5.2.1.  ROHC feedback

   Feedback carries information from decompressor to compressor.  The
   following principal kinds of feedback are supported.  In addition to
   the kind of feedback, other information may be included in profile-
   specific feedback information.

   ACK         : Acknowledges successful decompression of a packet,
                 which means that the context is up-to-date with a high
                 probability.

   NACK        : Indicates that the dynamic context of the
                 decompressor is out of sync.  Generated when several
                 successive packets have failed to be decompressed
                 correctly.

Top      Up      ToC       Page 44 
   STATIC-NACK : Indicates that the static context of the decompressor
                 is not valid or has not been established.

   It is anticipated that feedback to the compressor can be realized in
   many ways, depending on the properties of the particular lower layer.
   The exact details of how feedback is realized is to be specified in a
   "ROHC over X" document, for each lower layer X in question.  For
   example, feedback might be realized using

   1) lower-layer specific mechanisms

   2) a dedicated feedback-only channel, realized for example by the
      lower layer providing a way to indicate that a packet is a
      feedback packet

   3) a dedicated feedback-only channel, where the timing of the
      feedback provides information about which compressed packet caused
      the feedback

   4) interspersing of feedback packets among normal compressed packets
      going in the same direction as the feedback (lower layers do not
      indicate feedback)

   5) piggybacking of feedback information in compressed packets going
      in the same direction as the feedback (this technique may reduce
      the per-feedback overhead)

   6) interspersing and piggybacking on the same channel, i.e., both 4)
      and 5).

   Alternatives 1-3 do not place any particular requirements on the ROHC
   packet type scheme.  Alternatives 4-6 do, however.  The ROHC packet
   type scheme has been designed to allow alternatives 4-6 (these may be
   used for example over PPP):

   a) The ROHC scheme provides a feedback packet type.  The packet type
      is able to carry variable-length feedback information.

   b) The feedback information sent on a particular channel is passed
      to, and interpreted by, the compressor associated with feedback on
      that channel.  Thus, the feedback information must contain CID
      information if the associated compressor can use more than one
      context.  The ROHC feedback scheme requires that a channel carries
      feedback to at most one compressor.  How a compressor is
      associated with feedback on a particular channel needs to be
      defined in a "ROHC over X" document.

Top      Up      ToC       Page 45 
   c) The ROHC feedback information format is octet-aligned, i.e.,
      starts at an octet boundary, to allow using the format over a
      dedicated feedback channel, 2).

   d) To allow piggybacking, 5), it is possible to deduce the length of
      feedback information by examining the first few octets of the
      feedback.  This allows the decompressor to pass piggybacked
      feedback information to the associated same-side compressor
      without understanding its format.  The length information
      decouples the decompressor from the compressor in the sense that
      the decompressor can process the compressed header immediately
      without waiting for the compressor to hand it back after parsing
      the feedback information.

5.2.2.  ROHC feedback format

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

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   0 |   Code    |  feedback type octet
   +---+---+---+---+---+---+---+---+
   :             Size              :  if Code = 0
   +---+---+---+---+---+---+---+---+
   /         feedback data         /  variable length
   +---+---+---+---+---+---+---+---+

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

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

   feedback data: Profile-specific feedback information.  Includes
         CID information.

   The total size of the feedback data field is determinable upon
   reception by the decompressor, by inspection of the Code field and
   possibly the Size field.  This explicit length information allows
   piggybacking and also sending more than one feedback element in a
   packet.

   When the decompressor has determined the size of the feedback data
   field, it removes the feedback type octet and the Size field (if
   present) and hands the rest to the same-side associated compressor

Top      Up      ToC       Page 46 
   together with an indication of the size.  The feedback data received
   by the compressor has the following structure (feedback sent on a
   dedicated feedback channel MAY also use this format):

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   :         Add-CID octet         : if for small CIDs and (CID != 0)
   +---+---+---+---+---+---+---+---+
   :                               :
   /  large CID (4.5.6 encoding)   / 1-2 octets if for large CIDs
   :                               :
   +---+---+---+---+---+---+---+---+
   /           feedback            /
   +---+---+---+---+---+---+---+---+

   The large CID, if present, is encoded according to section 4.5.6.
   CID information in feedback data indicates the CID of the packet
   stream for which feedback is sent.  Note that the LARGE_CIDS
   parameter that controls whether a large CID is present is taken from
   the channel state of the receiving compressor's channel, NOT from
   that of the channel carrying the feedback.

   It is REQUIRED that the feedback field have either of the following
   two formats:

   FEEDBACK-1

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

   FEEDBACK-2

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

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

   The compressor can use the following logic to parse the feedback
   field.

Top      Up      ToC       Page 47 
   1) If for large CIDs, the feedback will always start with a CID
      encoded according to section 4.5.6.  If the first bit is 0, the
      CID uses one octet.  If the first bit is 1, the CID uses two
      octets.

   2) If for small CIDs, and the size is one octet, the feedback is a
      FEEDBACK-1.

   3) If for small CIDs, and the size is larger than one octet, and the
      feedback starts with the two bits 11, the feedback starts with an
      Add-CID octet.  If the size is 2, it is followed by FEEDBACK-1.
      If the size is larger than 2, the Add-CID is followed by
      FEEDBACK-2.

   4) Otherwise, there is no Add-CID octet, and the feedback starts with
      a FEEDBACK-2.

5.2.3.  ROHC IR packet type

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

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

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

Top      Up      ToC       Page 48 
   Profile: The profile to be associated with the CID.  In the IR
      packet, the profile identifier is abbreviated to the 8 least
      significant bits.  It selects the highest-number profile in the
      channel state parameter PROFILES that matches the 8 LSBs given.

   CRC: 8-bit CRC computed using the polynomial of section 5.9.1.  Its
      coverage is profile-dependent, but it MUST cover at least the
      initial part of the packet ending with the Profile field.  Any
      information which initializes the context of the decompressor
      should be protected by the CRC.

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

5.2.4.  ROHC IR-DYN packet type

   In contrast to the IR header, the IR-DYN header can never initialize
   an uninitialized context.  However, it can redefine what profile is
   associated with a context, see for example 5.11 (ROHC UDP) and 5.12
   (ROHC ESP).  Thus the type needs to be reserved at the framework
   level.  The IR-DYN header typically also initializes or refreshes
   parts of a context, typically the dynamic part.  It has the following
   general format:

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

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

Top      Up      ToC       Page 49 
      CRC: 8-bit CRC computed using the polynomial of section 5.9.1.
          Its coverage is profile-dependent, but it MUST cover at least
          the initial part of the packet ending with the Profile field.
          Any information which initializes the context of the
          decompressor should be protected by the CRC.

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

5.2.5.  ROHC segmentation

   Some link layers may provide a much more efficient service if the set
   of different packet sizes to be transported is kept small.  For such
   link layers, these sizes will normally be chosen to transport
   frequently occurring packets efficiently, with less frequently
   occurring packets possibly adapted to the next larger size by the
   addition of padding.  The link layer may, however, be limited in the
   size of packets it can offer in this efficient mode, or it may be
   desirable to request only a limited largest size.  To accommodate the
   occasional packet that is larger than that largest size negotiated,
   ROHC defines a simple segmentation protocol.

5.2.5.1.  Segmentation usage considerations

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

   ROHC segmentation should only be used for occasional packets with
   sizes larger than what is efficient to accommodate, e.g., due to
   exceptionally large ROHC headers.  The segmentation scheme was
   designed to reduce packet size variations that may occur due to
   outliers in the header size distribution.  In other cases,
   segmentation should be done at lower layers.  The segmentation scheme
   should only be used for packet sizes that are larger than the maximum
   size in the allowed set of sizes from the lower layers.

   In summary, ROHC segmentation should be used with a relatively low
   frequency in the packet flow.  If this cannot be ensured,
   segmentation should be performed at lower layers.

Top      Up      ToC       Page 50 
5.2.5.2.  Segmentation protocol

   Segment Packet

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

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

   The segment header may be preceded by padding octets and/or feedback.
   It never carries a CID.

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

   Reconstructed Unit

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

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

Top      Up      ToC       Page 51 
   If the CRC succeeds, the reconstructed ROHC packet is interpreted as
   a ROHC Header, optionally followed by a payload.  Note that this
   means that there can be no padding and no feedback in the
   reconstructed unit, and that the CID is derived from the initial
   octets of the reconstructed unit.

   (It should be noted that the ROHC segmentation protocol was inspired
   by SEAL by Steve Deering et al., which later became ATM AAL5.  The
   same arguments for not having sequence numbers in the segments but
   instead providing a strong CRC in the reconstructed unit apply here
   as well.  Note that, as a result of this protocol, there is no way in
   ROHC to make any use of a segment that has residual bit errors.)

5.2.6.  ROHC initial decompressor processing

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

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

   Other packet types can be used at will by individual profiles.

   The following steps is an outline of initial decompressor processing
   which upon reception of a ROHC packet can determine its contents.

   1) If the first octet is a Padding Octet (11100000),
      strip away all initial Padding Octets and goto next step.

   2) If the first remaining octet starts with 1110, it is an Add-CID
      octet:

         remember the Add-CID octet; remove the octet.

   3) If the first remaining octet starts with 11110, and an Add-CID
      octet was found in step 2),

         an error has occurred; the header MUST be discarded without
         further action.

   4) If the first remaining octet starts with 11110, and an Add-CID
      octet was not found in step 2), this is feedback:

         find the size of the feedback data, call it s;
         remove the feedback type octet;

Top      Up      ToC       Page 52 
         remove the Size octet if Code is 0;
         send feedback data of length s to the same-side associated
         compressor;
         if packet exhausted, stop; otherwise goto 2).

   5) If the first remaining octet starts with 1111111, this is a
      segment:

         attempt reconstruction using the segmentation protocol
         (5.2.5).  If a reconstructed packet is not produced, this
         finishes the processing of the original packet.  If a
         reconstructed packet is produced, it is fed into step 1)
         above.  Padding, segments, and feedback are not allowed in
         reconstructed packets, so when processing them, steps 1),
         4), and 5) are modified so that the packet is discarded
         without further action when their conditions match.

   6) Here, it is known that the rest is forward information (unless the
      header is damaged).

   7) If the forward traffic uses small CIDs, there is no large CID in
      the packet.  If an Add-CID immediately preceded the packet type
      (step 2), it has the CID of the Add-CID; otherwise it has CID 0.

   8) If the forward traffic uses large CIDs, the CID starts with the
      second remaining octet.  If the first bit(s) of that octet are not
      0 or 10, the packet MUST be discarded without further action.  If
      an Add-CID octet immediately preceded the packet type (step 2),
      the packet MUST be discarded without further action.

   9) Use the CID to find the context.

   10) If the packet type is IR, the profile indicated in the IR packet
       determines how it is to be processed.  If the CRC fails to verify
       the packet, it MUST be discarded.  If a profile is indicated in
       the context, the logic of that profile determines what, if any,
       feedback is to be sent.  If no profile is noted in the context,
       no further action is taken.

   11) If the packet type is IR-DYN, the profile indicated in the IR-DYN
       packet determines how it is to be processed.

      a) If the CRC fails to verify the packet, it MUST be discarded.
         If a profile is indicated in the context, the logic of that
         profile determines what, if any, feedback is to be sent.  If no
         profile is noted in the context, no further action is taken.

Top      Up      ToC       Page 53 
      b) If the context has not been initialized by an IR packet, the
         packet MUST be discarded.  The logic of the profile indicated
         in the IR-DYN header (if verified by the CRC), determines what,
         if any, feedback is to be sent.

   12) Otherwise, the profile noted in the context determines how the
       rest of the packet is to be processed.  If the context has not
       been initialized by an IR packet, the packet MUST be discarded
       without further action.

   The procedure for finding the size of the feedback data is as
   follows:

   Examine the three bits which immediately follow the feedback packet
   type.  When these bits are
      1-7, the size of the feedback data is given by the bits;
      0,   a Size octet, which explicitly gives the size of the
           feedback data, is present after the feedback type octet.

5.2.7.  ROHC RTP packet formats from compressor to decompressor

   ROHC RTP uses three packet types to identify compressed headers, and
   two for initialization/refresh.  The format of a compressed packet
   can depend on the mode.  Therefore a naming scheme of the form

      <modes format is used in>-<packet type number>-<some property>

   is used to uniquely identify the format when necessary, e.g., UOR-2,
   R-1.  For exact formats of the packet types, see section 5.7.

   Packet type zero: R-0, R-0-CRC, UO-0.

      This, the minimal, packet type is used when parameters of all SN-
      functions are known by the decompressor, and the header to be
      compressed adheres to these functions.  Thus, only the W-LSB
      encoded RTP SN needs to be communicated.

      R-mode: Only if a CRC is present (packet type R-0-CRC) may the
      header be used as a reference for subsequent decompression.

      U-mode and O-mode: A small CRC is present in the UO-0 packet.

   Packet type 1: R-1, R-1-ID, R-1-TS, UO-1, UO-1-ID, UO-1-TS.

      This packet type is used when the number of bits needed for the SN
      exceeds those available in packet type zero, or when the
      parameters of the SN-functions for RTP TS or IP-ID change.

Top      Up      ToC       Page 54 
      R-mode: R-1-* packets are not used as references for subsequent
      decompression.  Values for other fields than the RTP TS or IP-ID
      can be communicated using an extension, but they do not update the
      context.

      U-mode and O-mode: Only the values of RTP SN, RTP TS and IP-ID can
      be used as references for future compression.  Nonupdating values
      can be provided for other fields using an extension (UO-1-ID).

   Packet type 2: UOR-2, UOR-2-ID, UOR-2-TS

      This packet type can be used to change the parameters of any SN-
      function, except those for most static fields.  Headers of packets
      transferred using packet type 2 can be used as references for
      subsequent decompression.

   Packet type: IR

      This packet type communicates the static part of the context,
      i.e., the value of the constant SN-functions.  It can optionally
      also communicate the dynamic part of the context, i.e., the
      parameters of the nonconstant SN-functions.

   Packet type: IR-DYN

      This packet type communicates the dynamic part of the context,
      i.e., the parameters of nonconstant SN-functions.

5.2.8.  Parameters needed for mode transition in ROHC RTP

   The packet types IR (with dynamic information), IR-DYN, and UOR-2 are
   common for all modes.  They can carry a mode parameter which can take
   the values U = Unidirectional, O = Bidirectional Optimistic, and R =
   Bidirectional Reliable.

   Feedback of types ACK, NACK, and STATIC-NACK carry sequence numbers,
   and feedback packets can also carry a mode parameter indicating the
   desired compression mode: U, O, or R.

   As a shorthand, the notation PACKET(mode) is used to indicate which
   mode value a packet carries.  For example, an ACK with mode parameter
   R is written ACK(R), and an UOR-2 with mode parameter O is written
   UOR-2(O).

Top      Up      ToC       Page 55 
5.3.  Operation in Unidirectional mode

5.3.1.  Compressor states and logic (U-mode)

   Below is the state machine for the compressor in Unidirectional mode.
   Details of the transitions between states and compression logic are
   given subsequent to the figure.

                         Optimistic approach
      +------>------>------>------>------>------>------>------>------+
      |                                                              |
      |        Optimistic approach         Optimistic approach       |
      |      +------>------>------+      +------>------>------+      |
      |      |                    |      |                    |      |
      |      |                    v      |                    v      v
    +----------+                +----------+                +----------+
    | IR State |                | FO State |                | SO State |
    +----------+                +----------+                +----------+
      ^      ^                    |      ^                    |      |
      |      |      Timeout       |      |  Timeout / Update  |      |
      |      +------<------<------+      +------<------<------+      |
      |                                                              |
      |                           Timeout                            |
      +------<------<------<------<------<------<------<------<------+

5.3.1.1.  State transition logic (U-mode)

   The transition logic for compression states in Unidirectional mode is
   based on three principles: the optimistic approach principle,
   timeouts, and the need for updates.

5.3.1.1.1.  Optimistic approach, upwards transition

   Transition to a higher compression state in Unidirectional mode is
   carried out according to the optimistic approach principle.  This
   means that the compressor transits to a higher compression state when
   it is fairly confident that the decompressor has received enough
   information to correctly decompress packets sent according to the
   higher compression state.

   When the compressor is in the IR state, it will stay there until it
   assumes that the decompressor has correctly received the static
   context information.  For transition from the FO to the SO state, the
   compressor should be confident that the decompressor has all
   parameters needed to decompress according to a fixed pattern.

Top      Up      ToC       Page 56 
   The compressor normally obtains its confidence about decompressor
   status by sending several packets with the same information according
   to the lower compression state.  If the decompressor receives any of
   these packets, it will be in sync with the compressor.  The number of
   consecutive packets to send for confidence is not defined in this
   document.

5.3.1.1.2.  Timeouts, downward transition

   When the optimistic approach is taken as described above, there will
   always be a possibility of failure since the decompressor may not
   have received sufficient information for correct decompression.
   Therefore, the compressor MUST periodically transit to lower
   compression states.  Periodic transition to the IR state SHOULD be
   carried out less often than transition to the FO state.  Two
   different timeouts SHOULD therefore be used for these transitions.
   For an example of how to implement periodic refreshes, see [IPHC]
   chapters 3.3.1-3.3.2.

5.3.1.1.3.  Need for updates, downward transition

   In addition to the downward state transitions carried out due to
   periodic timeouts, the compressor must also immediately transit back
   to the FO state when the header to be compressed does not conform to
   the established pattern.

5.3.1.2.  Compression logic and packets used (U-mode)

   The compressor chooses the smallest possible packet format that can
   communicate the desired changes, and has the required number of bits
   for W-LSB encoded values.

5.3.1.3.  Feedback in Unidirectional mode

   The Unidirectional mode of operation is designed to operate over
   links where a feedback channel is not available.  If a feedback
   channel is available, however, the decompressor MAY send an
   acknowledgment of successful decompression with the mode parameter
   set to U (send an ACK(U)).  When the compressor receives such a
   message, it MAY disable (or increase the interval between) periodic
   IR refreshes.

5.3.2.  Decompressor states and logic (U-mode)

   Below is the state machine for the decompressor in Unidirectional
   mode.  Details of the transitions between states and decompression
   logic are given subsequent to the figure.

Top      Up      ToC       Page 57 
                                 Success
                +-->------>------>------>------>------>--+
                |                                        |
    No Static   |            No Dynamic        Success   |    Success
     +-->--+    |             +-->--+      +--->----->---+    +-->--+
     |     |    |             |     |      |             |    |     |
     |     v    |             |     v      |             v    |     v
   +--------------+         +----------------+         +--------------+
   |  No Context  |         | Static Context |         | Full Context |
   +--------------+         +----------------+         +--------------+
      ^                         |        ^                         |
      | k_2 out of n_2 failures |        | k_1 out of n_1 failures |
      +-----<------<------<-----+        +-----<------<------<-----+

5.3.2.1.  State transition logic (U-mode)

   Successful decompression will always move the decompressor to the
   Full Context state.  Repeated failed decompression will force the
   decompressor to transit downwards to a lower state.  The decompressor
   does not attempt to decompress headers at all in the No Context and
   Static Context states unless sufficient information is included in
   the packet itself.

5.3.2.2.  Decompression logic (U-mode)

   Decompression in Unidirectional mode is carried out following three
   steps which are described in subsequent sections.

5.3.2.2.1.  Decide whether decompression is allowed

   In Full Context state, decompression may be attempted regardless of
   what kind of packet is received.  However, for the other states
   decompression is not always allowed.  In the No Context state only IR
   packets, which carry the static information fields, may be
   decompressed.  Further, when in the Static Context state, only
   packets carrying a 7- or 8-bit CRC can be decompressed (i.e., IR,
   IR-DYN, or UOR-2 packets).  If decompression may not be performed the
   packet is discarded, unless the optional delayed decompression
   mechanism is used, see section 6.1.

5.3.2.2.2.  Reconstruct and verify the header

   When reconstructing the header, the decompressor takes the header
   information already stored in the context and updates it with the
   information received in the current header.  (If the reconstructed
   header fails the CRC check, these updates MUST be undone.)

Top      Up      ToC       Page 58 
   The sequence number is reconstructed by replacing the sequence number
   LSBs in the context with those received in the header.  The resulting
   value is then verified to be within the interpretation interval by
   comparison with a previously reconstructed reference value v_ref (see
   section 4.5.1).  If it is not within this interval, an adjustment is
   applied by adding N x interval_size to the reconstructed value so
   that the result is brought within the interpretation interval.  Note
   that N can be negative.

   If RTP Timestamp and IP Identification fields are not included in the
   received header, they are supposed to be calculated from the sequence
   number.  The IP Identifier usually increases by the same delta as the
   sequence number and the timestamp by the same delta times a fixed
   value.  See chapters 4.5.3 and 4.5.5 for details about how these
   fields are encoded in compressed headers.

   When working in Unidirectional mode, all compressed headers carry a
   CRC which MUST be used to verify decompression.

5.3.2.2.3.  Actions upon CRC failure

   This section is written so that it is applicable to all modes.

   A mismatch in the CRC can be caused by one or more of:

   1. residual bit errors in the current header

   2. a damaged context due to residual bit errors in previous headers

   3. many consecutive packets being lost between compressor and
      decompressor (this may cause the LSBs of the SN in compressed
      packets to be interpreted wrongly, because the decompressor has
      not moved the interpretation interval for lack of input -- in
      essence, a kind of context damage).

   (Cases 2 and 3 do not apply to IR packets; case 3 does not apply to
   IR-DYN packets.)  The 3-bit CRC present in some header formats will
   eventually detect context damage reliably, since the probability of
   undetected context damage decreases exponentially with each new
   header processed.  However, residual bit errors in the current header
   are only detected with good probability, not reliably.

   When a CRC mismatch is caused by residual bit errors in the current
   header (case 1 above), the decompressor should stay in its current
   state to avoid unnecessary loss of subsequent packets.  On the other
   hand, when the mismatch is caused by a damaged context (case 2), the
   decompressor should attempt to repair the context locally.  If the
   local repair attempt fails, it must move to a lower state to avoid

Top      Up      ToC       Page 59 
   delivering incorrect headers.  When the mismatch is caused by
   prolonged loss (case 3), the decompressor might attempt additional
   decompression attempts.  Note that case 3 does not occur in R-mode.

   The following actions MUST be taken when a CRC check fails:

   First, attempt to determine whether SN LSB wraparound (case 3) is
   likely, and if so, attempt a correction.  For this, the algorithm of
   section 5.3.2.2.4 MAY be used.  If another algorithm is used, it MUST
   have at least as high a rate of correct repairs as the one in
   5.3.2.2.4.  (This step is not applicable to R-mode.)

   Second, if the previous step did not attempt a correction, a repair
   should be attempted under the assumption that the reference SN has
   been incorrectly updated.  For this, the algorithm of section
   5.3.2.2.5 MAY be used.  If another algorithm is used, it MUST have at
   least as high a rate of correct repairs as the one in 5.3.2.2.5.
   (This step is not applicable to R-mode.)

   If both the above steps fail, additional decompression attempts
   SHOULD NOT be made.  There are two possible reasons for the CRC
   failure: case 1 or unrecoverable context damage.  It is impossible to
   know for certain which of these is the actual cause.  The following
   rules are to be used:

   a. When CRC checks fail only occasionally, assume residual errors in
      the current header and simply discard the packet.  NACKs SHOULD
      NOT be sent at this time.

   b. In the Full Context state: When the CRC check of k_1 out of the
      last n_1 decompressed packets have failed, context damage SHOULD
      be assumed and a NACK SHOULD be sent in O- and R-mode.  The
      decompressor moves to the Static Context state and discards all
      packets until an update (IR, IR-DYN, UOR-2) which passes the CRC
      check is received.

   c. In the Static Context state: When the CRC check of k_2 out of the
      last n_2 updates (IR, IR-DYN, UOR-2) have failed, static context
      damage SHOULD be assumed and a STATIC-NACK is sent in O- and R-
      mode.  The decompressor moves to the No Context state.

   d. In the No Context state: The decompressor discards all packets
      until a static update (IR) which passes the CRC check is received.
      (In O-mode and R-mode, feedback is sent according to sections
      5.4.2.2 and 5.5.2.2, respectively.)

Top      Up      ToC       Page 60 
   Note that appropriate values for k_1, n_1, k_2, and n_2, are related
   to the residual error rate of the link.  When the residual error rate
   is close to zero, k_1 = n_1 = k_2 = n_2 = 1 may be appropriate.

5.3.2.2.4.  Correction of SN LSB wraparound

   When many consecutive packets are lost there will be a risk of
   sequence number LSB wraparound, i.e., the SN LSBs being interpreted
   wrongly because the interpretation interval has not moved for lack of
   input.  The decompressor might be able to detect this situation and
   avoid context damage by using a local clock.  The following algorithm
   MAY be used:

   a. The decompressor notes the arrival time, a(i), of each incoming
      packet i.  Arrival times of packets where decompression fails are
      discarded.

   b. When decompression fails, the decompressor computes INTERVAL =
      a(i) - a(i - 1), i.e., the time elapsed between the arrival of the
      previous, correctly decompressed packet and the current packet.

   c. If wraparound has occurred, INTERVAL will correspond to at least
      2^k inter-packet times, where k is the number of SN bits in the
      current header.  On the basis of an estimate of the packet inter-
      arrival time, obtained for example using a moving average of
      arrival times, TS_STRIDE, or TS_TIME, the decompressor judges if
      INTERVAL can correspond to 2^k inter-packet times.

   d. If INTERVAL is judged to be at least 2^k packet inter-arrival
      times, the decompressor adds 2^k to the reference SN and attempts
      to decompress the packet using the new reference SN.

   e. If this decompression succeeds, the decompressor updates the
      context but SHOULD NOT deliver the packet to upper layers.  The
      following packet is also decompressed and updates the context if
      its CRC succeeds, but SHOULD be discarded.  If decompression of
      the third packet using the new context also succeeds, the context
      repair is deemed successful and this and subsequent decompressed
      packets are delivered to the upper layers.

   f. If any of the three decompression attempts in d. and e. fails, the
      decompressor discards the packets and acts according to rules a)
      through c) of section 5.3.2.2.3.

   Using this mechanism, the decompressor may be able to repair the
   context after excessive loss, at the expense of discarding two
   packets.

Top      Up      ToC       Page 61 
5.3.2.2.5.  Repair of incorrect SN updates

   The CRC can fail to detect residual errors in the compressed header
   because of its limited length, i.e., the incorrectly decompressed
   packet can happen to have the same CRC as the original uncompressed
   packet.  The incorrect decompressed header will then update the
   context.  This can lead to an erroneous reference SN being used in
   W-LSB decoding, as the reference SN is updated for each successfully
   decompressed header of certain types.

   In this situation, the decompressor will detect the incorrect
   decompression of the following packet with high probability, but it
   does not know the reason for the failure.  The following mechanism
   allows the decompressor to judge if the context was updated
   incorrectly by an earlier packet and, if so, to attempt a repair.

   a. The decompressor maintains two decompressed sequence numbers: the
      last one (ref 0) and the one before that (ref -1).

   b. When receiving a compressed header the SN (SN curr1) is
      decompressed using ref 0 as the reference.  The other header
      fields are decompressed using this decompressed SN curr1.  (This
      is part of the normal decompression procedure prior to any CRC
      test failures.)

   c. If the decompressed header generated in b. passes the CRC test,
      the references are shifted as follows:

           ref -1 = ref 0
           ref  0 = SN curr1.

   d. If the header generated in b. does not pass the CRC test, and the
      SN (SN curr2) generated when using ref -1 as the reference is
      different from SN curr1, an additional decompression attempt is
      performed based on SN curr2 as the decompressed SN.

   e. If the decompressed header generated in b. does not pass the CRC
      test and SN curr2 is the same as SN curr1, an additional
      decompression attempt is not useful and is not attempted.

   f. If the decompressed header generated in d. passes the CRC test,
      ref -1 is not changed while ref 0 is set to SN curr2.

   g. If the decompressed header generated in d. does not pass the CRC
      test, the decompressor acts according to rules a) through c) of
      section 5.3.2.2.3.

Top      Up      ToC       Page 62 
   The purpose of this algorithm is to repair the context.  If the
   header generated in d. passes the CRC test, the references are
   updated according to f., but two more headers MUST also be
   successfully decompressed before the repair is deemed successful.  Of
   the three successful headers, the first two SHOULD be discarded and
   only the third delivered to upper layers.  If decompression of any of
   the three headers fails, the decompressor MUST discard that header
   and the previously generated headers, and act according to rules a)
   through c) of section 5.3.2.2.3.

5.3.2.3.  Feedback in Unidirectional mode

   To improve performance for the Unidirectional mode over a link that
   does have a feedback channel, the decompressor MAY send an
   acknowledgment when decompression succeeds.  Setting the mode
   parameter in the ACK packet to U indicates that the compressor is to
   stay in Unidirectional mode.  When receiving an ACK(U), the
   compressor should reduce the frequency of IR packets since the static
   information has been correctly received, but it is not required to
   stop sending IR packets.  If IR packets continue to arrive, the
   decompressor MAY repeat the ACK(U), but it SHOULD NOT repeat the
   ACK(U) continuously.

5.4.  Operation in Bidirectional Optimistic mode

5.4.1.  Compressor states and logic (O-mode)

   Below is the state machine for the compressor in Bidirectional
   Optimistic mode.  The details of each state, state transitions, and
   compression logic are given subsequent to the figure.

                            Optimistic approach / ACK
     +------>------>------>------>------>------>------>------>------+
     |                                                              |
     |      Optimistic appr. / ACK      Optimistic appr. /ACK   ACK |
     |      +------>------>------+      +------>--- -->-----+  +->--+
     |      |                    |      |                   |  |    |
     |      |                    v      |                   v  |    v
   +----------+                +----------+                +----------+
   | IR State |                | FO State |                | SO State |
   +----------+                +----------+                +----------+
     ^      ^                    |      ^                    |      |
     |      |    STATIC-NACK     |      |    NACK / Update   |      |
     |      +------<------<------+      +------<------<------+      |
     |                                                              |
     |                         STATIC-NACK                          |
     +------<------<------<------<------<------<------<------<------+

Top      Up      ToC       Page 63 
5.4.1.1.  State transition logic

   The transition logic for compression states in Bidirectional
   Optimistic mode has much in common with the logic of the
   Unidirectional mode.  The optimistic approach principle and
   transitions occasioned by the need for updates work in the same way
   as described in chapter 5.3.1.  However, in Optimistic mode there are
   no timeouts.  Instead, the Optimistic mode makes use of feedback from
   decompressor to compressor for transitions in the backward direction
   and for OPTIONAL improved forward transition.

5.4.1.1.1.  Negative acknowledgments (NACKs), downward transition

   Negative acknowledgments (NACKs), also called context requests,
   obviate the periodic updates needed in Unidirectional mode.  Upon
   reception of a NACK the compressor transits back to the FO state and
   sends updates (IR-DYN, UOR-2, or possibly IR) to the decompressor.
   NACKs carry the SN of the latest packet successfully decompressed,
   and this information MAY be used by the compressor to determine what
   fields need to be updated.

   Similarly, reception of a STATIC-NACK packet makes the compressor
   transit back to the IR state.

5.4.1.1.2.  Optional acknowledgments, upwards transition

   In addition to NACKs, positive feedback (ACKs) MAY also be used for
   UOR-2 packets in the Bidirectional Optimistic mode.  Upon reception
   of an ACK for an updating packet, the compressor knows that the
   decompressor has received the acknowledged packet and the transition
   to a higher compression state can be carried out immediately.  This
   functionality is optional, so a compressor MUST NOT expect to get
   such ACKs initially.

   The compressor MAY use the following algorithm to determine when to
   expect ACKs for UOR-2 packets.  Let an update event be when a
   sequence of UOR-2 headers are sent to communicate an irregularity in
   the packet stream.  When ACKs have been received for k_3 out of the
   last n_3 update events, the compressor will expect ACKs.  A
   compressor which expects ACKs will repeat updates (possibly not in
   every packet) until an ACK is received.

5.4.1.2.  Compression logic and packets used

   The compression logic is the same for the Bidirectional Optimistic
   mode as for the Unidirectional mode (see section 5.3.1.2).

Top      Up      ToC       Page 64 
5.4.2.  Decompressor states and logic (O-mode)

   The decompression states and the state transition logic are the same
   as for the Unidirectional case (see section 5.3.2).  What differs is
   the decompression and feedback logic.

5.4.2.1.  Decompression logic, timer-based timestamp decompression

   In Bidirectional mode (or if there is some other way for the
   compressor to obtain the decompressor's clock resolution and the
   link's jitter), timer-based timestamp decompression may be used to
   improve compression efficiency when RTP Timestamp values are
   proportional to wall-clock time.  The mechanisms used are those
   described in 4.5.4.

5.4.2.2.  Feedback logic (O-mode)

   The feedback logic defines what feedback to send due to different
   events when operating in the various states.  As mentioned above,
   there are three principal kinds of feedback; ACK, NACK and STATIC-
   NACK.  Further, the logic described below will refer to different
   kinds of packets that can be received by the decompressor;
   Initialization and Refresh (IR) packets, IR packets without static
   information (IR-DYN) and type 2 packets (UOR-2), or type 1 (UO-1) and
   type 0 packets (UO-0).  A type 0 packet carries a packet header
   compressed according to a fixed pattern, while type 1, 2 and IR-DYN
   packets are used when this pattern is broken.

   Below, rules are defined stating which feedback to use when.  If the
   optional feedback is used once, the decompressor is REQUIRED to
   continue to send optional feedback for the lifetime of the packet
   stream.

   State Actions

   NC:  - When an IR packet passes the CRC check, send an ACK(O).
        - When receiving a type 0, 1, 2 or IR-DYN packet, or an IR
          packet has failed the CRC check, send a STATIC-NACK(O),
          subject to the considerations at the beginning of section
          5.7.6.

   SC:  - When an IR packet is correctly decompressed, send an ACK(O).
        - When a type 2 or an IR-DYN packet is correctly decompressed,
          optionally send an ACK(O).
        - When a type 0 or 1 packet is received, treat it as a
          mismatching CRC and use the logic of section 5.3.2.2.3 to
          decide if a NACK(O) should be sent.

Top      Up      ToC       Page 65 
        - When decompression of a type 2 packet, an IR-DYN packet or an
          IR packet has failed, use the logic of section 5.3.2.2.3 to
          decide if a STATIC-NACK(O) should be sent.

   FC:  - When an IR packet is correctly decompressed, send an ACK(O).
        - When a type 2 or an IR-DYN packet is correctly decompressed,
          optionally send an ACK(O).
        - When a type 0 or 1 packet is correctly decompressed, no
          feedback is sent.
        - When any packet fails the CRC check, use the logic of
          5.3.2.2.3 to decide if a NACK(O) should be sent.



(page 65 continued on part 4)

Next RFC Part