Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3095

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

Pages: 168
Proposed Standard
Updated by:  37594815
Part 3 of 7 – Pages 39 to 65
First   Prev   Next

Top   ToC   RFC3095 - Page 39   prevText

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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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 Section