Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
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 5 of 7 – Pages 90 to 119
First   Prev   Next

Top   ToC   RFC3095 - Page 90   prevText

5.7.6. Feedback packets and formats

When the round-trip time between compressor and decompressor is large, several packets can be in flight concurrently. Therefore, several packets may be received by the decompressor after feedback has been sent and before the compressor has reacted to feedback. Moreover, decompression may fail due to residual errors in the compressed header. Therefore, a) in O-mode, the decompressor SHOULD limit the rate at which feedback on successful decompression is sent (if it is sent at all); b) when decompression fails, feedback SHOULD be sent only when decompression of several consecutive packets has failed, and when this occurs, the feedback rate SHOULD be limited; c) when packets are received which belong to a rejected packet stream, the feedback rate SHOULD be limited. A decompressor MAY limit the feedback rate by sending feedback only for one out of every k packets provoking the same (kind of) feedback. The appropriate value of k is implementation dependent; k might be chosen such that feedback is sent 1-3 times per link round-trip time. See section 5.2.2 for a discussion concerning ways to provide feedback information to the compressor.
5.7.6.1. Feedback formats for ROHC RTP
This section describes the format for feedback information in ROHC RTP. See also 5.2.2. Several feedback formats carry a field labeled SN. The SN field contains LSBs of an RTP Sequence Number. The sequence number to use is the sequence number of the header which caused the feedback information to be sent. If that sequence number cannot be determined, for example when decompression fails, the sequence number to use is that of the last successfully decompressed header. If no sequence number is available, the feedback MUST carry a SN-NOT-VALID option. Upon reception, the compressor matches valid SN LSBs with the most recent header sent with a SN with matching LSBs. The decompressor must ensure that it sends enough SN LSBs in its feedback that this correlation does not become ambiguous; e.g., if an 8-bit SN LSB field could wrap around within a round-trip time, the FEEDBACK-1 format cannot be used.
Top   ToC   RFC3095 - Page 91
    FEEDBACK-1

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

      A FEEDBACK-1 is an ACK.  In order to send a NACK or a STATIC-NACK,
      FEEDBACK-2 must be used.  FEEDBACK-1 does not contain any mode
      information; FEEDBACK-2 must be used when mode information is
      required.

   FEEDBACK-2

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   |Acktype| Mode  |      SN       |
   +---+---+---+---+---+---+---+---+
   |              SN               |
   +---+---+---+---+---+---+---+---+
   /       Feedback options        /
   +---+---+---+---+---+---+---+---+

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

      Mode:     0 is reserved
                1 = Unidirectional mode
                2 = Bidirectional Optimistic mode
                3 = Bidirectional Reliable mode


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

5.7.6.2. ROHC RTP Feedback options
A ROHC RTP Feedback option has variable length and the following general format: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | Opt Type | Opt Len | +---+---+---+---+---+---+---+---+ / option data / Opt Len octets +---+---+---+---+---+---+---+---+
Top   ToC   RFC3095 - Page 92
   Sections 5.7.6.3-9 describe the currently defined ROHC RTP feedback
   options.

5.7.6.3. The CRC option
The CRC option contains an 8-bit CRC computed over the entire feedback payload, without the packet type and code octet, but including any CID fields, using the polynomial of section 5.9.1. If the CID is given with an Add-CID octet, the Add-CID octet immediately precedes the FEEDBACK-1 or FEEDBACK-2 format. For purposes of computing the CRC, the CRC fields of all CRC options are zero. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | Opt Type = 1 | Opt Len = 1 | +---+---+---+---+---+---+---+---+ | CRC | +---+---+---+---+---+---+---+---+ When receiving feedback information with a CRC option, the compressor MUST verify the information by computing the CRC and comparing the result with the CRC carried in the CRC option. If the two are not identical, the feedback information MUST be ignored.
5.7.6.4. The REJECT option
The REJECT option informs the compressor that the decompressor does not have sufficient resources to handle the flow. +---+---+---+---+---+---+---+---+ | Opt Type = 2 | Opt Len = 0 | +---+---+---+---+---+---+---+---+ When receiving a REJECT option, the compressor stops compressing the packet stream, and should refrain from attempting to increase the number of compressed packet streams for some time. Any FEEDBACK packet carrying a REJECT option MUST also carry a CRC option.
5.7.6.5. The SN-NOT-VALID option
The SN-NOT-VALID option indicates that the SN of the feedback is not valid. A compressor MUST NOT use the SN of the feedback to find the corresponding sent header when this option is present. +---+---+---+---+---+---+---+---+ | Opt Type = 3 | Opt Len = 0 | +---+---+---+---+---+---+---+---+
Top   ToC   RFC3095 - Page 93
5.7.6.6. The SN option
The SN option provides 8 additional bits of SN. +---+---+---+---+---+---+---+---+ | Opt Type = 4 | Opt Len = 1 | +---+---+---+---+---+---+---+---+ | SN | +---+---+---+---+---+---+---+---+
5.7.6.7. The CLOCK option
The CLOCK option informs the compressor of the clock resolution of the decompressor. This is needed to allow the compressor to estimate the jitter introduced by the clock of the decompressor when doing timer-based compression of the RTP Timestamp. +---+---+---+---+---+---+---+---+ | Opt Type = 5 | Opt Len = 1 | +---+---+---+---+---+---+---+---+ | clock resolution (ms) | +---+---+---+---+---+---+---+---+ The smallest clock resolution which can be indicated is 1 millisecond. The value zero has a special meaning: it indicates that the decompressor cannot do timer-based compression of the RTP Timestamp. Any FEEDBACK packet carrying a CLOCK option SHOULD also carry a CRC option.
5.7.6.8. The JITTER option
The JITTER option allows the decompressor to report the maximum jitter it has observed lately, using the following formula which is very similar to the formula for Max_Jitter_BC in section 4.5.4. Let observation window i contain the decompressor's best approximation of the sliding window of the compressor (see section 4.5.4) when header i is received. Max_Jitter_i = max {|(T_i - T_j) - ((a_i - a_j) / TIME_STRIDE)|, for all headers j in observation window i} Max_Jitter = max { Max_Jitter_i, for a large number of recent headers i }
Top   ToC   RFC3095 - Page 94
   This information may be used by the compressor to refine the formula
   for determining k when doing timer-based compression of the RTP
   Timestamp.

   +---+---+---+---+---+---+---+---+
   |  Opt Type = 6 |  Opt Len = 1  |
   +---+---+---+---+---+---+---+---+
   |          Max_Jitter           |
   +---+---+---+---+---+---+---+---+

   The decompressor MAY ignore the oldest observed values of
   Max_Jitter_i.  Thus, the reported Max_Jitter may decrease.
   Robustness will be reduced if the compressor uses a jitter estimate
   which is too small.  Therefore, a FEEDBACK packet carrying a JITTER
   option SHOULD also carry a CRC option.  Moreover, the compressor MAY
   ignore decreasing Max_Jitter values.

