tech-invite   World Map     

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

RFC 3095

 
 
 

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

Part 6 of 7, p. 119 to 151
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 119 
5.8.5.  Format of compressed lists in Extension 3

5.8.5.1.  Format of IP Extension Header(s) field

   In Extension 3 (section 5.7.5), there is a field called IP extension
   header(s).  This section describes the format of that field.

         0     1     2     3     4     5     6     7
      +-----+-----+-----+-----+-----+-----+-----+-----+
      | CL  | ASeq| ESeq| Gseq|          res          |  1 octet
      +-----+-----+-----+-----+-----+-----+-----+-----+
      :    compressed AH Seq Number,  1 or 4 octets   :  if ASeq = 1
       ----- ----- ----- ----- ----- ----- ----- -----
      :    compressed ESP Seq Number, 1 or 4 octets   :  if Eseq = 1
       ----- ----- ----- ----- ----- ----- ----- -----
      :    compressed GRE Seq Number, 1 or 4 octets   :  if Gseq = 1
       ----- ----- ----- ----- ----- ----- ----- -----
      :    compressed header list, variable length    :  if CL = 1
       ----- ----- ----- ----- ----- ----- ----- -----

      ASeq: indicates presence of compressed AH Seq Number
      ESeq: indicates presence of compressed ESP Seq Number
      GSeq: indicates presence of compressed GRE Seq Number
      CL:   indicates presence of compressed header list
      res:  reserved; set to zero when sending, ignored when received

   When Aseq, Eseq, or Gseq is set, the corresponding header item (AH,
   ESP, or GRE header) is compressed.  When not set, the corresponding
   header item is sent uncompressed or is not present.

   The format of compressed AH, ESP and GRE Sequence Numbers can each be
   either of the following:

Top      Up      ToC       Page 120 
     0   1   2   3   4   5   6   7       0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+   +---+---+---+---+---+---+---+---+
   | 0 |   LSB of sequence number  |   | 1 |                           |
   +---+---+---+---+---+---+---+---+   +---+                           +
                                       |                               |
                                       +     LSB of sequence number    +
                                       |                               |
                                       +                               +
                                       |                               |
                                       +---+---+---+---+---+---+---+---+

   The format of the compressed header list field is described in
   section 5.8.6.

5.8.5.2.  Format of Compressed CSRC List

   The Compressed CSRC List field in the RTP header part of an Extension
   3 (section 5.7.5) is as in section 5.8.6.

5.8.6.  Compressed list formats

   This section describes the format of compressed lists.  The format is
   the same for CSRC lists and header lists.  In CSRC lists, the items
   are CSRC identifiers; in header lists, they are uncompressed or
   compressed headers, as described in 5.8.4.2-4.

5.8.6.1.  Encoding Type 0 (generic scheme)

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | ET=0  |GP |PS |    CC = m     |
   +---+---+---+---+---+---+---+---+
   :            gen_id             :  1 octet, if GP = 1
   +---+---+---+---+---+---+---+---+
   |        XI 1, ..., XI m        |  m octets, or m * 4 bits
   /                --- --- --- ---/
   |               :    Padding    :  if PS = 0 and m is odd
   +---+---+---+---+---+---+---+---+
   |                               |
   /       item 1, ..., item n     /  variable
   |                               |
   +---+---+---+---+---+---+---+---+

      ET: Encoding type is zero.

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

Top      Up      ToC       Page 121 
      GP: Indicates presence of gen_id field.

      CC: CSRC counter from original RTP header.

      gen_id: Identifier for a sequence of identical lists.  It is
         present in U/O-mode when the compressor decides that it may use
         this list as a future reference list.

      XI 1, ..., XI m: m XI items.  The format of an XI item is as
            follows:

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

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

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

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

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

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

      Item 1, ..., item n:

         Each item corresponds to an XI with X = 1 in XI 1, ..., XI m.

Top      Up      ToC       Page 122 
5.8.6.2.  Encoding Type 1 (insertion only scheme)

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | ET=1  |GP |PS |     XI 1      |
   +---+---+---+---+---+---+---+---+
   :            gen_id             :  1 octet, if GP = 1
   +---+---+---+---+---+---+---+---+
   |            ref_id             |
   +---+---+---+---+---+---+---+---+
   /      insertion bit mask       /  1-2 octets
   +---+---+---+---+---+---+---+---+
   |            XI list            |  k octets, or (k - 1) * 4 bits
   /                --- --- --- ---/
   |               :    Padding    :  if PS = 0 and k is even
   +---+---+---+---+---+---+---+---+
   |                               |
   /       item 1, ..., item n     /  variable
   |                               |
   +---+---+---+---+---+---+---+---+

   Unless explicitly stated otherwise, fields have the same meaning and
   values as for encoding type 0.

      ET: Encoding type is one (1).

      XI 1: When PS = 0, the first 4-bit XI item is placed here.
            When PS = 1, the field is set to zero when sending, and
            ignored when receiving.

      ref_id: The identifier of the reference CSRC list used when the
           list was compressed.  It is the 8 least significant bits of
           the RTP Sequence Number in R-mode and gen_id (see section
           5.8.2) in U/O-mode.

      insertion bit mask: Bit mask indicating the positions where new
                items are to be inserted.  See Insertion Only scheme in
                section 5.8.3.  The bit mask can have either of the
                following two formats:

Top      Up      ToC       Page 123 
           0   1   2   3   4   5   6   7
         +---+---+---+---+---+---+---+---+
         | 0 |        7-bit mask         |  bit 1 is the first bit
         +---+---+---+---+---+---+---+---+

         +---+---+---+---+---+---+---+---+
         | 1 |                           |  bit 1 is the first bit
         +---+      15-bit mask          +
         |                               |  bit 7 is the last bit
         +---+---+---+---+---+---+---+---+

      XI list: XI fields for items to be inserted.  When the insertion
         bit mask has k ones, the total number of XI fields is k.  When
         PS = 1, all XI fields are in the XI list.  When PS = 0, the
         first XI field is in the XI 1 field, and the remaining k - 1
         XI fields are in the XI list.

      Padding: Present when PS = 0 and k is even.

      item 1, ..., item n: One item for each XI field with the X bit
         set.

5.8.6.3.  Encoding Type 2 (removal only scheme)

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      | ET=2  |GP |res|     Count     |
      +---+---+---+---+---+---+---+---+
      :            gen_id             :  1 octet, if GP = 1
      +---+---+---+---+---+---+---+---+
      |            ref_id             |
      +---+---+---+---+---+---+---+---+
      /       removal bit mask        /  1-2 octets
      +---+---+---+---+---+---+---+---+

      Unless explicitly stated otherwise, fields have the same meaning
      and values as in section 5.8.5.2.

         ET: Encoding type is 2.

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

         Count: Number of elements in ref_list.

