Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3095

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

Pages: 168
Proposed Standard
Updated by:  37594815
Part 6 of 7 – Pages 119 to 151
First   Prev   Next

Top   ToC   RFC3095 - Page 119   prevText

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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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   ToC   RFC3095 - 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 page on part 7)

Next Section