5.7.6.9. The LOSS option
The LOSS option allows the decompressor to report the largest observed number of packets lost in sequence. This information MAY be used by the compressor to adjust the size of the reference window used in U- and O-mode. +---+---+---+---+---+---+---+---+ | Opt Type = 7 | Opt Len = 1 | +---+---+---+---+---+---+---+---+ | longest loss event (packets) | +---+---+---+---+---+---+---+---+ The decompressor MAY choose to ignore the oldest loss events. Thus, the value reported may decrease. Since setting the reference window too small can reduce robustness, a FEEDBACK packet carrying a LOSS option SHOULD also carry a CRC option. The compressor MAY choose to ignore decreasing loss values.
5.7.6.10. Unknown option types
If an option type unknown to the compressor is encountered, it must continue parsing the rest of the FEEDBACK packet, which is possible since the length of the option is explicit, but MUST otherwise ignore the unknown option.
5.7.6.11. RTP feedback example
Feedback for CID 8 indicating an ACK for SN 17 and Bidirectional Reliable mode can have the following formats.
Top   ToC   RFC3095 - Page 95
   Assuming small CIDs:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   0 | 0   1   1 |  feedback packet type, Code = 3
   +---+---+---+---+---+---+---+---+
   | 1   1   1   0 | 1   0   0   0 |  Add-CID octet with CID = 8
   +---+---+---+---+---+---+---+---+
   | 0   0 | 1   1 |  SN MSB = 0   |  AckType = ACK, Mode = Reliable
   +---+---+---+---+---+---+---+---+
   |          SN LSB = 17          |
   +---+---+---+---+---+---+---+---+

      The second, third, and fourth octet are handed to the compressor.

   The FEEDBACK-1 format may also be used.  Assuming large CIDs:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   0 | 0   1   0 |  feedback packet type, Code = 2
   +---+---+---+---+---+---+---+---+
   | 0   0   0   0   1   0   0   0 |  large CID with value 8
   +---+---+---+---+---+---+---+---+
   |          SN LSB = 17          |
   +---+---+---+---+---+---+---+---+

      The second and third octet are handed to the compressor.

   Assuming small CIDs:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   0 | 0   1   0 |  feedback packet type, Code = 2
   +---+---+---+---+---+---+---+---+
   | 1   1   1   0 | 1   0   0   0 |  Add-CID octet with CID = 8
   +---+---+---+---+---+---+---+---+
   |          SN LSB = 17          |
   +---+---+---+---+---+---+---+---+

      The second and third octet are handed to the compressor.
Top   ToC   RFC3095 - Page 96
   Assuming small CIDs and CID 0 instead of CID 8:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   0 | 0   0   1 |  feedback packet type, Code = 1
   +---+---+---+---+---+---+---+---+
   |          SN LSB = 17          |
   +---+---+---+---+---+---+---+---+

      The second octet is handed to the compressor.

5.7.7. RTP IR and IR-DYN packets

The subheaders which are compressible are split into a STATIC part and a DYNAMIC part. These parts are defined in sections 5.7.7.3 through 5.7.7.7. The structure of a chain of subheaders is determined by each header having a Next Header, or Protocol, field. This field identifies the type of the following header. Each Static part below that is followed by another Static part contains the Next Header/Protocol field and allows parsing of the Static chain; the Dynamic chain, if present, is structured analogously. IR and IR-DYN packets will cause a packet to be delivered to upper layers if and only if the payload is non-empty. This means that an IP/UDP/RTP packet where the UDP length indicates a UDP payload of size 12 octets cannot be represented by an IR or IR-DYN packet. Such packets can instead be represented using the UNCOMPRESSED profile (section 5.10).
5.7.7.1. Basic structure of the IR packet
This packet type communicates the static part of the context, i.e., the values of the constant SN functions. It can optionally also communicate the dynamic part of the context, i.e., the parameters of nonconstant SN functions. It can also optionally communicate the payload of an original packet, if any.
Top   ToC   RFC3095 - Page 97
     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 | D |
   +---+---+---+---+---+---+---+---+
   |                               |
   /    0-2 octets of CID info     /  1-2 octets if for large CIDs
   |                               |
   +---+---+---+---+---+---+---+---+
   |            Profile            |  1 octet
   +---+---+---+---+---+---+---+---+
   |              CRC              |  1 octet
   +---+---+---+---+---+---+---+---+
   |                               |
   |         Static chain          |  variable length
   |                               |
   +---+---+---+---+---+---+---+---+
   |                               |
   |         Dynamic chain         |  present if D = 1, variable length
   |                               |
    - - - - - - - - - - - - - - - -
   |                               |
   |           Payload             |  variable length
   |                               |
    - - - - - - - - - - - - - - - -

      D:   D = 1 indicates that the dynamic chain is present.

      Profile: Profile identifier, abbreviated as defined in section
          5.2.3.

      CRC: 8-bit CRC, computed according to section 5.9.1.

      Static chain: A chain of static subheader information.

      Dynamic chain: A chain of dynamic subheader information.  What
          dynamic information is present is inferred from the Static
          chain.

      Payload: The payload of the corresponding original packet, if any.
          The presence of a payload is inferred from the packet length.