Top      Up      ToC       Page 124 
         removal bit mask: Indicates the elements in ref_list to be
            removed in order to obtain the current list.  See section
            5.8.3.  The removal bit mask has the same format as the
            insertion bit mask of section 5.8.6.3.

5.8.6.4.  Encoding Type 3 (remove then insert scheme)

      See section 5.8.3 for a description of the Remove then insert
      scheme.

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      | ET=3  |GP |PS |     XI 1      |
      +---+---+---+---+---+---+---+---+
      :            gen_id             :  1 octet, if GP = 1
      +---+---+---+---+---+---+---+---+
      |            ref_id             |
      +---+---+---+---+---+---+---+---+
      /       removal bit mask        /  1-2 octets
      +---+---+---+---+---+---+---+---+
      /      insertion bit mask       /  1-2 octets
      +---+---+---+---+---+---+---+---+
      |            XI list            |  k octets, or (k - 1) * 4 bits
      /                --- --- --- ---/
      |               :    Padding    :  if PS = 0 and k is even
      +---+---+---+---+---+---+---+---+
      |                               |
      /       item 1, ..., item n     /  variable
      |                               |
      +---+---+---+---+---+---+---+---+

      The fields in this header have the same meaning and formats as in
      section 5.8.5.2, except when explicitly stated otherwise below.

         ET: Encoding type is 3.

         removal bit mask: See section 5.8.6.3.

5.8.7.  CRC coverage for extension headers

   All fields of extension headers are CRC-STATIC, with the following
   exceptions which are CRC-DYNAMIC.

   1) Entire AH header.
   2) Entire ESP header.
   3) Sequence number in GRE, Checksum in GRE

Top      Up      ToC       Page 125 
5.9.  Header compression CRCs, coverage and polynomials

   This chapter describes how to calculate the CRCs used in packet
   headers defined in this document.  (Note that another type of CRC is
   defined for reconstructed units in section 5.2.5.)

5.9.1.  IR and IR-DYN packet CRCs

   The CRC in the IR and IR-DYN packet is calculated over the entire IR
   or IR-DYN packet, excluding Payload and including CID or any Add-CID
   octet.  For purposes of computing the CRC, the CRC field in the
   header is set to zero.

   The initial content of the CRC register is to be preset to all 1's.

   The CRC polynomial to be used for the 8-bit CRC is:

      C(x) = 1 + x + x^2 + x^8

5.9.2.  CRCs in compressed headers

   The CRC in compressed headers is calculated over all octets of the
   entire original header, before compression, in the following manner.

   The octets of the header are classified as either CRC-STATIC or CRC-
   DYNAMIC, and the CRC is calculated over:

   1) the concatenated CRC-STATIC octets of the original header, placed
      in the same order as they appear in the original header, followed
      by

   2) the concatenated CRC-DYNAMIC octets of the original header, placed
      in the same order as they appear in the original header.

   The intention is that the state of the CRC computation after 1) will
   be saved.  As long as the CRC-STATIC octets do not change, the CRC
   calculation will then only need to process the CRC-DYNAMIC octets.

   In a typical RTP/UDP/IPv4 header, 25 octets are CRC-STATIC and 15 are
   CRC-DYNAMIC.  In a typical RTP/UDP/IPv6 header, 49 octets are CRC-
   STATIC and 11 are CRC-DYNAMIC.  This technique will thus reduce the
   computational complexity of the CRC calculation by roughly 60% for
   RTP/UDP/IPv4 and by roughly 80% for RTP/UDP/IPv6.

   Note: Whenever the CRC-STATIC fields change, the new saved CRC state
   after 1) is compared with the old state.  If the states are
   identical, the CRC cannot catch the error consisting in the
   decompressor not having updated the static context.  In U/O-mode the

Top      Up      ToC       Page 126 
   compressor SHOULD then for a while use packet types with another CRC
   length, for which there is a difference in CRC state, to ensure error
   detection.

   The initial content of the CRC register is preset to all 1's.

   The polynomial to be used for the 3 bit CRC is:

      C(x) = 1 + x + x^3

   The polynomial to be used for the 7 bit CRC is:

      C(x) = 1 + x + x^2 + x^3 + x^6 + x^7

   The CRC in compressed headers is calculated over the entire original
   header, before compression.

5.10.  ROHC UNCOMPRESSED -- no compression (Profile 0x0000)

   In ROHC, compression has not been defined for all kinds of IP
   headers.  Profile 0x0000 provides a way to send IP packets without
   compressing them.  This can be used for IP fragments, RTCP packets,
   and in general for any packet for which compression of the header has
   not been defined, is not possible due to resource constraints, or is
   not desirable for some other reason.

   After initialization, the only overhead for sending packets using
   Profile 0x0000 is the size of the CID.  When uncompressed packets are
   frequent, Profile 0x0000 should be associated with a CID with size
   zero or one octet.  There is no need to associate Profile 0x0000 with
   more than one CID.

5.10.1.  IR packet

   The initialization packet (IR packet) for Profile 0x0000 has the
   following format:

Top      Up      ToC       Page 127 
     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 |res|
   +---+---+---+---+---+---+---+---+
   :                               :
   /    0-2 octets of CID info     / 1-2 octets if for large CIDs
   :                               :
   +---+---+---+---+---+---+---+---+
   |          Profile = 0          | 1 octet
   +---+---+---+---+---+---+---+---+
   |              CRC              | 1 octet
   +---+---+---+---+---+---+---+---+
   :                               : (optional)
   /           IP packet           / variable length
   :                               :
    --- --- --- --- --- --- --- ---

      res: Always zero.

      Profile: 0.

      CRC: 8-bit CRC, computed using the polynomial of section 5.9.1.
      The CRC covers the first octet of the IR packet through the
      Profile octet of the IR packet, i.e., it does not cover the
      CRC itself or the IP packet.

      IP packet: An uncompressed IP packet may be included in the IR
      packet.  The decompressor determines if the IP packet is
      present by considering the length of the IR packet.

5.10.2.  Normal packet

   A Normal packet is a normal IP packet plus CID information.  When the
   channel uses small CIDs, and profile 0x0000 is associated with a CID
   > 0, an Add-CID octet is prepended to the IP packet.  When the
   channel uses large CIDs, the CID is placed so that it starts at the
   second octet of the Normal packet.

