[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 03 04 RFC 4019

Network Working Group                                 Ghyslain Pelletier
INTERNET-DRAFT                                               Ericsson AB
Expires: April 2004
                                                        October 11, 2003


                    RObust Header Compression (ROHC):
                          Profiles for UDP-Lite
                    <draft-ietf-rohc-udp-lite-01.txt>


Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/lid-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This document is an individual submission to the IETF. Comments
   should be directed to the authors.


Abstract

   This document defines ROHC (Robust Header Compression) profiles for
   compression of RTP/UDP-Lite/IP packets (Real-Time Transport Protocol,
   User Datagram Protocol Lite, Internet Protocol) and UDP-Lite/IP.
   These profiles are defined based on their differences with the
   profiles specified in [RFC-3095] for UDP [RFC-768].

   Although both transport protocols are very similar, ROHC profiles
   must be defined separately for robust compression of UDP-Lite headers
   because it does not share protocol identifier with UDP. Also, the
   UDP-Lite Checksum Coverage field does not share the semantics of the
   corresponding UDP Length field and as a consequence cannot always be
   inferred anymore.




Pelletier                                                       [Page 1]

INTERNET-DRAFT         ROHC Profiles for UDP-Lite       October 11, 2003





Table of contents

   1.  Introduction....................................................3

   2.  Terminology.....................................................3

   3.  Background......................................................4

       3.1.  Overview of the UDP-Lite protocol.........................4
       3.2.  Expected behaviours of UDP-Lite flows.....................5
       3.3.  Header field classification...............................6

   4.  Rationale behind the design of ROHC profiles for UDP-Lite.......6

       4.1.  Design motivations........................................6
       4.2.  ROHC considerations.......................................6

   5.  ROHC profiles for UDP-Lite......................................7

       5.1.  Context parameters........................................7
       5.2.  Initialization............................................8
       5.2.1.  Initialization of the UDP-Lite header [UDP-Lite]........8
       5.2.2.  Compressor and decompressor logic.......................9
       5.3.  Packet formats............................................9
       5.3.1.  General packet format...................................9
       5.3.2.  Packet type CE: CE(), CE(ON) and CE(OFF)...............10
       5.4.  Compression logic........................................11
       5.5.  Decompression logic......................................12

   6.  Security considerations........................................12

   7.  IANA considerations............................................12

   8.  Acknowledgements...............................................12

   9.  References.....................................................12

   10.  Authors address...............................................13

   Appendix A.  Detailed classification of header fields..............14

       A.1.  UDP-Lite header fields...................................14
       A.2.  Header compression strategies for UDP-Lite...............16

   Appendix B.  Detailed format of the CE packet type.................17






Pelletier                                                       [Page 2]

INTERNET-DRAFT         ROHC Profiles for UDP-Lite       October 11, 2003


1.  Introduction

   The ROHC WG has developed a header compression framework on top of
   which various profiles can be defined for different protocol sets, or
   for different compression strategies. Due to the demands of the
   cellular industry for an efficient way of transporting voice over IP
   over wireless, ROHC [RFC-3095] has mainly focused on compression of
   IP/UDP/RTP headers, which are generous in size, especially compared
   to the payloads often carried by packets with these headers.

   ROHC RTP has become a very efficient, robust and capable compression
   scheme, able to compress the headers down to a total size of one
   octet only. Also, transparency is guaranteed to an extremely high
   extent even when residual bit errors are present in compressed
   headers delivered to the decompressor.

   UDP-Lite [UDP-Lite] is a transport protocol similar to the UDP
   protocol [RFC-768]. UDP-Lite is useful for applications that are
   designed with the capability to tolerate errors in the payload and
   for which receiving damaged data is better than dealing with the loss
   of entire packets. This may be particularly suitable when packets are
   transported over link technologies where data can be partially
   damaged, such as wireless links.

   Separate ROHC profiles are needed for UDP-Lite because it does not
   share protocol identifier with UDP. Also, the UDP-Lite Checksum
   Coverage field does not share the semantics of the corresponding UDP
   Length field and cannot always be inferred.

   This document defines two ROHC profiles for efficient compression of
   UDP-Lite headers. The objectives of these profiles are to provide
   simple modifications to the corresponding ROHC profiles for UDP, as
   specified in [RFC-3095]. In addition, the ROHC profiles for UDP-Lite
   support compression of multiple IP headers using the mechanisms
   defined in [IP-ONLY].


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

   ROHC RTP          : RTP/UDP/IP profile 0x0001 defined in [RFC-3095].
   ROHC UDP          : UDP/IP profile 0x0002 defined in [RFC-3095].
   ROHC UDP-Lite     : UDP-Lite/IP profile defined in this document.
   ROHC RTP/UDP-Lite : RTP/UDP-Lite/IP profile defined in this document.







Pelletier                                                       [Page 3]

INTERNET-DRAFT         ROHC Profiles for UDP-Lite       October 11, 2003


3.  Background

3.1.  Overview of the UDP-Lite protocol

   UDP-Lite is a transport protocol defined as an independent variant of
   the UDP transport protocol. UDP-Lite is very similar to UDP, and
   allow applications that can tolerate errors in the payload to use a
   checksum with an optional partial coverage. This is particularly
   useful with IPv6 [RFC-2460], where the use of the transport-layer
   checksum is mandatory.

   UDP-Lite replaces the Length field of the UDP header with a Checksum
   Coverage field. This field indicates the number of octets covered by
   the 16-bit checksum, and it is applied on a per-packet basis. The
   coverage area must always include the UDP-Lite header and may cover
   the entire packet, in which case UDP-Lite becomes semantically
   identical to UDP. UDP-Lite and UDP do not share protocol identifier.

     The UDP-Lite header format:

        0              15 16             31
       +--------+--------+--------+--------+
       |     Source      |   Destination   |
       |      Port       |      Port       |
       +--------+--------+--------+--------+
       |    Checksum     |                 |
       |    Coverage     |    Checksum     |
       +--------+--------+--------+--------+
       |                                   |
       :              Payload              :
       |                                   |
       +-----------------------------------+

   The UDP-Lite checksum, like the UDP checksum, is an end-to-end
   mechanism against erroneous delivery of error sensitive data.
   However, as opposed to UDP, the UDP-Lite checksum may not be
   transmitted as all zeroes and cannot be disabled for IPv4 [RFC-791].

   For UDP, in the case where the checksum is disabled (IPv4 only), the
   Checksum field maintains a constant value and is normally not sent by
   the header compression scheme. In the case where the UDP checksum is
   enabled (mandatory for IPv6), such an unpredictable field cannot be
   compressed and is sent uncompressed. The UDP Length field, however,
   is always redundant and can be provided by the IP module. Header
   compression schemes do not normally transmit any bits of information
   for this field, as its value can be inferred from the link layer.

   For UDP-Lite, the checksum also has unpredictable values and this
   field must always be included as-is in the compressed header, for
   both IPv4 and IPv6. Furthermore, as the UDP Length field is redefined




Pelletier                                                       [Page 4]

INTERNET-DRAFT         ROHC Profiles for UDP-Lite       October 11, 2003


   as the Checksum Coverage field by UDP-Lite, this leads to different
   properties for this field from a header compression perspective.

   The following summarizes the relationship between UDP and UDP-Lite:

     - UDP-Lite and UDP have different protocol identifiers;
     - The UDP-Lite checksum cannot be disabled for IPv4;
     - UDP-Lite redefines the UDP Length field as the Checksum
       Coverage field, with different semantics;
     - UDP-Lite is semantically equivalent to UDP when the Checksum
       Coverage field indicates the total length of the packet.

   The next section provides a more detailed discussion of the behavior
   of the Checksum Coverage field of UPD-Lite in relation to header
   compression.

3.2.  Expected behaviours of UDP-Lite flows

   Per-packet behavior

     As mentioned in the previous section, the checksum coverage value
     is applied independently of other packets that may belong to the
     same flow. Specifically, the value of the checksum coverage may
     indicate that the UDP-Lite packet is either entirely covered by the
     checksum, or covered up to some boundary less than the packet size
     but including the UDP-Lite header.

   Inter-packet behavior

     In relation to each other, UDP-Lite packets may exhibit either one
     of three possible change patterns, where within a sequence of
     packets the value of the Checksum Coverage field is:

       1. changing, while covering the entire packet;
       2. unchanging, covering up to a fixed boundary within the packet;
       3. changing, but does not follow any specific pattern.

     The first pattern above corresponds to the semantics of UDP, when
     the UDP checksum is enabled. For this case, the checksum coverage
     field varies according to the packet length and may be inferred
     from the IP module similarly as for the UDP Length field.

     The second pattern corresponds to the case where the coverage is
     the same from one packet to another within a particular sequence.
     For this case, the Checksum Coverage field may be a static value
     defined in the context and it does not need to be sent in the
     compressed header.

     For the third case, no useful change pattern can be identified
     from packet to packet for the value of the checksum coverage field,
     and it must be included in the compressed header.



Pelletier                                                       [Page 5]

INTERNET-DRAFT         ROHC Profiles for UDP-Lite       October 11, 2003


   Per-flow behavior

     Finally, it can be expected that any one of these change patterns
     for sequences of packets may be predominant at any time during the
     lifetime of the UDP-Lite flow. A flow that predominantly follows
     the first two change patterns described above may provide
     opportunities for compressing the Checksum Coverage field for most
     of the packets.

3.3.  Header field classification

     In relation to the header field classification from [RFC-3095], the
     first two patterns represent the case where the value of the
     Checksum Coverage field behavior is fixed and may be either
     INFERRED (pattern 1) or STATIC (pattern 2); pattern 3 is for the
     case where the value varies unpredictably, the field is CHANGING
     and the value must be sent along with every packet.

     Additional information regarding the analysis of the behavior of
     the UDP-Lite fields may be found in the Appendix A.


4.  Rationale behind the design of ROHC profiles for UDP-Lite

4.1.  Design motivations

   Simplicity is a strong motivation for the design of the UDP-Lite
   header compression profiles. The profiles defined for UDP-Lite should
   entail only a few simple modifications to the corresponding profiles
   defined for UDP in [RFC-3095]. In addition, whenever UDP-Lite is used
   in a manner that is semantically identical to UDP, the compression
   efficiency should be similar.

4.2.  ROHC considerations

   The simplest approach to the definition of ROHC profiles for UDP-Lite
   is to treat the Checksum Coverage field as an irregular value, and to
   send it uncompressed for every packet. This may be achieved simply by
   adding the field to the definition of the general packet format [RFC-
   3095]. However, the compression efficiency would then always be less
   than for UDP.

   Some care should be given to achieve similar compression efficiency
   for UDP-Lite as for UDP when the Checksum Coverage field behaves like
   the UDP Length field. This requires the possibility to infer the
   Checksum Coverage field when it is equal to the length of the packet.
   This would otherwise put the UDP-Lite protocol at a disadvantage over
   links where header compression is used, when its behavior is made
   similar to the semantics of UDP.





Pelletier                                                       [Page 6]

INTERNET-DRAFT         ROHC Profiles for UDP-Lite       October 11, 2003


   A mechanism to detect the presence of the Checksum Coverage field in
   compressed headers is thus needed. This is achieved by defining a new
   packet type, using the unused identifiers from [RFC-3095].


5.  ROHC profiles for UDP-Lite

   This section describes two ROHC profiles:

   - RTP/UDP-Lite/IP compression (profile 0x0007)
   - UDP-Lite/IP compression     (profile 0x0008)

   These profiles build on the specifications found in [RFC-3095] with
   as little modifications as possible. Unless explicitly stated
   otherwise, the profiles defined herein follow the specifications of
   ROHC UDP and ROHC RTP, respectively.

   Note that this document also reuses the notation found in [RFC-3095].

5.1.  Context parameters

   As described in [RFC-3095], information relevant to previous packets
   is maintained in a context. This includes information describing the
   packet stream, or parameters. While the UDP and UDP-Lite protocols
   share many commonalities, the differences in semantics as described
   earlier renders the following parameter inapplicable:

   The parameter context(UDP Checksum)

     The UDP-Lite checksum cannot be disabled, as opposed to UDP. The
     parameter context(UDP Checksum) of [RFC-3095, section 5.7] is
     therefore not used for compression of UDP-Lite.

   In addition, the UDP-Lite checksum is always sent as-is in every
   compressed packet. However, the Checksum Coverage field may not
   always be sent in each compressed packet, and the following context
   parameter is used to indicate whether or not the field is sent:

   The parameter context(UDP-Lite Coverage Field Present)

     Whether the UDP-Lite Checksum Coverage field is present or not in
     the general packet format (see 5.3.1.) is controlled by the value
     of the Coverage Field Present (CFP) flag in the context.

     If context(CFP) is nonzero, the Checksum Coverage field is not
     compressed and it is present within compressed packets. If
     context(CFP) is zero, the Checksum Coverage field is compressed and
     it is not sent. This is the case when the value of the Checksum
     Coverage field follows a stable inter-packet change pattern; the
     field has either a constant value or it has a value equal to the
     packet length for most packets in a sequence (see 3.2.).



Pelletier                                                       [Page 7]

INTERNET-DRAFT         ROHC Profiles for UDP-Lite       October 11, 2003



   Finally, the following context parameter is needed to indicate
   whether the field should be inferred or taken from a value previously
   saved in the context:

   The parameter context(UDP-Lite Coverage Field Inferred)

     When the UDP-Lite Checksum Coverage field is not present in the
     compressed header (CFP=0), whether it is inferred or not is
     controlled by the value of the Coverage Field Inferred (CFI) flag
     in the context.

     If context(CFI) is nonzero, the Checksum Coverage field is inferred
     from the packet length, similarly as for the UDP Length field in
     ROHC RTP. If context(CFI) is zero, the Checksum Coverage field is
     decompressed using context(UDP-Lite Checksum Coverage). Therefore,
     when context(CFI) is updated to a nonzero value, the value of the
     Checksum Coverage field stored in the context must also be updated.

5.2.  Initialization

   Unless stated otherwise, the mechanisms of ROHC RTP and ROHC UDP
   found in [RFC-3095] are used also for the ROHC RTP/UDP-Lite and the
   ROHC UDP-Lite profiles, respectively.

   In particular, the considerations of ROHC UDP regarding the UDP SN
   taking the role of the RTP Sequence Number applies to ROHC UDP-Lite.
   Also, the static context for ROHC UDP-Lite may be initialized by
   reusing an existing context belonging to a stream compressed using
   ROHC RTP/UDP-Lite (profile 0x0007), similarly as for ROHC UDP.

5.2.1.  Initialization of the UDP-Lite header [UDP-Lite]

   The structure of the IR and IR-DYN packets and the initialization
   procedures are the same as for the ROHC profiles for UDP [RFC-3095],
   with the exception of the dynamic part as specified for UDP. A 2-
   octet field containing the checksum coverage is added before the
   Checksum field. This affects the format of dynamic chains in both IR
   and IR-DYN packets.

   Dynamic part:

      +---+---+---+---+---+---+---+---+
      /       Checksum Coverage       /   2 octets
      +---+---+---+---+---+---+---+---+
      /           Checksum            /   2 octets
      +---+---+---+---+---+---+---+---+

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

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



Pelletier                                                       [Page 8]

INTERNET-DRAFT         ROHC Profiles for UDP-Lite       October 11, 2003


5.2.2.  Compressor and decompressor logic

   The following logic must be used by both the compressor and the
   decompressor for assigning values to the parameters context(CFP) and
   context(CFI) during initialization:

   Context(CFP)

     During context initialization, the value of context(CFP) MUST be
     set to a nonzero value if the Checksum Coverage field differs from
     the length of the UDP-Lite packet, for any one IR or IR-DYN packet
     sent (compressor) or received (decompressor); otherwise the value
     MUST be set to zero.

   Context(CFI)

     During context initialization, the value of context(CFI) MUST be
     set to a nonzero value if the Checksum Coverage field is equal to
     the length of the UDP-Lite packet within an IR or an IR-DYN packet
     sent (compressor) or received (decompressor); otherwise the value
     MUST be set to zero.

5.3.  Packet formats

     The general packet format as defined in [RFC-3095] is modified to
     include an additional field for the UDP-Lite checksum coverage. A
     packet type is also defined to handle the specific semantics and
     characteristics of this field.

5.3.1.  General packet format

   The general packet format of a compressed ROHC UDP-Lite header is
   similar to the compressed ROHC RTP header [RFC-3095, section 5.7],
   with modifications to the Checksum field, as well as additional
   fields for handling multiple IP headers [IP-ONLY, section 3.3.] and
   for the UDP-Lite checksum coverage:

      --- --- --- --- --- --- --- ---
     :            List of            :
     /        dynamic chains         /  variable, given by static chain
     :   for additional IP headers   :  see [IP-ONLY, section 3.3].
      --- --- --- --- --- --- --- ---
     :                               :  2 octets,
     +  UDP-Lite Checksum Coverage   +  if context(CFP) = 1 or
     :                               :  if packet type = CE (see 5.3.2.)
      --- --- --- --- --- --- --- ---
     :                               :
     +      UDP-Lite Checksum        +  2 octets
     :                               :
      --- --- --- --- --- --- --- ---




Pelletier                                                       [Page 9]

INTERNET-DRAFT         ROHC Profiles for UDP-Lite       October 11, 2003


   Note that the order of the fields following the optional extension of
   the general ROHC packet format is the same as the order between the
   fields in the uncompressed header.

   Note also that when calculating the CRC for this profile, the
   Checksum Coverage field is CRC-DYNAMIC.

5.3.2.  Packet type CE: CE(), CE(ON) and CE(OFF)

   The ROHC profiles for UDP-Lite defines a packet type to handle the
   various possible change patterns of the checksum coverage. This
   packet type may be used to manipulate the context values that control
   the presence of the Checksum Coverage field within the general packet
   format, i.e. context(CFP), and how the field is decompressed, i.e.
   context(CFI). The 2-octet Checksum Coverage field is always present
   within the format of this packet (see 5.3.1.).

   This packet is named Coverage Extension, or CE, and its updating
   properties depend on the final two bits of the packet type octet (see
   format below). A naming scheme of the form CE(<some property>) is
   used to uniquely identify the properties of a particular CE packet.

   Although this packet type defines its own format, it may be
   considered as an extension mechanism for packets of type 2, 1 or 0
   [RFC-3095]. This is achieved by substitution of the packet type
   identifier of the first octet of the base header (the "outer"
   identifier) with one of the unused packet types from [RFC-3095]. The
   substituted identifier is then moved to the first octet of the
   remainder of the base header (the "inner" identifier).

   The format of the ROHC UDP-Lite CE packet type:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   1   0   F | K |  Outer packet type identifier
   +===+===+===+===+===+===+===+===+
   :                               :  (with inner type identifier)
   /       Inner Base header       /  variable number of bits, given by
   :                               :  the inner packet type identifier
   +---+---+---+---+---+---+---+---+

     F,K: F,K = 00 is reserved at framework level (IR-DYN);
          F,K = 01 indicates CE();
          F,K = 10 indicates CE(ON);
          F,K = 11 indicates CE(OFF).

     Updating properties: The updating properties of the inner packet
     type carried within any of the CE packets are always maintained. In
     addition, CE(ON) always update context(CFP); CE(OFF) always update
     context(CFP), context(CFI) and context(UDP-Lite Checksum Coverage).




Pelletier                                                      [Page 10]

INTERNET-DRAFT         ROHC Profiles for UDP-Lite       October 11, 2003


   Appendix B provides an expanded view of the resulting format of the
   CE packet type.

   Properties of CE():

     Aside from the updating properties of the inner packet type carried
     within CE(), this packet does not update any other context values.
     CE() thus is mode-agnostic, e.g. it can extend any of packet types
     2, 1 and 0, regardless of the current mode of operation [RFC-3095].

     CE() may be used when the checksum coverage deviates from the
     change pattern assumed by the compressor, while the field could
     previously be compressed. This packet is useful if the occurrence
     of such deviations are seldom.

   Properties of CE(ON):

     In addition to the updating properties of the inner packet type,
     CE(ON) updates context(CFP) to a nonzero value, i.e. it effectively
     turns on the presence of the Checksum Coverage field within the
     general packet format. This is useful when the predominant change
     pattern of the checksum coverage preclude its compression.

     CE(ON) can extend any of the context updating packets of type 2, 1
     and 0, that is packets with a compressed header containing a CRC
     [RFC-3095]. Specifically, R-0 and R-1* headers MUST NOT be extended
     using CE(ON).

   Properties of CE(OFF):

     In addition to the updating properties of the inner packet type,
     CE(OFF) updates context(CFP) to a value of zero, i.e. it
     effectively turns off the presence of the Checksum Coverage field
     within the general packet format. This is useful when the change
     pattern of the checksum coverage seldom deviates from the pattern
     assumed by the compressor.

     CE(OFF) also updates context(CFI) to a nonzero value, if field(UDP-
     Lite Checksum Coverage) is equal to the packet length; otherwise it
     must be set to zero. Finally, context(UDP-Lite Checksum Coverage)
     is also updated by CE(OFF).

     Similarly to CE(ON), CE(OFF) can extend any of the context updating
     packets of type 2, 1 and 0 [RFC-3095].

5.4.  Compressor logic

   Should hdr(UDP-Lite Checksum Coverage) be different from context(UDP-
   Lite Checksum Coverage) and different from the packet length when
   context(CFP) is zero, the Checksum Coverage field cannot be
   compressed. In addition, should hdr(UDP-Lite Checksum Coverage) be



Pelletier                                                      [Page 11]

INTERNET-DRAFT         ROHC Profiles for UDP-Lite       October 11, 2003


   different from the packet length when context(CFP) is zero and
   context(CFI) is nonzero, the Checksum Coverage field cannot be
   compressed either. For both cases, the field must be sent
   uncompressed using a CE packet or the context must be reinitialized
   using an IR packet.

5.5.  Decompressor logic

   For packet types other than IR, IR-DYN and CE that are received when
   the value of context(CFP) is zero, the Checksum Coverage field must
   be decompressed using the value stored in the context if the value of
   context(CFI) is zero; otherwise the field is inferred from the length
   of the UDP-Lite packet derived from the IP module.


6.  Security considerations

   The security considerations of [RFC-3095] apply integrally to this
   document without modifications.


7.  IANA considerations

   A ROHC profile identifier must be reserved by the IANA for each of
   the profiles defined in this document, preferably as listed below:

     Profile        Document     Usage
     Identifier

     0x0007         RFCthis      ROHC RTP/UDP-Lite
     0x0008         RFCthis      ROHC UDP-Lite


8.  Acknowledgements

   The author would like to thank Lars-Erik Jonsson, Mats Nordberg for
   reviews and discussions around this document.


9.  References

    [RFC-3095]  Bormann, C., Burmeister, C., Degermark, M., Fukushima,
                H., Hannu, H., Jonsson, L., Hakenberg, R., Koren, T.,
                Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro,
                K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust
                Header Compression (ROHC): Framework and four profiles:
                RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.







Pelletier                                                      [Page 12]

INTERNET-DRAFT         ROHC Profiles for UDP-Lite       October 11, 2003


    [IP-ONLY]   Jonsson, L. and G. Pelletier, "RObust Header Compression
                (ROHC): A compression profile for IP", Internet draft
                (work in progress), September 2003, <draft-ietf-rohc-ip-
                only-04.txt>

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

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

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

    [UDP-Lite]  Larzon, L., Degermark, M., Pink, S., Jonsson, L. and G.
                Fairhurst, "The UDP-Lite Protocol", Internet draft (work
                in progress), August 2003, <draft-ietf-tsvwg-udp-lite-
                02.txt>

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


10.  Authors address

   Ghyslain Pelletier
   Ericsson AB
   Box 920
   SE-971 28 Lulea, Sweden

   Phone: +46 920 20 24 32
   Fax: +46 920 20 20 99
   Email: ghyslain.pelletier@ericsson.com




















Pelletier                                                      [Page 13]

INTERNET-DRAFT         ROHC Profiles for UDP-Lite       October 11, 2003


Appendix A.  Detailed classification of header fields

   This section summarizes the difference from the classification found
   in the corresponding appendix in [RFC-3095], and similarly provides
   conclusions about how the various header fields should be handled by
   the header compression scheme to optimize compression and
   functionality. These conclusions are separated based on the behavior
   of the UDP-Lite Checksum Coverage field and uses the expected change
   patterns described in section 3.2 of this document.

A.1.  UDP-Lite header fields

   The following table summarizes a possible classification for the UDP-
   Lite header fields in comparison with the classification for UDP,
   using the same classes as in [RFC-3095].

     Header fields of UDP-Lite and UDP:

                                  +-------------------+-------------+
                                  |      UDP-Lite     |     UDP     |
     +-------------------+--------+-------------------+-------------+
     |       Header      |  Size  |       Class       |    Class    |
     |       Field       | (bits) |                   |             |
     +-------------------+--------+-------------------+-------------+
     |    Source Port    |   16   |     STATIC-DEF    | STATIC-DEF  |
     | Destination Port  |   16   |     STATIC-DEF    | STATIC-DEF  |
     | Checksum Coverage |   16   |      INFERRED     |             |
     |                   |        |       STATIC      |             |
     |                   |        |      CHANGING     |             |
     |      Length       |   16   |                   |  INFERRED   |
     |     Checksum      |   16   |      CHANGING     |  CHANGING   |
     +-------------------+--------+-------------------+-------------+

   Source and Destination Port

     Same as for UDP. Specifically, these fields are part of the
     definition of a stream and must thus be constant for all packets in
     the stream.  The fields are therefore classified as STATIC-DEF.

   Checksum Coverage

     This field specifies which part of the UDP-Lite datagram is covered
     by the checksum. It may have a value of zero or equal to the
     datagram length if the checksum covers the entire datagram, or it
     may have any value between eight octets and the length of the
     datagram to specify the number of octets protected by the checksum,
     calculated from the first octet of the UDP-Lite header. The value
     of this field may vary for each packet, and this makes the value
     unpredictable from a header compression perspective.





Pelletier                                                      [Page 14]

INTERNET-DRAFT         ROHC Profiles for UDP-Lite       October 11, 2003


   Checksum

     The information used for the calculation of the UDP-Lite checksum
     is governed by the value of the checksum coverage, and minimally
     includes the UDP-Lite header. The checksum is a changing field that
     must always be sent as-is.

   The total size of the fields in each class, for each expected change
   patterns (see section 3.2), is summarized in the tables below:

   Pattern 1:
     +------------+---------------+
     |   Class    | Size (octets) |
     +------------+---------------+
     | INFERRED   |       2       |  Checksum Coverage
     | STATIC-DEF |       4       |  Source Port / Destination Port
     | CHANGING   |       2       |  Checksum
     +------------+---------------+

   Pattern 2:
     +------------+---------------+
     |   Class    | Size (octets) |
     +------------+---------------+
     | STATIC-DEF |       4       |  Source Port / Destination Port
     | STATIC     |       2       |  Checksum Coverage
     | CHANGING   |       2       |  Checksum
     +------------+---------------+

   Pattern 3:
     +------------+---------------+
     |   Class    | Size (octets) |
     +------------+---------------+
     | STATIC-DEF |       4       |  Source Port / Destination Port
     | CHANGING   |       4       |  Checksum Coverage / Checksum
     +------------+---------------+



















Pelletier                                                      [Page 15]

INTERNET-DRAFT         ROHC Profiles for UDP-Lite       October 11, 2003


A.2.  Header compression strategies for UDP-Lite

   The following table revisits the corresponding table (table A.1) for
   UDP from [RFC-3095, section A.2] and classifies the changing fields,
   based on the change patterns previously identified in section 3.2.

   Header compression strategies for UDP-Lite:
   +----------+---------+-------------+-----------+-----------+
   |  Field   | Pattern | Value/Delta |   Class   | Knowledge |
   +==========+=========+=============+===========+===========+
   |          |    #1   |    Value    | CHANGING  | INFERRED  |
   | Checksum |---------+-------------+-----------+-----------+
   | Coverage |    #2   |    Value    |    RC     |  UNKNOWN  |
   |          |---------+-------------+-----------+-----------+
   |          |    #3   |    Value    | IRREGULAR |  UNKNOWN  |
   +----------+---------+-------------+-----------+-----------+
   | Checksum |   All   |    Value    | IRREGULAR |  UNKNOWN  |
   +----------+---------+-------------+-----------+-----------+

A.2.1.  Transmit initially, but be prepared to update

   UDP-Lite Checksum Coverage (Patterns #1 and #2)

A.2.2.  Transmit as-is in all packets

   UDP-Lite Checksum
   UDP-Lite Checksum Coverage (Pattern #3)



























Pelletier                                                      [Page 16]

INTERNET-DRAFT         ROHC Profiles for UDP-Lite       October 11, 2003


Appendix B.  Detailed format of the CE packet type

   This section provides an expanded view of the format of the CE
   packet, based on the general ROHC RTP compressed header [RFC-3095]
   and the general format of a compressed header [IP-ONLY]. The
   modifications necessary to carry the base header of a packet of type
   2, 1 or 0 [RFC-3095] within the CE packet format along with the
   additional fields to properly handle compression of multiple IP
   headers results in the following structure for the CE packet type:

     0   1   2   3   4   5   6   7
    --- --- --- --- --- --- --- ---
   :         Add-CID octet         :  if for small CIDs and CID 1-15
   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   1   0   F | K |  Outer packet type identifier
   +---+---+---+---+---+---+---+---+
   :                               :
   /   0, 1, or 2 octets of CID    /  1-2 octets if large CIDs
   :                               :
   +---+---+---+---+---+---+---+---+
   |   First octet of base header  |  (with "inner" type indication)
   +---+---+---+---+---+---+---+---+
   /    Remainder of base header   /  variable number of bits
   +---+---+---+---+---+---+---+---+
   :                               :
   /          Extension            /  See [RFC-3095], section 5.7.
   :                               :
    --- --- --- --- --- --- --- ---
   :                               :
   +   IP-ID of outer IPv4 header  +  See [RFC-3095], section 5.7.
   :                               :
    --- --- --- --- --- --- --- ---
   /    AH data for outer list     /  See [RFC-3095], section 5.7.
    --- --- --- --- --- --- --- ---
   :                               :
   +         GRE checksum          +  See [RFC-3095], section 5.7.
   :                               :
    --- --- --- --- --- --- --- ---
   :                               :
   +   IP-ID of inner IPv4 header  +  See [RFC-3095], section 5.7.
   :                               :
    --- --- --- --- --- --- --- ---
   /    AH data for inner list     /  See [RFC-3095], section 5.7.
    --- --- --- --- --- --- --- ---
   :                               :
   +         GRE checksum          +  See [RFC-3095], section 5.7.
   :                               :
    --- --- --- --- --- --- --- ---
   :            List of            :
   /        dynamic chains         /  See [IP-ONLY], section 3.3.
   :   for additional IP headers   :



Pelletier                                                      [Page 17]

INTERNET-DRAFT         ROHC Profiles for UDP-Lite       October 11, 2003


    --- --- --- --- --- --- --- ---
   :                               :
   +  UDP-Lite Checksum Coverage   +  2 octets
   :                               :
   +---+---+---+---+---+---+---+---+
   :                               :
   +      UDP-Lite Checksum        +  2 octets
   :                               :
   +---+---+---+---+---+---+---+---+

   F,K: F,K = 00 is reserved at framework level (IR-DYN);
        F,K = 01 indicates CE();
        F,K = 10 indicates CE(ON);
        F,K = 11 indicates CE(OFF).

   Note that this document does not define (F,K) = 00, as this would
   collide with the IR-DYN packet type already reserved at the ROHC
   framework level.


Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



This Internet-Draft expires April 11, 2004.



Pelletier                                                      [Page 18]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/