Top   ToC   RFC3095 - Page 98
5.7.7.2. Basic structure of the IR-DYN packet
This packet type communicates the dynamic part of the context, i.e., the parameters of nonconstant SN functions. 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 packet type +---+---+---+---+---+---+---+---+ : : / 0-2 octets of CID info / 1-2 octets if for large CIDs : : +---+---+---+---+---+---+---+---+ | Profile | 1 octet +---+---+---+---+---+---+---+---+ | CRC | 1 octet +---+---+---+---+---+---+---+---+ | | / Dynamic chain / variable length | | +---+---+---+---+---+---+---+---+ : : / Payload / variable length : : - - - - - - - - - - - - - - - - Profile: Profile identifier, abbreviated as defined in section 5.2.3. CRC: 8-bit CRC, computed according to section 5.9.1. NOTE: As the CRC checks only the integrity of the header itself, an acknowledgment of this header does not signify that previous changes to the static chain in the context are also acknowledged. In particular, care should be taken when IR packets that update an existing context are followed by IR-DYN packets. Dynamic chain: A chain of dynamic subheader information. What dynamic information is present is inferred from the Static chain of the context. Payload: The payload of the corresponding original packet, if any. The presence of a payload is inferred from the packet length.
Top   ToC   RFC3095 - Page 99
   Note: The static and dynamic chains of IR or IR-DYN packets for
   profile 0x0001 (ROHC RTP) MUST end with the static and dynamic parts
   of an RTP header.  If not, the packet MUST be discarded and the
   context MUST NOT be updated.

   Note: The static or dynamic chains of IR or IR-DYN packets for
   profile 0x0002 (ROHC UDP) MUST end with the static and dynamic parts
   of a UDP header.  If not, the packet MUST be discarded and the
   context MUST NOT be updated.

   Note: The static or dynamic chains of IR or IR-DYN packets for
   profile 0x0003 (ROHC ESP) MUST end with the static and dynamic parts
   of an ESP header.  If not, the packet MUST be discarded and the
   context MUST NOT be updated.

5.7.7.3. Initialization of IPv6 Header [IPv6]
Static part: +---+---+---+---+---+---+---+---+ | Version = 6 |Flow Label(msb)| 1 octet +---+---+---+---+---+---+---+---+ / Flow Label (lsb) / 2 octets +---+---+---+---+---+---+---+---+ | Next Header | 1 octet +---+---+---+---+---+---+---+---+ / Source Address / 16 octets +---+---+---+---+---+---+---+---+ / Destination Address / 16 octets +---+---+---+---+---+---+---+---+ Dynamic part: +---+---+---+---+---+---+---+---+ | Traffic Class | 1 octet +---+---+---+---+---+---+---+---+ | Hop Limit | 1 octet +---+---+---+---+---+---+---+---+ / Generic extension header list / variable length +---+---+---+---+---+---+---+---+ Eliminated: Payload Length
Top   ToC   RFC3095 - Page 100
   Extras:

      Generic extension header list: Encoded according to section
      5.8.6.1, with all header items present in uncompressed form.

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

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

   CRC coverage for extension headers is defined in section 5.8.7.

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

5.7.7.4. Initialization of IPv4 Header [IPv4, section 3.1].
Static part: Version, Protocol, Source Address, Destination Address. +---+---+---+---+---+---+---+---+ | Version = 4 | 0 | +---+---+---+---+---+---+---+---+ | Protocol | +---+---+---+---+---+---+---+---+ / Source Address / 4 octets +---+---+---+---+---+---+---+---+ / Destination Address / 4 octets +---+---+---+---+---+---+---+---+ Dynamic part: Type of Service, Time to Live, Identification, DF, RND, NBO, extension header list. +---+---+---+---+---+---+---+---+ | Type of Service | +---+---+---+---+---+---+---+---+ | Time to Live | +---+---+---+---+---+---+---+---+ / Identification / 2 octets +---+---+---+---+---+---+---+---+ | DF|RND|NBO| 0 | +---+---+---+---+---+---+---+---+ / Generic extension header list / variable length +---+---+---+---+---+---+---+---+
Top   ToC   RFC3095 - Page 101
   Eliminated:

      IHL               (IP Header Length, must be 5)
      Total Length      (inferred in decompressed packets)
      MF flag           (More Fragments flag, must be 0)
      Fragment Offset   (must be 0)
      Header Checksum   (inferred in decompressed packets)
      Options, Padding  (must not be present)

      Extras:

         RND, NBO           See section 5.7.

         Generic extension header list: Encoded according to section
         5.8.6.1, with all header items present in uncompressed form.

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

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

   CRC coverage for extension headers is defined in section 5.8.7.

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

5.7.7.5. Initialization of UDP Header [RFC-768].
Static part: +---+---+---+---+---+---+---+---+ / Source Port / 2 octets +---+---+---+---+---+---+---+---+ / Destination Port / 2 octets +---+---+---+---+---+---+---+---+ Dynamic part: +---+---+---+---+---+---+---+---+ / Checksum / 2 octets +---+---+---+---+---+---+---+---+
Top   ToC   RFC3095 - Page 102
   Eliminated:

      Length

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

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

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