Top      Up      ToC       Page 128 
     0   1   2   3   4   5   6   7
    --- --- --- --- --- --- --- ---
   :         Add-CID octet         : if for small CIDs and (CID != 0)
   +---+---+---+---+---+---+---+---+
   |   first octet of IP packet    |
   +---+---+---+---+---+---+---+---+
   :                               :
   /    0-2 octets of CID info     / 1-2 octets if for large CIDs
   :                               :
   +---+---+---+---+---+---+---+---+
   |                               |
   /      rest of IP packet        / variable length
   |                               |
   +---+---+---+---+---+---+---+---+

   Note that the first octet of the IP packet starts with the bit
   pattern 0100 (IPv4) or 0110 (IPv6).  This does not conflict with any
   reserved packet types.  Hence, no bits in addition to the CID are
   needed.  The profile is reasonably future-proof since problems do not
   occur until IP version 14.

5.10.3.  States and modes

   There are two modes in Profile 0x0000: Unidirectional mode and
   Bidirectional mode.  In Unidirectional mode, the compressor repeats
   the IR packet periodically.  In Bidirectional mode, the compressor
   never repeats the IR packet.  The compressor and decompressor always
   start in Unidirectional mode.  Whenever feedback is received, the
   compressor switches to Bidirectional mode.

   The compressor can be in either of two states: the IR state or the
   Normal state.  It starts in the IR state.

   a) IR state: Only IR packets can be sent.  After sending a small
      number of IR packets (only one when refreshing), the compressor
      switches to the Normal state.

   b) Normal state: Only Normal packets can be sent. When in
      Unidirectional mode, the compressor periodically transits back to
      the IR state.  The length of the period is implementation
      dependent, but should be fairly long.  Exponential backoff may be
      used.

   c) When feedback is received in any state, the compressor switches to
      Bidirectional mode.

Top      Up      ToC       Page 129 
   The decompressor can be in either of two states: NO_CONTEXT or
   FULL_CONTEXT.  It starts in NO_CONTEXT.

   d) When an IR packet is received in the NO_CONTEXT state, the
      decompressor first verifies the packet using the CRC.  If the
      packet is OK, the decompressor 1) moves to the FULL_CONTEXT state,
      2) delivers the IP packet to upper layers if present, 3) MAY send
      an ACK.  If the packet is not OK, it is discarded without further
      action.

   e) When any other packet is received in the NO_CONTEXT state, it is
      discarded without further action.

   f) When an IR packet is received in the FULL_CONTEXT state, the
      packet is first verified using the CRC.  If OK, the decompressor
      1) delivers the IP packet to upper layers if present, 2) MAY send
      an ACK.  If the packet is not OK, no action is taken.

   g) When a Normal packet is received in the FULL_CONTEXT state, the
      CID information is removed and the IP packet is delivered to upper
      layers.

5.10.4.  Feedback

   The only kind of feedback in Profile 0x0000 is ACKs.  Profile 0x0000
   MUST NOT be rejected.  Profile 0x0000 SHOULD be associated with at
   most one CID.  ACKs use the FEEDBACK-1 format of section 5.2.  The
   value of the profile-specific octet in the FEEDBACK-1 ACK is 0
   (zero).

5.11.  ROHC UDP -- non-RTP UDP/IP compression (Profile 0x0002)

   UDP/IP headers do not have a sequence number which is as well-behaved
   as the RTP Sequence Number.  For UDP/IPv4, there is an IP-ID field
   which may be echoed in feedback information, but when no IPv4 header
   is present such feedback identification becomes problematic.

   Therefore, in the ROHC UDP profile, the compressor generates a 16-bit
   sequence number SN which increases by one for each packet received in
   the packet stream.  This sequence number is thus relatively well-
   behaved and can serve as the basis for most mechanisms described for
   ROHC RTP.  It is called SN or UDP SN below.  Unless stated otherwise,
   the mechanisms of ROHC RTP are used also for ROHC UDP, with the UDP
   SN taking the role of the RTP Sequence Number.

Top      Up      ToC       Page 130 
   The ROHC UDP profile always uses p = -1 when interpreting the SN,
   since there will be no repetitions or reordering of the compressor-
   generated SN.  The interpretation interval thus always starts with
   (ref_SN + 1).

5.11.1.  Initialization

   The static context for ROHC UDP streams can be initialized in either
   of two ways:

   1) By using an IR packet as in section 5.7.7.1, where the profile is
      two (2) and the static chain ends with the static part of an UDP
      packet.  At the compressor, UDP SN is initialized to a random
      value when the IR packet is sent.

   2) By reusing an existing context where the existing static chain
      contains the static part of a UDP packet, e.g., the context of a
      stream compressed using ROHC RTP (profile 0x0001).  This is done
      with an IR-DYN packet (section 5.7.7.2) identifying profile
      0x0002, where the dynamic chain corresponds to the prefix of the
      existing static chain that ends with the UDP header.  UDP SN is
      initialized to the RTP Sequence Number if the earlier profile was
      profile 0x0001, and to a random number otherwise.

   For ROHC UDP, the dynamic part of a UDP packet is different from
   section 5.7.7.5: a two-octet field containing the UDP SN is added
   after the Checksum field.  This affects the format of dynamic chains
   in IR and IR-DYN packets.

   Note: 2) can be used for packet streams which were initially assumed
   to be RTP streams, so that compression started with profile 0x0001,
   but were later found evidently not to be RTP streams.

5.11.2.  States and modes

   ROHC UDP uses the same states and modes as ROHC RTP.  Mode
   transitions and state logic are the same except when explicitly
   stated otherwise.  Mechanisms dealing with fields in the RTP header
   (except the RTP SN) are not used.  The decompressed UDP SN is never
   included in any header delivered to upper layers.  The UDP SN is used
   in place of the RTP SN in feedback.

Top      Up      ToC       Page 131 
5.11.3.  Packet types

   The general format of a ROHC UDP packet is the same as for ROHC RTP
   (see beginning of section 5.7).  Padding and CIDs are the same, as is
   the feedback packet type (5.7.6.1) and the feedback.  IR and IR-DYN
   packets (5.7.7) are changed as described in 5.11.1.

   The general format of compressed packets is also the same, but there
   are differences in specific formats and extensions as detailed below.
   The differences are caused by removal of all RTP specific information
   except the RTP SN, which is replaced by the UDP SN.

   Unless explicitly stated below, the packet formats are as in sections
   5.7.1-6.

   R-1

      The TS field is replaced by an IP-ID field.  The M flag has become
      part of IP-ID.  The X bit has moved.  The formats R-1-ID and R-1-
      TS are not used.

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   0 |          SN           |
   +===+===+===+===+===+===+===+===+
   | X |           IP-ID           |
   +---+---+---+---+---+---+---+---+

   UO-1

      The TS field is replaced by an IP-ID field.  The M flag has become
      part of SN.  Formats UO-1-ID and UO-1-TS are not used.

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   0 |         IP-ID         |
   +===+===+===+===+===+===+===+===+
   |        SN         |    CRC    |
   +---+---+---+---+---+---+---+---+

   UOR-2

