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.

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

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

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 }

   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.

   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.

   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.

     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.

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.

   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

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

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

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

   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.

   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.

   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.

   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.

   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.

      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

      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.

   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.

      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.

   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.

   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.

   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.

   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.

   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.

      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.

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

      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.