5.7.7.6. Initialization of RTP Header [RTP].
Static part: SSRC. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ / SSRC / 4 octets +---+---+---+---+---+---+---+---+ Dynamic part: P, X, CC, PT, M, sequence number, timestamp, timestamp stride, CSRC identifiers. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | V=2 | P | RX| CC | (RX is NOT the RTP X bit) +---+---+---+---+---+---+---+---+ | M | PT | +---+---+---+---+---+---+---+---+ / RTP Sequence Number / 2 octets +---+---+---+---+---+---+---+---+ / RTP Timestamp (absolute) / 4 octets +---+---+---+---+---+---+---+---+ / Generic CSRC list / variable length +---+---+---+---+---+---+---+---+ : Reserved | X | Mode |TIS|TSS: if RX = 1 +---+---+---+---+---+---+---+---+ : TS_Stride : 1-4 octets, if TSS = 1 +---+---+---+---+---+---+---+---+ : Time_Stride : 1-4 octets, if TIS = 1 +---+---+---+---+---+---+---+---+
Top   ToC   RFC3095 - Page 103
   Eliminated:

      Nothing.

   Extras:

      RX: Controls presence of extension.

      Mode: Compression mode. 0 = Reserved,
                              1 = Unidirectional,
                              2 = Bidirectional Optimistic,
                              3 = Bidirectional Reliable.

   X: Copy of X bit from RTP header (presumed 0 if RX = 0)

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

   Generic CSRC list: CSRC list encoded according to section
          5.8.6.1, with all CSRC items present.

   CRC-DYNAMIC: Octets containing M-bit, sequence number field,
                and timestamp (octets 2-8).

   CRC-STATIC: All other fields (octets 1, 9-12, original CSRC list).

5.7.7.7. Initialization of ESP Header [ESP, section 2]
This is for the case when the NULL encryption algorithm [NULL] is NOT being used with ESP, so that subheaders after the ESP header are encrypted (see 5.12). See 5.8.4.3 for compression of the ESP header when NULL encryption is being used. Static part: +---+---+---+---+---+---+---+---+ / SPI / 4 octets +---+---+---+---+---+---+---+---+ Dynamic part: +---+---+---+---+---+---+---+---+ / Sequence Number / 4 octets +---+---+---+---+---+---+---+---+ Eliminated: Other fields are encrypted, and can neither be located nor compressed.
Top   ToC   RFC3095 - Page 104
   CRC-DYNAMIC: Sequence number (octets 5-8)

   CRC-STATIC: All other octets.

   Note: No encrypted data is considered to be part of the header for
   purposes of computing the CRC, i.e., octets after the eight octet are
   not considered part of the header.

5.7.7.8. Initialization of Other Headers
Headers not explicitly listed in previous subsections can be compressed only by making them part of an extension header chain following an IPv4 or IPv6 header, see section 5.8.

5.8. List compression

Header information from the packet stream to be compressed can be structured as an ordered list, which is largely constant between packets. The generic structure of such a list is as follows. +--------+--------+--...--+--------+ list: | item 1 | item 2 | | item n | +--------+--------+--...--+--------+ This section describes the compression scheme for such information. The basic principles of list-based compression are the following: 1) While the list is constant, no information about the list is sent in compressed headers. 2) Small changes in the list are represented as additions (Insertion scheme), or deletions (Removal scheme), or both (Remove Then Insert scheme). 3) The list can also be sent in its entirety (Generic scheme). There are two kinds of lists: CSRC lists in RTP packets, and extension header chains in IP packets (both IPv4 and IPv6). IPv6 base headers and IPv4 headers cannot be part of an extension header chain. Headers which can be part of extension header chains include a) the AH header b) the null ESP header c) the minimal encapsulation header [RFC2004, section 3.1] d) the GRE header [GRE1, GRE2] e) IPv6 extension headers.
Top   ToC   RFC3095 - Page 105
   The table-based item compression scheme (5.8.1), which reduces the
   size of each item, is described first.  Then it is defined which
   reference list to use in the insertion and removal schemes (5.8.2).
   List encoding schemes are described in section 5.8.3, and a few
   special cases in section 5.8.4.  Finally, exact formats are described
   in sections 5.8.5-5.8.6.

5.8.1. Table-based item compression

The Table-based item compression scheme is a way to compress individual items sent in compressed lists. The compressor assigns each item in a list a unique identifier Index. The compressor conceptually maintains a table with all items, indexed by Index. The (Index, item) pair is sent together in compressed lists until the compressor gains enough confidence that the decompressor has observed the mapping between the item and its Index. Such confidence is obtained by receiving an acknowledgment from the decompressor in R- mode, and in U/O-mode by sending L (Index, item) pairs (not necessarily consecutively). After that, the Index alone is sent in compressed lists to indicate the corresponding item. The compressor may reassign an existing Index to a new item, and then needs to re- establish the mapping in the same manner as above. The decompressor conceptually maintains a table that contains all (Index, item) pairs it knows about. The table is updated whenever an (Index, item) pair is received (and decompression is verified by a CRC). The decompressor retrieves the item from the table whenever an Index without an accompanying item is received.
5.8.1.1. Translation table in R-mode
At the compressor side, an entry in the Translation Table has the following structure. +-------+------+---------------+ Index i | Known | item | SN1, SN2, ... | +-------+------+---------------+ The Known flag indicates whether the mapping between Index i and item has been established, i.e., if Index i alone can be sent in compressed lists. Known is initially zero. It is also set to zero whenever Index i is assigned to a new item. Known is set to one when the corresponding (Index, item) pair is acknowledged. Acknowledgments are based on the RTP Sequence Number, so a list of RTP Sequence Numbers of all packets which contain the (Index, item) pair is included in the translation table. When a packet with a sequence number in the sequence number list is acknowledged, the Known flag is set, and the sequence number list can be discarded.
Top   ToC   RFC3095 - Page 106
   Each entry in the Translation Table at the decompressor side has the
   following structure:

              +-------+------+
      Index i | Known | item |
              +-------+------+

   All Known fields are initialized to zero.  Whenever the decompressor
   receives an (Index, item) pair, it inserts item into the table at
   position Index and sets the Known flag in that entry to one.  If an
   index without an accompanying item is received for which the Known
   flag is zero, the header MUST be discarded and a NACK SHOULD be sent.