Top      Up      ToC       Page 132 
      New format:

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

5.11.4.  Extensions

   Extensions are as in 5.7.5, with the following exceptions:

   Extension 0:

      +---+---+---+---+---+---+---+---+
      | 0   0 |    SN     |   IP-ID   |
      +---+---+---+---+---+---+---+---+

   Extension 1:

      +---+---+---+---+---+---+---+---+
      | 0   1 |    SN     |   IP-ID   |
      +---+---+---+---+---+---+---+---+
      |             IP-ID             |
      +---+---+---+---+---+---+---+---+

   Extension 2:

      +---+---+---+---+---+---+---+---+
      | 1   0 |    SN     |   IP-ID2  |
      +---+---+---+---+---+---+---+---+
      |            IP-ID2             |
      +---+---+---+---+---+---+---+---+
      |             IP-ID             |
      +---+---+---+---+---+---+---+---+

         IP-ID2: For outer IP-ID field.

   Extension 3 is the same as Extension 3 in section 5.7.5, with the
   following exceptions.

   1) The initial flag octet has the following format:

         0     1     2     3     4     5     6     7
      +-----+-----+-----+-----+-----+-----+-----+-----+
      |  1     1  |  S  |   Mode    |  I  | ip  | ip2 |
      +-----+-----+-----+-----+-----+-----+-----+-----+

Top      Up      ToC       Page 133 
      Mode: Replaces R-TS and Tsc of 5.7.5.  Provides mode information
      as was earlier done in RTP header flags and fields.

      ip2: Replaces rtp bit of 5.7.5.  Moved here from the Inner IP
      header flags octet.

   2) The bit which was the ip2 flag in the Inner IP header flags in
      5.7.5 is reserved.  It is set to zero when sending and ignored
      when receiving.

5.11.5.  IP-ID

   Treated as in ROHC RTP, but the offset is from UDP SN.

5.11.6.  Feedback

   Feedback is as for ROHC RTP with the following exceptions:

   1) UDP SN replaces RTP SN in feedback.
   2) The CLOCK option (5.7.6.6) is not used.
   3) The JITTER option (5.7.6.7) is not used.

5.12.  ROHC ESP -- ESP/IP compression (Profile 0x0003)

   When the ESP header is being used with an encryption algorithm other
   than NULL, subheaders after the ESP header are encrypted and cannot
   be compressed.  Profile 0x0003 is for compression of the chain of
   headers up to and including the ESP header in this case.  When the
   NULL encryption algorithm is being used, other profiles can be used
   and could give higher compression rates.  See section 5.8.4.3.

   This profile is very similar to the ROHC UDP profile.  It uses the
   ESP sequence number as the basis for compression instead of a
   generated number, but is otherwise very similar to ROHC UDP.  The
   interpretation interval (value of p) for the ESP-based SN is as with
   ROHC RTP (profile 0x0001).  Apart from this, unless stated explicitly
   below, mechanisms and formats are as for ROHC UDP.

5.12.1.  Initialization

   The static context for ROHC ESP streams can be initialized in either
   of two ways:

   1) by using an IR packet as in section 5.7.7.1, where the profile is
      three (3) and the static chain ends with the static part of an ESP
      header.

Top      Up      ToC       Page 134 
   2) by reusing an existing context, where the existing static chain
      contains the static part of an ESP header.  This is done with an
      IR-DYN packet (section 5.7.7.2) identifying profile 0x0003, where
      the dynamic chain corresponds to the prefix of the existing static
      chain that ends with the ESP header.

   In contrast to ROHC UDP, no extra sequence number is added to the
   dynamic part of the ESP header: the ESP sequence number is the only
   element.

   Note: 2) can be used for streams where compression has been initiated
   under the assumption that NULL encryption was being used with ESP.
   When it becomes obvious that an encryption algorithm other than NULL
   is being used, the compressor may send an IR-DYN according to 2) to
   switch to profile 0x0003 without having to send an IR packet.

5.12.2.  Packet types

   The packet types for ROHC ESP are the same as for ROHC UDP, except
   that the ESP sequence number is used instead of the generated
   sequence number of ROHC UDP.  The ESP header is not part of any
   compressed list in ROHC ESP.

6.  Implementation issues

   This document specifies mechanisms for the protocol and leaves many
   details on the use of these mechanisms to the implementers.  This
   chapter is aimed to give guidelines, ideas and suggestions for
   implementing the scheme.

6.1.  Reverse decompression

   This section describes an OPTIONAL decompressor operation to reduce
   the number of packets discarded due to an invalid context.

   Once a context becomes invalid (e.g., when more consecutive packet
   losses than expected have occurred), subsequent compressed packets
   cannot immediately be decompressed correctly.  Reverse decompression
   aims at decompressing such packets later instead of discarding them,
   by storing them until the context has been updated and validated and
   then attempting decompression.

   Let the sequence of stored packets be i, i + 1, ..., i + k, where i
   is the first packet and i + k is the last packet before the context
   was updated.  The decompressor will attempt to recover the stored
   packets in reverse order, i.e., starting with i + k, and working back
   toward i.  When a stored packet has been reconstructed, its
   correctness is verified using its CRC.  Packets not carrying a CRC

Top      Up      ToC       Page 135 
   must not be delivered to upper layers.  Packets where the CRC
   succeeds are delivered to upper layers in their original order, i.e.,
   i, i + 1, ..., i + k.

   Note that this reverse decompression introduces buffering while
   waiting for the context to be validated and thereby introduces
   additional delay.  Thus, it should be used only when some amount of
   delay is acceptable.  For example, for video packets belonging to the
   same video frame, the delay in packet arrivals does not cause
   presentation time delay.  Delay-insensitive streaming applications
   can also be tolerant of such delay.  If the decompressor cannot
   determine whether the application can tolerate delay, it should not
   perform reverse decompression.

   The following illustrates the decompression procedure in some detail:

   1. The decompressor stores compressed packets that cannot be
      decompressed correctly due to an invalid context.

   2. When the decompressor has received a context updating packet and
      the context has been validated, it proceeds to recover the last
      packet stored.  After decompression, the decompressor checks the
      correctness of the reconstructed header using the CRC.

   3. If the CRC indicates successful decompression, the decompressor
      stores the complete packet and attempts to decompress the
      preceding packet.  In this way, the stored packets are recovered
      in reverse order until no compressed packets are left.  For each
      packet, the decompressor checks the correctness of the
      decompressed headers using the header compression CRC.

   4. If the CRC indicates an incorrectly decompressed packet, the
      reverse decompression attempt MUST be terminated and all remaining
      uncompressed packets MUST be discarded.

   5. Finally, the decompressor forwards all the correctly decompressed
      packets to upper layers in their original order.