5.8.1.2. Translation table in U/O-modes
At the compressor side, each entry in the Translation Table has the following structure: +-------+------+---------+ Index | Known | item | Counter | +-------+------+---------+ The Index, Known, and item fields have the same meaning as in section 5.8.1.1. Known is set when the (Index, item) pair has been sent in L compressed lists (not necessarily consecutively). The Counter field keeps track of how many times the pair has been sent. Counter is set to 0 for each new entry added to the table, and whenever Index is assigned to a new item. Counter is incremented by 1 whenever an (Index, item) pair is sent. When the counter reaches L, the Known field is set and after that only the Index needs to be sent in compressed lists. At the decompressor side, the Translation Table is the same as the Translation Table defined in R-mode.

5.8.2. Reference list determination

In reference based compression schemes (i.e., addition or deletion based schemes), compression and decompression of a list (curr_list) are based on a reference list (ref_list) which is assumed to be present in the context of both compressor and decompressor. The compressed list is an encoding of the differences between curr_list and ref_list. Upon reception of a compressed list, the decompressor applies the differences to its reference list in order to obtain the original list.
Top   ToC   RFC3095 - Page 107
   To identify the reference list (to be) used, each compressed list
   carries an identifier (ref_id).  The reference list is established by
   different methods in R-mode and U/O-mode.

5.8.2.1. Reference list in R-mode and U/O-mode
In R-mode, the choice of reference list is based on acknowledgments, i.e., the compressor uses as ref_list the latest list which has been acknowledged by the decompressor. The ref_list is updated only upon receiving an acknowledgment. The least significant bits of the RTP Sequence Number of the acknowledged packet are used as the ref_id. In U/O-mode, a sequence of identical lists are considered as belonging to the same generation and are all assigned the same generation identifier (gen_id). Gen_id increases by 1 each time the list changes and is carried in compressed and uncompressed lists that are candidates for being used as reference lists. Normally, Gen_id must have been repeated in at least L headers before the list can be used as a ref_list. However, some acknowledgments may be sent in O- mode (and also in U-mode), and whenever an acknowledgment for a header is received, the list of that header is considered known and need not be repeated further. The least significant bits of the Gen_id is used as the ref_id in U/O-mode. The logic of the compressor and decompressor for reference based list compression is similar to that for SN and TS. The principal difference is that the decompressor maintains a sliding window with candidates for ref_list, and retrieves ref_list from the sliding window using the ref_id of the compressed list. Logic of compressor: a) In the IR state, the compressor sends Generic lists (see 5.8.5) containing all items of the current list in order to establish or refresh the context of the decompressor. In R-mode, such Generic lists are sent until a header is acknowledged. The list of that header can be used as a reference list to compress subsequent lists. In U/O-mode, the compressor sends generation identifiers with the Generic lists until 1) a generation identifier has been repeated L times, or 2) an acknowledgment for a header carrying a generation identifier has been received.
Top   ToC   RFC3095 - Page 108
      The repeated (1) or acknowledged (2) list can be used as a
      reference list to compress subsequent lists and is kept together
      with its generation identifier.

   b) When not in the IR state, the compressor moves to the FO state
      when it observes a difference between curr_list and the previous
      list.  It sends compressed lists based on ref_list to update the
      context of the decompressor.  (However, see d).)

      In R-mode, the compressor keeps sending compressed lists using the
      same reference until it receives an acknowledgment for a packet
      containing the newest list.  The compressor may then move to the
      SO state with regard to the list.

      In U/O-mode, the compressor keeps sending compressed lists with
      generation identifiers until

      1) a generation identifier has been repeated L times, or

      2) an acknowledgment for a header carrying the latest generation
         identifier has been received.

      The repeated or acknowledged list is used as the future reference
      list.  The compressor may move to the SO state with regard to the
      list.

   c) In R-mode, the compressor maintains a sliding window containing
      the lists which have been sent to update the context of the
      decompressor and have not yet been acknowledged.  The sliding
      window shrinks when an acknowledgment arrives: all lists sent
      before the acknowledged list are removed.  The compressor may use
      the Index to represent items of lists in the sliding window.

      In U/O-mode, the compressor needs to store

      1) the reference list and its generation identifier, and

      2) if the current generation identifier is different from the
         reference generation, the current list and the sequence
         numbers with which the current list has been sent.

      (2) is needed to determine if an acknowledgment concerns the
          latest generation.  It is not needed in U-mode.

   d) In U/O-mode, the compressor may choose to not send a generation
      identifier with a compressed list.  Such lists without generation
      identifiers are not assigned a new generation identifier and must