6.2.  RTCP

   RTCP is the RTP Control Protocol [RTP].  RTCP is based on periodic
   transmission of control packets to all participants in a session,
   using the same distribution mechanism as for data packets.  Its
   primary function is to provide feedback from the data receivers on
   the quality of the data distribution.  The feedback information may
   be used for issues related to congestion control functions, and
   directly useful for control of adaptive encodings.

Top      Up      ToC       Page 136 
   In an RTP session there will be two types of packet streams: one with
   the RTP header and application data, and one with the RTCP control
   information.  The difference between the streams at the transport
   level is in the UDP port numbers: the RTP port number is always even,
   the RTCP port number is that number plus one and therefore always odd
   [RTP, section 10].  The ROHC header compressor implementation has
   several ways at hand to handle the RTCP stream:

   1. One compressor/decompressor entity carrying both types of streams
      on the same channel, using CIDs to distinguish between them.  For
      sending a single RTP stream together with its RTCP packets on one
      channel, it is most efficient to set LARGE_CIDS to false, send the
      RTP packets with the implied CID 0 and use the Add-CID mechanism
      to send the RTCP packets.

   2. Two compressor/decompressor entities, one for RTP and another one
      for RTCP, carrying the two types of streams on separate channels.
      This means that they will not share the same CID number space.

   RTCP headers may simply be sent uncompressed using profile 0x0000.
   More efficiently, ROHC UDP compression (profile 0x0002) can be used.

6.3.  Implementation parameters and signals

   A ROHC implementation may have two kinds of parameters: configuration
   parameters that are mandatory and must be negotiated between
   compressor and decompressor peers, and implementation parameters that
   are optional and, when used, stipulate how a ROHC implementation is
   to operate.

   Configuration parameters are mandatory and must be negotiated between
   compressor and decompressor, so that they have the same values at
   both compressor and decompressor, see section 5.1.1.

   Implementation parameters make it possible for an external entity to
   stipulate how an implementation of a ROHC compressor or decompressor
   should operate.  Implementation parameters have local significance,
   are optional to use and are thus not necessary to negotiate between
   compressor and decompressor.  Note that this does not preclude
   signaling or negotiating implementation parameters using lower layer
   functionality in order to set the way a ROHC implementation should
   operate.  Some implementation parameters are valid only at either of
   compressor or decompressor.  Implementation parameters may further be
   divided into parameters that allow an external entity to describe the
   way the implementation should operate and parameters that allow an
   external entity to trigger a specific event, i.e., signals.

Top      Up      ToC       Page 137 
6.3.1.  ROHC implementation parameters at compressor

   CONTEXT_REINITIALIZATION -- signal
   This parameter triggers a reinitialization of the entire context at
   the decompressor, both the static and the dynamic part.  The
   compressor MUST, when CONTEXT_REINITIALIZATION is triggered, back off
   to the IR state and fully reinitialize the context by sending IR
   packets with both the static and dynamic chains covering the entire
   uncompressed headers until it is reasonably confident that the
   decompressor contexts are reinitialized.  The context
   reinitialization MUST be done for all contexts at the compressor.
   This parameter may for instance be used to do context relocation at,
   e.g., a cellular handover that results in a change of compression
   point in the radio access network.

   NO_OF_PACKET_SIZES_ALLOWED -- value: positive integer
   This parameter may be set by an external entity to specify the number
   of packet sizes a ROHC implementation may use.  However, the
   parameter may be used only if PACKET_SIZES is not used by an external
   entity.  With this parameter set, the ROHC implementation at the
   compressor MUST NOT use more different packet sizes than the value
   this parameter stipulates.  The ROHC implementation must itself be
   able to determine which packet sizes will be used and describe these
   to an external entity using PACKET_SIZES_USED.  It should be noted
   that one packet size might be used for several header formats, and
   that the number of packet sizes can be reduced by employing padding
   and segmentation.

   NO_OF_PACKET_SIZES_USED _- value: positive integer
   This parameter is set by the ROHC implementation to indicate how many
   packet sizes it will actually use.  It can be set to a large value to
   indicate that no particular attempt is made to minimize that number.

   PACKET_SIZES_ALLOWED -- value: list of positive integers (bytes)
   This parameter, if set, governs which packet sizes in bytes may be
   used by the ROHC implementation.  Thus, packet sizes not in the set
   of values for this parameter MUST NOT be used.  Hence, an external
   entity can mandate a ROHC implementation to produce packet sizes that
   fit pre-configured lower layers better.  If this parameter is used to
   stipulate which packet sizes a ROHC implementation can use, the
   following rules apply:

   - A packet large enough to hold the entire IR header (both static and
     dynamic chain) MUST be part of the set of sizes, unless MRRU is set
     to a large enough value to allow segmentation.
   - The packet size likely to be used most frequently in the SO state
     SHOULD be part of the set.

Top      Up      ToC       Page 138 
   - The packet size likely to be used most frequently in the FO state
     SHOULD be part of the set.

   PACKET_SIZES_USED -- values: set of positive integers (bytes)
   This parameter describes which packet sizes a ROHC implementation
   uses if NO_OF_PACKET_SIZES_ALLOWED or PACKET_SIZES_ALLOWED is used by
   an external entity to stipulate how many packet sizes a ROHC
   implementation should use.  The information about used packet sizes
   (bytes) in this parameter, may then be used to configure lower
   layers.

   PAYLOAD_SIZES -_ values: set of positive integer values (bytes)
   This parameter is set by an external entity that wants to make use of
   the PACKET_SIZES_USED parameter to indicate which payload sizes can
   be expected.

   When a ROHC implementation has a limited set of allowed packet sizes,
   and the most preferable header format has a size that is not part of
   the set, it has the following options:

   - Choose the next larger header format from the allowed set.  This is
     probably the most efficient choice.
   - Use the most preferable header format as if there were no
     restrictions on size, and then add padding octets to complete a
     packet of the next larger size in the allowed set.
   - Use segmentation to fragment the packet into pieces that would make
     up packets of sizes that are permissible (possibly after the
     addition of padding to the last segment).

   It should be noted that even if the two last parameters introduce the
   possibility of restricting the number of packet sizes used, such
   restrictions will have a negative impact on compression performance.