Top   ToC   RFC3095 - Page 109
      not be used as future reference lists.  They do not update the
      context.  This feature is useful when a new list is repeated few
      times and the list then reverts back to its old value.

   Logic of decompressor:

   e) In R-mode, the decompressor acknowledges all received uncompressed
      or compressed lists which establish or update the context.  (Such
      compressed headers contain a CRC.)

      In O-mode, the decompressor MAY acknowledge a list with a new
      generation identifier, see section 5.4.2.2.

      In U-mode, the decompressor MAY acknowledge a list sent in an IR
      packet, see section 5.3.2.3.

   f) The decompressor maintains a sliding window which contains the
      lists that may be used as reference lists.

      In R-mode, the sliding window contains lists which have been
      acknowledged but not yet used as reference lists.

      In U/O-mode, the sliding window contains at most one list per
      generation.  It contains all generations seen by the decompressor
      newer than the last generation used as a reference.

   g) When the decompressor receives a compressed list, it retrieves the
      proper ref_list from the sliding window based on the ref_id, and
      decompresses the compressed list obtaining curr_list.

      In R-mode, curr_list is inserted into the sliding window if an
      acknowledgment is sent for it.  The sliding window is shrunk by
      removing all lists received before ref_list.

      In U/O-mode, curr_list is inserted into the sliding window
      together with its generation identifier if the compressed list had
      a generation identifier and the sliding window does not contain a
      list with that generation identifier.  All lists with generations
      older than ref_id are removed from the sliding window.

5.8.3. Encoding schemes for the compressed list

Four encoding schemes for the compressed list are described here. The exact formats of the compressed CSRC list and compressed IP extension header list using these encoding schemes are described in sections 5.8.5-5.8.6.
Top   ToC   RFC3095 - Page 110
   Generic scheme

      In contrast to subsequent schemes, this scheme does not rely on a
      reference list having been established.  The entire list is sent,
      using table based compression for each individual item.  The
      generic scheme is always used when establishing the context of the
      decompressor and may also be used at other times, as the
      compressor sees fit.

   Insertion Only scheme

      When the new list can be constructed from ref_list by adding
      items, a list of the added items is sent (using table based
      compression), along with the positions in ref_list where the new
      items will be inserted.  An insertion bit mask indicates the
      insertion positions in ref_list.

      Upon reception of a list compressed according to the Insertion
      Only scheme, curr_list is obtained by scanning the insertion bit
      mask from left to right.  When a '0' is observed, an item is
      copied from the ref_list.  When a '1' is observed, an item is
      copied from the list of added items.  If a '1' is observed when
      the list of added items has been exhausted, an error has occurred
      and decompression fails: The header MUST NOT be delivered to upper
      layers; it should be discarded, and MUST NOT be acknowledged nor
      used as a reference.

      To construct the insertion bit mask and the list of added items,
      the compressor MAY use the following algorithm:

      1) An empty bit list and an empty Inserted Item list are generated
         as the starting point.

      2) Start by considering the first item of curr_list and ref_list.

      3) If curr_list has a different item than ref_list,

            a set bit (1) is appended to the bit list;
            the first item in curr_list (represented using table-based
            item compression) is appended to the Inserted Item list;
            advance to the next item of curr_list;

      otherwise,

            a zero bit (0) is appended to the bit list;

            advance to the next item of curr_list;
            advance to the next item of ref_list.
Top   ToC   RFC3095 - Page 111
      4) Repeat 3) until curr_list has been exhausted.

      5) If the length of the bit list is less than the required bit
         mask length, append additional zeroes.

   Removal Only scheme

      This scheme can be used when curr_list can be obtained by removing
      some items in ref_list.  The positions of the items which are in
      ref_list, but not in curr_list, are sent as a removal bit mask.

      Upon reception of the compressed list, the decompressor obtains
      curr_list by scanning the removal bit mask from left to right.
      When a '0' is observed, the next item of ref_list is copied into
      curr_list.  When a '1' is observed, the next item of ref_list is
      skipped over without being copied.  If a '0' is observed when
      ref_list has been exhausted, an error has occurred and
      decompression fails: The header MUST NOT be delivered to upper
      layers; it should be discarded, and MUST NOT be acknowledged nor
      used as a reference.

      To construct the removal bit mask and the list of added items, the
      compressor MAY use the following algorithm:

      1) An empty bit list is generated as the starting point.

      2) Start by considering the first item of curr_list and ref_list.

      3) If curr_list has a different item than ref_list,

         a set bit (1) is appended to the bit list;
         advance to the next item of ref_list;

      otherwise,

         a zero bit (0) is appended to the bit list;
         advance to the next item of curr_list;
         advance to the next item of ref_list.

      4) Repeat 3) until curr_list has been exhausted.

      5) If the length of the bit list is less than the required bit
         mask length, append additional ones.
Top   ToC   RFC3095 - Page 112
   Remove Then Insert scheme

      In this scheme, curr_list is obtained by first removing items from
      ref_list, and then inserting items into the resulting list.  A
      removal bit mask, an insertion bit mask, and a list of added items
      are sent.

      Upon reception of the compressed list, the decompressor processes
      the removal bit mask as in the Removal Only scheme.  The resulting
      list is then used as the reference list when the insertion bit
      mask and the list of added items are processed, as in the
      Insertion Only scheme.

5.8.4. Special handling of IP extension headers