6.3.2.  ROHC implementation parameters at decompressor

   MODE -- values: [U-mode, O-mode, R-mode]
   This parameter triggers a mode transition using the mechanism
   described in chapter 5 when the parameter changes value, i.e., to U-
   mode (Unidirectional mode), O-mode (Bidirectional Optimistic mode) or
   R-mode (Bidirectional Reliable mode).  The mode transition is made
   from the current mode to the new mode as signaled by the
   implementation parameter.  For example, if the current mode is
   Bidirectional Optimistic mode, MODE should have the value O-mode.  If
   the MODE is changed to R-mode, a mode transition MUST be made from
   Bidirectional Optimistic mode to Bidirectional Reliable mode.  MODE
   should not only serve as a trigger for mode transitions, but also
   make it visible which mode ROHC operates in.

Top      Up      ToC       Page 139 
   CLOCK_RESOLUTION -- value: nonnegative integer
   This parameter indicates the system clock resolution in units of
   milliseconds.  A zero (0) value means that there is no clock
   available.  If nonzero, this parameter allows the decompressor to use
   timer-based TS compression (section 4.5.4) and SN wraparound
   detection (section 5.3.2.2.4).  In this case, its specific value is
   also significant for correctness of the algorithms.

   REVERSE_DECOMPRESSION_DEPTH -- value: nonnegative integer
   This parameter determines whether reverse decompression as described
   in section 6.1 should be used or not, and if used, to what extent.
   The value indicates the maximum number of packets that can be
   buffered, and thus possibly be reverse decompressed by the
   decompressor.  A zero (0) value means that reverse decompression MUST
   NOT be used.

6.4.  Handling of resource limitations at the decompressor

   In a point-to-point link, the two nodes can agree on the number of
   compressed sessions they are prepared to support for this link.  It
   may, however, not be possible for the decompressor to accurately
   predict when it will run out of resources.  ROHC allows the
   negotiated number of contexts to be larger than could be accommodated
   in the worst case.  Then, as context resources are consumed, an
   attempt to set up a new context may be rejected by the decompressor,
   using the REJECT option of the feedback payload.

   Upon reception of a REJECT option, the compressor SHOULD wait for a
   while before attempting to compress additional streams destined for
   the rejecting node.

6.5.  Implementation structures

   This section provides some explanatory material on data structures
   that a ROHC implementation will have to maintain in one form or
   another.  It is not intended to constrain the implementations.

6.5.1.  Compressor context

   The compressor context consists of a static part and a dynamic part.
   The content of the static part is the same as the static chain
   defined in section 5.7.7.  The dynamic part consists of multiple
   elements which can be categorized into four types.

   a) Sliding Window (SW)
   b) Translation Table (TT)
   c) Flag
   d) Field

Top      Up      ToC       Page 140 
   These elements may be common to all modes or mode specific.  The
   following table summarizes all these elements.

   +--------+---------------------------+-------------+----------------+
   |        |         Common to         | Specific to |  Specific to   |
   |        |         all modes         |   R-mode    |    U/O-mode    |
   +--------+---------------------------+-------------+----------------+
   | SWs    | GSW                       | R_CSW       | UO_CSW         |
   |        |                           | R_IESW      | UO_IESW        |
   +--------+---------------------------+-------------+----------------+
   | TTs    |                           | R_CTT       | UO_CTT         |
   |        |                           | R_IETT      | UO_IETT        |
   +--------+---------------------------+-------------+----------------+
   | Flags  | UDP Chksum                |             | ACKED          |
   |        | TSS, TIS                  |             |                |
   |        | RND, RND2                 |             |                |
   |        | NBO, NBO2                 |             |                |
   +--------+---------------------------+-------------+----------------+
   | Fields | Profile                   |             | CSRC_REF_ID    |
   |        | C_MODE                    |             | CSRC_GEN_ID    |
   |        | C_STATE                   |             | CSRC_GEN_COUNT |
   |        | C_TRANS                   |             | IPEH_REF_ID    |
   |        | TS_STRIDE (if TSS = 1)    |             | IPEH_GEN_ID    |
   |        | TS_OFFSET (if TSS = 1)    |             | IPEH_GEN_COUNT |
   |        | TIME_STRIDE (if TIS = 1)  |             |                |
   |        | CURR_TIME (if TIS = 1)    |             |                |
   |        | MAX_JITTER_CD (if TIS = 1)|             |                |
   |        | LONGEST_LOSS_EVENT(O)     |             |                |
   |        | CLOCK_RESOLUTION(O)       |             |                |
   |        | MAX_JITTER(O)             |             |                |
   +--------+---------------------------+-------------+----------------+

   1) GSW: Generic W_LSB Sliding Window

      Each element in GSW consists of all the dynamic fields in the
      dynamic chain (defined in section 5.7.7) plus the fields specified
      in a) but excluding the fields specified in b).

      a) Packet Arrival Time (if TIS = 1)
         Scaled RTP Time Stamp (if TSS = 1) (optional)
         Offset_i (if RND = 0) (optional)

      b) UDP Checksum, TS Stride, CSRC list, IPv6 Extension Headers

   2) R_CSW: CSRC Sliding Window in R-mode

      R_IESW: IPv6 Extension Header Sliding Window in R-mode

Top      Up      ToC       Page 141 
      UO_CSW: CSRC Sliding Window in U/O-mode

      UO_IESW: IPv6 Extension Header Sliding Window in U/O-mode

      Each element in R_CSW, R_IESW, UO_CSW and UO_IESW is defined in
      section 6.5.3.

   3) R_CTT: CSRC Translation Table in R-mode

      R_IETT: IPv6 Extension Header Translation Table in U/O-mode

      UO_CTT: CSRC Translation Table in U/O-mode

      UO_IETT: IPv6 Extension Header Translation Table in U/O-mode

      Each element in R_CTT and R_IETT is defined in section 5.8.1.1.
      Each element in UO_CTT and UO_IETT is defined in section 5.8.1.2.

   4) ACKED: Indicates whether or not the decompressor has ever acked

   5) CURR_TIME: The current time value (used for context relocation
      when timer-based timestamp compression is used)

   6) All the other flags and fields are defined elsewhere in the ROHC
      document.

6.5.2.  Decompressor context

   The decompressor context consists of a static part and a dynamic
   part.  The content of the static part is the same as the static chain
   defined in section 5.7.7.  The dynamic part consists of multiple
   elements, one of which is the nonstatic reference header that
   includes all the nonstatic fields.  These nonstatic fields are the
   fields in the dynamic chain defined in section 5.7.7, excluding UDP
   Checksum and TS_Stride.  All the remaining elements can be
   categorized into four types:

   a) Sliding Window (SW)
   b) Translation Table (TT)
   d) Flag
   e) Field

   These elements may be mode specific or common to all modes.  The
   following table summarizes all these elements.