In CSRC list compression, each CSRC is assigned an index. In contrast, in IP extension header list compression an index is usually associated with a type of extension header. When there is more than one IP header, there is more than one list of extension headers. An index per type per list is then used. The association with a type means that a new index need not always be used each time a field in an IP extension header changes. However, when a field in an extension header changes, the mapping between the index and the new value of the extension header needs to be established, except in the special handling cases defined in the following subsections.
5.8.4.1. Next Header field
The next header field in an IP header or extension header changes whenever the type of the immediately following header changes, e.g., when a new extension header is inserted after it, when the immediate subsequent extension header is removed from the list, or when the order of extension headers is changed. Thus it may not be uncommon that, for a given header, the next header field changes while the remaining fields do not change. Therefore, in the case that only the next header field changes, the extension header is considered to be unchanged and rules for special treatment of the change in the next header field are defined below. All communicated uncompressed extension header items indicate their own type in their Next Header field. Note that the rules below explain how to treat the Next Header fields while showing the conceptual reference list as an exact recreation of the original uncompressed extension header list.
Top   ToC   RFC3095 - Page 113
   a) When a subsequent extension header is removed from the list, the
      new value of the next header field is obtained from the reference
      extension header list.  For example, assume that the reference
      header list (ref_list) consists of headers A, B and C (ref_ext_hdr
      A, B, C), and the current extension header list (curr_list) only
      consists of extension headers A and C (curr_ext_hdr A, C).  The
      order and value of the next header fields of these extension
      headers are as follows.

   ref_list:
   +--------+-----+    +--------+-----+    +--------+-----+
   | type B |     |    | type C |     |    | type D |     |
   +--------+     |    +--------+     |    +--------+     |
   |              |    |              |    |              |
   +--------------+    +--------------+    +--------------+
   ref_ext_hdr A        ref_ext_hdr B       ref_ext_hdr C

    curr_list:
   +--------+-----+    +--------+-----+
   | type C |     |    | type D |     |
   +--------+     |    +--------+     |
   |              |    |              |
   +--------------+    +--------------+
    curr_ext_hdr A      curr_ext_hdr C

      Comparing the curr_ext_hdr A in curr_list and the ref_ext_hdr A in
      ref_list, the value of next header field is changed from "type B"
      to "type C" because of the removal of extension header B.  The new
      value of the next header field in curr_ext_hdr A, i.e., "type C",
      does not need to be sent to the decompressor.  Instead, it is
      retrieved from the next header field of the removed ref_ext_hdr B.

   b) When a new extension header is inserted after an existing
      extension header, the next header field in the communicated item
      will carry the type of itself, rather than the type of the header
      that follows.  For example, assume that the reference header list
      (ref_list) consists of headers A and C (ref_ext_hdr A, C), and the
      current header list (curr_list) consists of headers A, B and C
      (curr_ext_hdr A, B, C).  The order and the value of the next
      header fields of these extension headers are as follows.
Top   ToC   RFC3095 - Page 114
   ref_list:
   +--------+-----+    +--------+-----+
   | type C |     |    | type D |     |
   +--------+     |    +--------+     |
   |              |    |              |
   +--------------+    +--------------+
    ref_ext_hdr A        ref_ext_hdr C

   curr_list:
   +--------+-----+    +--------+-----+    +--------+-----+
   | type B |     |    | type C |     |    | type D |     |
   +--------+     |    +--------+     |    +--------+     |
   |              |    |              |    |              |
   +--------------+    +--------------+    +--------------+
    curr_ext_hdr A      curr_ext_hdr B      curr_ext_hdr C

      Comparing the curr_list and the ref_list, the value of the next
      header field in extension header A is changed from "type C" to
      "type B".

      The uncompressed curr_ext_hdr B is carried in the compressed
      header list.  However, it carries "type B" instead of "type C" in
      its next header field.  When the decompressor inserts a new header
      after curr_ext_hdr A, the next header field of A is taken from the
      new header, and the next header field of the new header is taken
      from ref_ext_hdr A.

   c) Some headers whose compression is defined in this document do not
      contain Next Header fields or do not have their Next Header field
      in the standard position (first octet of the header).  The GRE and
      ESP headers are such headers.  When sent as uncompressed items in
      lists, these headers are modified so that they do have a Next
      Header field as their first octet (see 5.8.4.3 and 5.8.4.4).  This
      is necessary to enable the decompressor to decode the item.

5.8.4.2. Authentication Header (AH)
The sequence number field in the AH [AH] contains a monotonically increasing counter value for a security association. Therefore, when comparing curr_list with ref_list, if the sequence number in AH changes and SPI field does not change, the AH is not considered as changed. If the sequence number in the AH linearly increases as the RTP Sequence Number increases, and the compressor is confident that the decompressor has obtained the pattern, the sequence number in AH need not be sent. The decompressor applies linear extrapolation to reconstruct the sequence number in the AH.
Top   ToC   RFC3095 - Page 115
   Otherwise, a compressed sequence number is included in the IPX
   compression field in an Extension 3 of an UOR-2 header.

   The authentication data field in AH changes from packet to packet and
   is sent as-is.  If the uncompressed AH is sent, the authentication
   data field is sent inside the uncompressed AH; otherwise, it is sent
   after the compressed IP/UDP/RTP and IPv6 extension headers and before
   the payload.  See beginning of section 5.7.

   Note: The payload length field of the AH uses a different notion of
   length than other IPv6 extension headers.

5.8.4.3. Encapsulating Security Payload Header (ESP)
When the Encapsulating Security Payload Header (ESP) [ESP] is present and an encryption algorithm other than NULL is being used, the UDP and RTP headers are both encrypted and cannot be compressed. The ESP header thus ends the compressible header chain. The ROHC ESP profile defined in section 5.12 MAY be used for the stream in this case. A special case is when the NULL encryption algorithm is used. This is the case when the ESP header is used for authentication only, and not for encryption. The payload is not encrypted by the NULL encryption algorithm, so compression of the rest of the header chain is possible. The rest of this section describes compression of the ESP header when the NULL encryption algorithm is used with ESP. It is not possible to determine whether NULL encryption is used by inspecting a header in the stream, this information is present only at the encryption endpoints. However, a compressor may attempt compression under the assumption that the NULL encryption algorithm is being used, and later abort compression when the assumption proves to be false. The compressor may, for example, inspect the Next Header fields and the header fields supposed to be static in subsequent headers in order to determine if NULL encryption is being used. If these change unpredictably, an encryption algorithm other than NULL is probably being used and compression of subsequent headers SHOULD be aborted. Compression of the stream is then either discontinued, or a profile that compresses only up to the ESP header may be used (see 5.12). While attempting to compress the header, the compressor should use the SPI of the ESP header together with the destination IP address as the defining fields for determining which packets belong to the stream.
Top   ToC   RFC3095 - Page 116
   In the ESP header [ESP, section 2], the fields that can be compressed
   are the SPI, the sequence number, the Next Header, and the padding
   bytes if they are in the standard format defined in [ESP]. (As
   always, the decompressor reinserts these fields based on the
   information in the context.  Care must be taken to correctly reinsert
   all the information as the Authentication Data must be verified over
   the exact same information it was computed over.)

   ESP header [ESP, section 2]:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Security Parameters Index (SPI)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sequence Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Payload Data (variable)                    |
   ~                                                               ~
   |                                                               |
   +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |     Padding (0-255 octets)                    |
   +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |  Pad Length   | Next Header   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Authentication Data                       |
   +        (variable length, but assumed to be 12 octets)         +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      SPI: Static.  If it changes, it needs to be reestablished.

      Sequence Number: Not sent when the offset from the sequence number
          of the compressed header is constant.  When the offset is not
          constant, the sequence number may be compressed by sending
          LSBs.  See 5.8.4.

      Payload Data: This is where subsequent headers are to be found.
          Parsed according to the Next Header field.

      Padding: The padding octets are assumed to be as defined in [ESP],
          i.e., to take the values 1, 2, ..., k, where k = Pad Length.
          If the padding in the static context has this pattern, padding
          in compressed headers is assumed to have this pattern as well
          and is removed.  If padding in the static context does not
          have this pattern, the padding is not removed.
Top   ToC   RFC3095 - Page 117
      Pad Length: Dynamic.  Always sent.  14th octet from end of packet.

      Next Header: Static.  13th octet from end of packet.

   Authentication Data: Can have variable length, but when compression
   of NULL-encryption ESP header is attempted, it is assumed to have
   length 12 octets.

   The sequence number in ESP has the same behavior as the sequence
   number field in AH.  When it increases linearly, it can be compressed
   to zero bits.  When it does not increase linearly, a compressed
   sequence number is included in the IPX compression field in an
   Extension 3 of an UOR-2 header.

   The information which is part of an uncompressed item of a compressed
   list is the Next Header field, followed by the SPI and the Sequence
   Number.  Padding, Pad Length, Next Header, and Authentication Data
   are sent as-is at the end of the packet.  This means that the Next
   Header occurs in two places.

   Uncompressed ESP list item:

       +---+---+---+---+---+---+---+---+
      |          Next Header          !  1 octet (see section 5.8.4.1)
      +---+---+---+---+---+---+---+---+
      /              SPI              /  4 octets
      +---+---+---+---+---+---+---+---+
      /        Sequence Number        /  4 octets
      +---+---+---+---+---+---+---+---+

      When sending Uncompressed ESP list items, all ESP fields near the
      the end of the packet are left untouched (Padding, Pad Length,
      Next Header, Authentication Data).

   A compressed item consists of a compressed sequence number.  When an
   item is compressed, Padding (if it follows the 1, 2, ..., k pattern)
   and Next Header are removed near the end of the packet.
   Authentication Data and Pad Length remain as-is near the end of the
   packet.

5.8.4.4. GRE Header [RFC 2784, RFC 2890]
The GRE header is a set of flags, followed by a mandatory Protocol Type and optional parts as indicated by the flags.
Top   ToC   RFC3095 - Page 118
   The sequence number field in the GRE header contains a counter value
   for a GRE tunnel.  Therefore, when comparing curr_list with ref_list,
   if the sequence number in GRE changes, the GRE is not considered as
   changed.

   If the sequence number in the GRE header linearly increases as the
   RTP Sequence Number increases and the compressor is confident that
   the decompressor has received the pattern, the sequence number in GRE
   need not be sent.  The decompressor applies linear extrapolation to
   reconstruct the sequence number in the GRE header.

   Otherwise, a compressed sequence number is included in the IPX
   compression field in an Extension 3 of an UOR-2 header.

   The checksum data field in GRE, if present, changes from packet to
   packet and is sent as-is.  If the uncompressed GRE header is sent,
   the checksum data field is sent inside the uncompressed GRE header;
   otherwise, if present, it is sent after the compressed IP/UDP/RTP and
   IPv6 extension headers and before the payload.  See beginning of
   section 5.7.

   In order to allow simple parsing of lists of items, an uncompressed
   GRE header sent as an item in a list is modified from the original
   GRE header in the following manner: 1) the 16-bit Protocol Type field
   that encodes the type of the subsequent header using Ether types (see
   Ether types section in [ASSIGNED]) is removed.  2) A one-octet Next
   Header field is inserted as the first octet of the header.  The value
   of the Next Header field corresponds to GRE (this value is 47
   according to the Assigned Internet Protocol Number section of
   [ASSIGNED]) when the uncompressed item is to be inserted in a list,
   and to the type of the subsequent header when the uncompressed item
   is in a Generic list.  Note that this implies that only GRE headers
   with Ether types that correspond to an IP protocol number can be
   compressed.

   Uncompressed GRE list item:

      +---+---+---+---+---+---+---+---+
      |          Next Header          !  1 octet (see section 5.8.4.1)
      +---+---+---+---+---+---+---+---+
      / C |   | K | S |   |    Ver    |  1 octet
      +---+---+---+---+---+---+---+---+
      /           Checksum            /  2 octets, if C=1
      +---+---+---+---+---+---+---+---+
      /              Key              /  4 octets, if K=1
      +---+---+---+---+---+---+---+---+
      /        Sequence Number        /  4 octets, if S=1
      +---+---+---+---+---+---+---+---+
Top   ToC   RFC3095 - Page 119
      The bits left blank in the second octet are set to zero when
      sending and ignored when received.

      The fields Reserved0 and Reserved1 of the GRE header [GRE2] must
      be all zeroes; otherwise, the packet cannot be compressed by this
      profile.



(page 119 continued on part 6)

Next Section