Top      Up      ToC       Page 142 
   +--------+---------------------------+-------------+----------------+
   |        |       Common to           | Specific to |   Specific to  |
   |        |       all modes           |    R-mode   |     U/O-mode   |
   +--------+---------------------------+-------------+----------------+
   | SWs    |                           | R_CSW       | UO_CSW         |
   |        |                           | R_IESW      | UO_IESW        |
   +--------+---------------------------+-------------+----------------+
   | TTs    |                           | R_CTT       | UO_CTT         |
   |        |                           | R_IETT      | UO_IETT        |
   +--------+---------------------------+-------------+----------------+
   | Flags  | UDP Checksum              |             | ACKED          |
   |        | TSS, TIS                  |             |                |
   |        | RND, RND2                 |             |                |
   |        | NBO, NBO2                 |             |                |
   +--------+---------------------------+-------------+----------------+
   | Fields | Profile                   |             | CSRC_GEN_ID    |
   |        | D_MODE                    |             | IPEH_GEN_ID    |
   |        | D_STATE                   |             | PRE_SN_V_REF   |
   |        | D_TRANS                   |             |                |
   |        | TS_STRIDE (if TSS = 1)    |             |                |
   |        | TS_OFFSET (if TSS = 1)    |             |                |
   |        | TIME_STRIDE (if TIS = 1)  |             |                |
   |        | PKT_ARR_TIME (if TIS = 1) |             |                |
   |        | LONGEST_LOSS_EVENT(O)     |             |                |
   |        | CLOCK_RESOLUTION(O)       |             |                |
   |        | MAX_JITTER(O)             |             |                |
   +--------+---------------------------+-------------+----------------+

   1) ACKED: Indicates whether or not ACK has ever been sent.

   2) PKT_ARR_TIME: The arrival time of the packet that most recently
      decompressed and verified using CRC.

      PRE_SN_V_REF: The sequence number of the packet verified before
      the most recently verified packet.

      CSRC_GEN_ID: The CSRC gen_id of the most recently received packet.

      IPEH_GEN_ID: The IPv6 Extension Header gen_id of the most recently
      received packet.

   3) The remaining elements are as defined in the compressor context.

6.5.3.  List compression: Sliding windows in R-mode and U/O-mode

   In R-mode list compression (see section 5.8.2.1), each entry in the
   sliding window, both at the compressor side and at the decompressor
   side, has the following structure:

Top      Up      ToC       Page 143 
   +---------------------+--------+------------+
   | RTP Sequence Number | icount | index list |
   +---------------------+--------+------------+

   The table index list contains a list of index.  Each of these index
   corresponds to the item in the original list carried in the packet
   identified by the RTP Sequence Number.  The mapping between the index
   and the item is identified in the translation table.  The icount
   field carries the number of index in the following index list.

   In U/O-mode list compression, each entry in the sliding window at
   both the compressor side and decompressor side has the following
   structure.

   +--------+--------+------------+
   | Gen_id | icount | index list |
   +--------+--------+------------+

   The icount and index list fields are the same as defined in R-mode.
   Instead of using the RTP Sequence Number to identify each entry, the
   Gen_id is included in the sliding window in U/O-mode.

7.  Security Considerations

   Because encryption eliminates the redundancy that header compression
   schemes try to exploit, there is some inducement to forego encryption
   of headers in order to enable operation over low-bandwidth links.
   However, for those cases where encryption of data (and not headers)
   is sufficient, RTP does specify an alternative encryption method in
   which only the RTP payload is encrypted and the headers are left in
   the clear.  That would still allow header compression to be applied.

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

   A malfunctioning or malicious header compressor could cause the
   header decompressor to reconstitute packets that do not match the
   original packets but still have valid IP, UDP and RTP headers and
   possibly also valid UDP checksums.  Such corruption may be detected
   with end-to-end authentication and integrity mechanisms which will
   not be affected by the compression.  Moreover, this header
   compression scheme uses an internal checksum for verification of
   reconstructed headers.  This reduces the probability of producing
   decompressed headers not matching the original ones without this
   being noticed.

Top      Up      ToC       Page 144 
   Denial-of-service attacks are possible if an intruder can introduce
   (for example) bogus STATIC, DYNAMIC or FEEDBACK packets onto the link
   and thereby cause compression efficiency to be reduced.  However, an
   intruder having the ability to inject arbitrary packets at the link
   layer in this manner raises additional security issues that dwarf
   those related to the use of header compression.

8.  IANA Considerations

   The ROHC profile identifier is a non-negative integer. In many
   negotiation protocols, it will be represented as a 16-bit value.  Due
   to the way the profile identifier is abbreviated in ROHC packets, the
   8 least significant bits of the profile identifier have a special
   significance: Two profile identifiers with identical 8 LSBs should be
   assigned only if the higher-numbered one is intended to supersede the
   lower-numbered one.  To highlight this relationship, profile
   identifiers should be given in hexadecimal (as in 0x1234, which would
   for example supersede 0x0A34).

   Following the policies outlined in [IANA-CONSIDERATIONS], the IANA
   policy for assigning new values for the profile identifier shall be
   Specification Required: values and their meanings must be documented
   in an RFC or in some other permanent and readily available reference,
   in sufficient detail that interoperability between independent
   implementations is possible.  In the 8 LSBs, the range 0 to 127 is
   reserved for IETF standard-track specifications; the range 128 to 254
   is available for other specifications that meet this requirement
   (such as Informational RFCs).  The LSB value 255 is reserved for
   future extensibility of the present specification.

   The following profile identifiers are already allocated:

   Profile     Document       Usage
   identifier

   0x0000      RFCthis        ROHC uncompressed
   0x0001      RFCthis        ROHC RTP
   0x0002      RFCthis        ROHC UDP
   0x0003      RFCthis        ROHC ESP

Top      Up      ToC       Page 145 
9.  Acknowledgments

   Earlier header compression schemes described in [CJHC], [IPHC], and
   [CRTP] have been important sources of ideas and knowledge.

   The editor would like to extend his warmest thanks to Mikael
   Degermark, who actually did a lot of the editing work, and Peter
   Eriksson, who made a copy editing pass through the document,
   significantly increasing its editorial consistency.  Of course, all
   remaining editorial problems have then been inserted by the editor.

   Thanks to Andreas Jonsson (Lulea University), who supported this work
   by his study of header field change patterns.

   Finally, this work would not have succeeded without the continual
   advice in navigating the IETF standards track, garnished with both
   editorial and technical comments, from the IETF transport area
   directors, Allison Mankin and Scott Bradner.

10.  Intellectual Property Right Claim Considerations

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

Top      Up      ToC       Page 146 
11.  References

11.1.  Normative References

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

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

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

   [RTP]                 Schulzrinne, H., Casner, S., Frederick, R. and
                         V.  Jacobson, "RTP: A Transport Protocol for
                         Real-Time Applications", RFC 1889, January
                         1996.

   [HDLC]                Simpson, W., "PPP in HDLC-like framing", STD
                         51, RFC 1662, July 1994.

   [ESP]                 Kent, S. and R. Atkinson, "IP Encapsulating
                         Security Payload", RFC 2406, November 1998.

   [NULL]                Glenn, R. and S. Kent, "The NULL Encryption
                         Algorithm and Its Use With Ipsec", RFC 2410,
                         November 1998.

   [AH]                  Kent, S. and R. Atkinson, "IP Authentication
                         Header", RFC 2402, November 1998.

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

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

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

   [ASSIGNED]            Reynolds, J. and J. Postel, "Assigned Numbers",
                         STD 2, RFC 1700, October 1994.

Top      Up      ToC       Page 147 
11.2.  Informative References

   [VJHC]                Jacobson, V., "Compressing TCP/IP Headers for
                         Low-Speed Serial Links", RFC 1144, February
                         1990.

   [IPHC]                Degermark, M., Nordgren, B. and S. Pink, "IP
                         Header Compression", RFC 2507, February 1999.

   [CRTP]                Casner, S. and V. Jacobson, "Compressing
                         IP/UDP/RTP Headers for Low-Speed Serial Links",
                         RFC 2508, February 1999.

   [CRTPC]               Degermark, M., Hannu, H., Jonsson, L.E.,
                         Svanbro, K., "Evaluation of CRTP Performance
                         over Cellular Radio Networks", IEEE Personal
                         Communication Magazine, Volume 7, number 4, pp.
                         20-25, August 2000.

   [REQ]                 Degermark, M., "Requirements for robust
                         IP/UDP/RTP header compression", RFC 3096, June
                         2001.

   [LLG]                 Svanbro, K., "Lower Layer Guidelines for Robust
                         RTP/UDP/IP Header Compression", Work in
                         Progress.

   [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
                         Writing an IANA Considerations Section in
                         RFCs", BCP 26, RFC 2434, October 1998.

Top      Up      ToC       Page 148 
12.  Authors' Addresses

   Carsten Bormann, Editor
   Universitaet Bremen TZI
   Postfach 330440
   D-28334 Bremen, Germany

   Phone: +49 421 218 7024
   Fax:   +49 421 218 7000
   EMail: cabo@tzi.org


   Carsten Burmeister
   Panasonic European Laboratories GmbH
   Monzastr. 4c
   63225 Langen, Germany

   Phone: +49-6103-766-263
   Fax:   +49-6103-766-166
   EMail: burmeister@panasonic.de


   Mikael Degermark
   The University of Arizona
   Dept of Computer Science
   P.O. Box 210077
   Tucson, AZ 85721-0077, USA

   Phone: +1 520 621-3498
   Fax:   +1 520 621-4642
   EMail: micke@cs.arizona.edu


   Hideaki Fukushima
   Matsushita Electric Industrial Co.,
   Ltd006, Kadoma, Kadoma City,
   Osaka, Japan

   Phone: +81-6-6900-9192
   Fax:   +81-6-6900-9193
   EMail: fukusima@isl.mei.co.jp

Top      Up      ToC       Page 149 
   Hans Hannu
   Box 920
   Ericsson Erisoft AB
   SE-971 28 Lulea, Sweden

   Phone: +46 920 20 21 84
   Fax:   +46 920 20 20 99
   EMail: hans.hannu@ericsson.com


   Lars-Erik Jonsson
   Box 920
   Ericsson Erisoft AB
   SE-971 28 Lulea, Sweden

   Phone: +46 920 20 21 07
   Fax:   +46 920 20 20 99
   EMail: lars-erik.jonsson@ericsson.com


   Rolf Hakenberg
   Panasonic European Laboratories GmbH
   Monzastr. 4c
   63225 Langen, Germany

   Phone: +49-6103-766-162
   Fax:   +49-6103-766-166
   EMail: hakenberg@panasonic.de


   Tmima Koren
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134, USA

   Phone: +1 408-527-6169
   EMail: tmima@cisco.com

Top      Up      ToC       Page 150 
   Khiem Le
   2-700
   Mobile Networks Laboratory
   Nokia Research Center
   6000 Connection Drive
   Irving, TX 75039, USA

   Phone: +1-972-894-4882
   Fax:   +1 972 894-4589
   EMail: khiem.le@nokia.com


   Zhigang Liu
   2-700
   Mobile Networks Laboratory
   Nokia Research Center
   6000 Connection Drive
   Irving, TX 75039, USA

   Phone: +1 972 894-5935
   Fax:   +1 972 894-4589
   EMail: zhigang.liu@nokia.com


   Anton Martensson
   Ericsson Radio Systems AB
   Torshamnsgatan 23
   SE-164 80 Stockholm, Sweden

   Phone: +46 8 404 3881
   Fax:   +46 8 757 5550
   EMail: anton.martensson@era.ericsson.se


   Akihiro Miyazaki
   Matsushita Electric Industrial Co., Ltd
   1006, Kadoma, Kadoma City, Osaka, Japan

   Phone: +81-6-6900-9192
   Fax:   +81-6-6900-9193
   EMail: akihiro@isl.mei.co.jp

Top      Up      ToC       Page 151 
   Krister Svanbro
   Box 920
   Ericsson Erisoft AB
   SE-971 28 Lulea, Sweden

   Phone: +46 920 20 20 77
   Fax:   +46 920 20 20 99
   EMail: krister.svanbro@ericsson.com


   Thomas Wiebke
   Panasonic European Laboratories GmbH
   Monzastr. 4c
   63225 Langen, Germany

   Phone: +49-6103-766-161
   Fax:   +49-6103-766-166
   EMail: wiebke@panasonic.de


   Takeshi Yoshimura
   NTT DoCoMo, Inc.
   3-5, Hikarinooka
   Yokosuka, Kanagawa, 239-8536, Japan

   Phone: +81-468-40-3515
   Fax:   +81-468-40-3788
   EMail: yoshi@spg.yrp.nttdocomo.co.jp


   Haihong Zheng
   2-700
   Mobile Networks Laboratory
   Nokia Research Center
   6000 Connection Drive
   Irving, TX 75039, USA

   Phone: +1 972 894-4232
   Fax:   +1 972 894-4589
   EMail: haihong.zheng@nokia.com


Next RFC Part