Network Working Group                                 Ghyslain Pelletier
INTERNET-DRAFT                                               Ericsson AB
Expires: August 2002
                                                       February 22, 2002 May 2003
                                                        January 31, 2003

                    RObust Header Compression (ROHC):
                          Profiles for UDP Lite
                  <draft-pelletier-rohc-udplite-00.txt> UDP-Lite
                  <draft-pelletier-rohc-udplite-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 IP/UDP Lite/RTP RTP/UDP-Lite/IP packets (Internet (Real-Time Transport Protocol,
   User Datagram Protocol Lite, Real-Time Transport Internet Protocol) and IP/UDP
   Lite. UDP-Lite/IP.
   These profiles are defined based on their differences with the
   profiles specified in [RFC-3095] for the classic UDP [RFC-768].

   Although both transport protocols are very similar, ROHC profiles
   must be defined separately for robust compression of UDP Lite UDP-Lite headers
   because it does not share protocol identifier with the classic UDP. Also, the UDP Lite
   UDP-Lite Checksum Coverage field does not either share the semantics of the
   corresponding classic UDP Length field and as a consequence cannot always be
   inferred anymore. In addition, this
   coverage field may open new possibilities for additional compression
   efficiency when compared to the UDP profiles defined in [RFC-3095].

Table of contents

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

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

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

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

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

       4.1.  UDP Lite Considerations..................................8  Design motivations........................................6
       4.2.  ROHC Considerations......................................8
        4.3.  Header Compression strategies for UDP Lite...............9
        4.4.  UPD Lite checksum and ROHC CRC..........................10 considerations.......................................6

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

       5.1.  Context parameters........................................7
       5.2.  Initialization............................................8
       5.2.1.  Initialization of the UDP Lite UDP-Lite header [UDPLITE]..........11
        5.2. States [UDP-Lite]........8
       5.2.2.  Compressor and modes.........................................11 decompressor logic.......................9
       5.3.  Packet type format.......................................11
        5.4. IP/UDP Lite/RTP compression: ROHC RTP/UDPLite............12
        5.4.1.  Initialization........................................12
        5.4.2.  Packet types..........................................12
        5.4.2.1  Packet type 0: TBD...................................12
        5.4.2.2 formats............................................9
       5.3.1.  General packet format...................................9
       5.3.2.  Packet type 1: TBD...................................13
        5.4.2.3  Packet types 2, IR, IR-DYN CE: CE(), CE(ON) and extensions............13 CE(OFF)...............10
       5.4.  Compression logic........................................11
       5.5. Non-RTP IP/UPD Lite compression: ROHC UDPLite............13
        5.5.1.  Initialization........................................13
        5.5.2.  Packet types..........................................13  Decompression logic......................................12

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

   7.  Acknowledgements...............................................14  IANA considerations............................................12

   8.  Intellectual Property Right Claim Considerations...............14  Acknowledgements...............................................12

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

   10.  Authors address................................................14 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

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, the main focus of ROHC [RFC-3095] has so far been mainly focused on compression of
   IP/UDP/RTP headers, which are generous in size, especially compared
   to the payloads often carried by the 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 [UDP-Lite] is a transport protocol similar to the classic UDP
   protocol [RFC-768]. UDP Lite 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. The protocol is This may be particularly suitable for when packets are
   transported over link technologies where data can be partially
   damaged, such as wireless links.

   New

   Separate ROHC profiles are needed for UDP Lite UDP-Lite because it does not
   share protocol identifier with the classic UDP. Also, the UDP Lite UDP-Lite Checksum
   Coverage field does not either share the semantics of the corresponding UDP
   Length field of the classic UDP and cannot always be inferred. In addition, the coverage field may open new possibilities
   for additional compression efficiency when compared to ROHC RTP.

   This document thus defines two ROHC profiles to allow for efficient compression of
   UDP Lite
   UDP-Lite headers. The objectives of these profiles are to provide
   simple modifications to the existing profiles for compressing classic
   UDP headers, as well as introducing a simple method by which the UDP
   Lite checksum may be entirely compressed away in certain specific
   scenarios, without threats to the end-to-end nature of this checksum.
   This document therefore focuses on differences to the compression corresponding ROHC profiles for classic UDP headers, UDP, as
   specified in [RFC-3095], to
   define corresponding [RFC-3095]. In addition, the ROHC profiles for UDP Lite header compression.

   Revision history:
     00:  First version of this document, including:
          Motivation for the work, the problematic and some possible
          directions.

   This first draft is currently showing the initial state of the work,
   and will hopefully generate fruitful discussions around header UDP-Lite
   support compression for UDP Lite within of multiple IP headers using the ROHC WG. 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          Robust Header Compression
   Classic UDP   Classic UDP, as defined in [RFC-768]
   UDP Lite      UDP Lite, as defined in [UDPLite]

   ROHC RTP

     ROHC RTP in this document refers to the          : RTP/UDP/IP profile 0x0001
     as defined in [RFC-3095].
   ROHC UDP

     ROHC UDP in this document refers to the non-RTP          : UDP/IP profile 0x0002 as defined in [RFC-3095].
   ROHC UDPLite

     ROHC UDPLite in this document refers to the non-RTP UDP Lite/RTP
     profile, as UDP-Lite     : UDP-Lite/IP profile defined in this document.
   ROHC RTP/UDPLite

     ROHC RTP/UDPLite in this document refers to the RTP/UDP Lite
     profile, as RTP/UDP-Lite : RTP/UDP-Lite/IP profile defined in this document.

3.  Background

3.1.  The UDP Lite Protocol

   UDP Lite  Overview of the UDP-Lite protocol

   UDP-Lite is a datagram transport protocol defined as an independant independent variant of
   the classic UDP transport protocol [RFC-768]. UDP Lite protocol. UDP-Lite is very similar to the classic UDP, and
   allow applications that can tolerate errors in the payload to use a
   checksum with optionally an optional partial coverage. See [UDPLite] for further information about This is particularly
   useful with IPv6 [RFC-2460], where the
   motivations and benefits use of the protocol.

   UDP Lite transport-layer
   checksum is mandatory.

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

   UDP Lite Header Format:

     The UDP-Lite header format:

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

   The UDP Lite UDP-Lite checksum, like the classic UDP checksum, is an end-to-
   end 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 for classic UDP (mandatory for IPv6 [RFC-2460]), IPv6), such an unpredictable field cannot be
   compressed and is sent unmodified. uncompressed. The classic 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. inferred from the link layer.

   For UDP Lite, UDP-Lite, the checksum has also completely random 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 being is redefined
   as the Checksum Coverage field by UDP-Lite, this leads to different
   properties for both the Checksum
   Coverage and the Checksum fields this field from a header compression perspective.

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

   UDP Lite header fields and Classic UDP fields:
                                  +-------------------+-------------+
                                  |      UDP Lite     | Classic UDP-Lite:

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

   One difference from have different protocol identifiers;
     - The UDP-Lite checksum cannot be disabled for IPv4;
     - UDP-Lite redefines the classic UDP header fields behavior is that
   only in some cases may Length field as the Checksum
       Coverage be inferred, more
   specifically when either only the header(s) (UDP Lite header only or field, with different semantics;
     - UDP-Lite is semantically equivalent to UDP Lite/RTP headers) or when the entire datagram is covered.

   Another difference lies in Checksum
       Coverage field indicates the nature total length of the UDP Lite checksum field
   itself: packet.

   The next section provides a more detailed discussion of the checksum value depends on behavior
   of the Checksum Coverage field and
   may exclude payload. An interesting consideration from a of UPD-Lite in relation to header
   compression perspective
   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 it may be acceptable under certain
   circumstances belong to replace the UDP Lite
     same flow. Specifically, the value of the checksum and its functionality
   by a stronger cyclic redundancy check (CRC) using less bits, similar
   to coverage may
     indicate that the CRC currently used in ROHC profiles. Using UDP-Lite packet is either entirely covered by the ROHC CRC could
   in
     checksum, or covered up to some specific and potentially frequently occurring cases allow boundary less than the
   UDP Lite checksum to be replaced and inferred at packet size
     but including the receiver. UDP-Lite header.

   Inter-packet behavior

     In
   this respect, the presence relation to each other, UDP-Lite packets may exhibit either one
     of three possible change patterns, where within a stronger CRC using less bits would
   thus make the Checksum field redundant and make it acceptable not to
   transmit its uncompressed value.

3.2.  Checksum Coverage

   It is sequence of interest to consider
     packets the semantics value of the UDP Lite checksum
   when considering header compression, to find out if those semantics
   allow for some additional compression efficiency gains. Referring to
   [RFC-1144] section 3.1, when addressing Checksum Coverage field is:

       1. changing, while covering the IP checksum:

          It seems rather silly entire packet;
       2. unchanging, covering up to protect a fixed boundary within the transmission of
          information that is packet;
       3. changing, but does not being transmitted. follow any specific pattern.

     The first pattern above corresponds to the semantics of UDP, when
     the UDP Lite Checksum allow for partial coverage of
   the datagram. It must minimally cover the transport-layer header
   [UDPLite]. This is particularly useful with IPv6, where the
   transport-layer checksum is mandatory [RFC-2460]. In enabled. For this specific case, no information other than the checksum coverage and the actual
   checksum needs
     field varies according to the packet length and may be transmitted in inferred
     from the header compressed stream. It
   thus seem justified to not transmit those four octets, IP module similarly as this
   checksum in this case protects bits that are not transmitted.

   Moving forward in this line of reasoning, for the UDP Length field.

     The second pattern corresponds to the case where the checksum
   also covers coverage is
     the entire RTP header in addition same from one packet to the UDP Lite header
   may offer a similar opportunity. When operating with another within a high
   compression ratio, very few information bits are being sent as part
   of the compressed stream. It particular sequence.
     For this case, it the Checksum Coverage field may also be acceptable to
   not transmit the checksum value, provided equal or superior
   protection is provided within a static value
     defined in the header compression scheme context and it does not need to
   replace the checksum functionality, for example transmitting a strong
   enough CRC within be sent in the
     compressed header. At

     For the receiver, third pattern, the checksum may then coverage field has completely
     random values from packet to packet, and it must be regenerated locally when decompressing included in the
   headers and then validated using
     compressed header.

   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 CRC.

   The following figure shows
     lifetime of the relationship between UDP-Lite flow. A flow that predominantly follows
     the possible UDP
   Lite checksum coverage and first two change patterns described above may provide
     opportunities for compressing the ROHC CRC coverage.

   UDP Lite Checksum and ROHC CRC coverage:
     +--------+--------------+---------+-------------+
     | IP hdr | UDP Lite hdr | RTP hdr | RTP Payload |
     +--------+--------------+---------+-------------+
     <----- ROHC CRC coverage -------->
     <- UDP Lite Checksum --><- Optional coverage -->

   The UDP Lite Checksum Coverage field has four possible different
   behaviors embodied via the following assignments for its value:

     a. set to most
     of the UDP datagram length (or is set to 0)
     b. set packets.

3.3.  Header field classification

     In relation to the UDP Lite header size (set to 8)
     c. set to field classification from [RFC-3095], the UDP Lite/RTP header size
     d. set to an unpredictable value, fluctuating between
     first two patterns represent the UDP Lite
        (or UDP Lite/RTP) header length and case where the entire datagram length.

   The semantics value of the
     Checksum Coverage field thus yields a number of
   different transport scenarios each having different properties from a
   header compression perspective. These properties are further
   summarized in the following figures, for each identified scenarios.

   Note that c behavior is a special case of d, for which optimal compression
   efficiency fixed and may also be desirable.

   Note also that it is possible that an application use any of the
   possible coverage values within a single packet stream, and this is
   unpredictable from a header compression perspective.

   Total size of the fields in each class, for each scenarios:

   Scenario #1 û Assignment a.:
     +------------+---------------+
     |   Class    | Size (octets) |
     +------------+---------------+
     | either
     INFERRED   |       2       |  Checksum Coverage
     | STATIC-DEF |       4       |  Source Port / Destination Port
     | CHANGING   |       2       |  Checksum
     +------------+---------------+

   Scenario #2 û Assignment b. (pattern 1) or c.:
     +------------+---------------+
     |   Class    | Size (octets) |
     +------------+---------------+
     | INFERRED   |       4       |  Checksum Coverage / Checksum
     | STATIC-DEF |       4       |  Source Port / Destination Port
     | CHANGING   |       0       |
     +------------+---------------+

   Scenario #3 û Assignment d.:
     +------------+---------------+
     |   Class    | Size (octets) |
     +------------+---------------+
     | INFERRED   |       0       |
     | STATIC-DEF |       4       |  Source Port / Destination Port
     | CHANGING   |       4       |  Checksum Coverage / Checksum
     +------------+---------------+

   For scenario #1, corresponding to STATIC (pattern 2); pattern 3 is for the classic UDP semantics,
     case where the value varies unpredictably, the
   checksum coverage field is inferred as in classic UDP case. The
   checksum (if enabled for IPv4) has completely random values CHANGING
     and this
   field must be included as-is in the compressed header.

   For scenario #2, the checksum coverage field may value must be inferred from sent along with every packet.

     Additional information regarding the
   size analysis of the UDP Lite (UDP Lite or UDP Lite/RTP streams) or the size behavior of
     the UDP Lite/RTP header (UDP Lite/RTP streams only). The checksum
   field can then be recalculated at the receiver and the ROHC CRC
   applied on the entire decompressed to validate the checksum
   recalculation.

   For scenario #3, the checksum coverage field and the checksum field
   have completely random values and these UDP-Lite fields must both may be included
   as-is found in the compressed header. Appendix A.

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

   A for UDP-Lite

4.1.  Design motivations

   Simplicity is a strong motivation for the design of the UDP Lite UDP-Lite
   header compression profiles. The profiles is defined for UDP-Lite should
   entail only a few simple modifications to use the semantics and properties of the corresponding profiles
   defined for UDP Lite
   checksum coverage in [RFC-3095]. In addition, whenever UDP-Lite is used
   in a manner that is semantically identical to improve efficiency when UDP, the transport-layer
   checksum is enabled.

4.1.  UDP Lite compression
   efficiency should be similar.

4.2.  ROHC considerations

   The UDP Lite checksum, like the classic UDP checksum, is an end-to-
   end mechanism against erroneous delivery of error sensitive data.
   Care must be taken not simplest approach to violate this end-to-end functionality.

   The checksum coverage of UDP Lite is applied on a per-packet basis.
   As per the protocol definition, there is no guarantee that one definition of the
   scenarios identified in section 3.2 will occur more often than
   another. This in turn makes it difficult to maintain state in a
   header compression ROHC profiles for UDP-Lite
   is to treat the coverage field.

   The UDP Lite Checksum Coverage field may vary unpredictably and thus
   cannot always be inferred, as opposed an entirely random value,
   and to the corresponding Length
   field of the classic UDP.

4.2.  ROHC considerations

   The ROHC CRC

     ROHC packets may carry a CRC calculated over the send it uncompressed
     header. for every packet. This CRC is defined at the framework level and is used may be achieved
   simply by adding the decompressor field to verify that the decompressed header is correct.
     This verification serves three purposes:

      - Detection definition of longer losses than can be covered by the sequence
        number LSBs
      - Protection against failures caused by residual bit errors in the
        compressed header
      - Protection against faulty implementations or other error causes

   Replacing the transport-layer checksum

     Since this document suggests that general packet
   format [RFC-3095]. However, the end-to-end UDPLite checksum
     may compression efficiency would then
   always be completely compressed away and replaced by the ROHC CRC, less than for UDP.

   Some care must should be taken given to ensure that the CRC used offers equal or
     stronger robustness than what is provided by the UDP Lite checksum.
     Specifically, the ROHC CRC cannot replace the achieve similar compression efficiency
   for UDP-Lite as for UDP Lite checksum
     unless when the UDP Lite Checksum Coverage field covers only behaves like
   the UDP
     Lite or Length field. This requires the UDP Lite/RTP headers. Otherwise, possibility to infer the
   Checksum Coverage field when it must be sent
     uncompressed. This is necessary equal to ensure that the end-to-end
     nature length of the checksum packet.
   This would otherwise put the UDP-Lite protocol at a disadvantage over
   links where header compression is maintained.

     It used, when its behavior is thus reasonable made
   similar to assume that compression and decompression
     transparency can be guaranteed even without explicitly carrying the
     uncompressed UPD Lite coverage field and/or uncompressed UDP Lite semantics of UDP.

   A mechanism to detect the presence of the Checksum Coverage field in header
   compressed packets, in certain specific
     cases.

   Reuse of ROHC RTP and ROHC UDP mechanisms

     A headers is thus needed. This is achieved by defining a new
   packet type, using the unused identifiers from [RFC-3095].

5.  ROHC compressor will initially behave as profiles for UDP-Lite

   This section describes two ROHC RTP, however
     based profiles:

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

   These profiles build on the UDP Lite profile identifier.

     The initialization of other headers than the UDP Lite header (IPv4,
     IPv6, RTP) is the same specifications found in [RFC-3095] with
   as [RFC-3095].

     The same actions are taken upon CRC failure little modifications as in ROHC 5.3.2.2.3.

   Additional notes

     A mechanism, for example via possible. Unless explicitly stated
   otherwise, the definition of new packet types,
     must be profiles defined to allow herein follow the compressor to segregate specifications of
   ROHC UDP and ROHC RTP, respectively.

   Note that this document also reuses the different
     scenarios from each other (section 3.2), notation found in [RFC-3095].

5.1.  Context parameters

   As described in [RFC-3095], information relevant to allow previous packets
   is maintained in a context. This includes information describing the proper
     parsing and decompression of both
   packet stream, or parameters. While the coverage 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 fields,
     if these scenarios are to cannot be used disabled, as a basis opposed to improve UDP. The
     parameter context(UDP Checksum) of [RFC-3095, section 5.7] is
     therefore not used for compression
     efficiency. This mechanism may be defined in combination with a
     context value indicating if of UDP-Lite.

   In addition, the UDP-Lite checksum is enabled or not, similar
     to [RFC-3095].

     Additionally, for scenario #2 (section 3.2) it always sent as-is in every
   compressed packet. However, the Checksum Coverage field may not
   always be possible to
     achieve a minimal sent in each compressed header of one octet, similar to PT-0
     defined for ROHC RTP, even for IPv6 when packet, and the transport protocol
     checksum following context
   parameter is mandated.

4.3.  Header compression strategies for UDP Lite

   This table revisits used to indicate whether or not the corresponding table for field is sent:

   The parameter context(UDP-Lite Coverage Field Present)

     Whether the classic UDP from
   [RFC-3095] section A.3 and classifies UDP-Lite Checksum Coverage field is present or not in
     the changing fields, based on general packet format (see 5.3.1.) is controlled by the previously identified scenarios and for value
     of the case when Coverage Field Present (CFP) flag in the UDP
   Lite checksum context.

     If context(CFP) is enabled.

   Header compression strategies for UDP Lite:
   +----------------------------+-------------+-----------+-----------+
   |          Field             | Value/Delta |  Class    | Knowledge |
   +============================+=============+===========+===========+
   |                    Datagram|    Value    |  STATIC   |   KNOWN   |
   +                    --------+-------------+-----------+-----------+
   | nonzero, the Checksum Coverage: Header  |    Value    |  STATIC   |   KNOWN   |
   +                    --------+-------------+-----------+-----------+
   |                    Partial |    Value    | IRREGULAR |  UNKNOWN  |
   +----------------------------+-------------+-----------+-----------+
   |                    Datagram|    Value    | IRREGULAR |  UNKNOWN  |
   +                    --------+-------------+-----------+-----------+
   | Checksum(Enabled): Header  |    Value    | IRREGULAR |  UNKNOWN  |
   +                    --------+-------------+-----------+-----------+
   |                    Partial |    Value    | IRREGULAR |  UNKNOWN  |
   +----------------------------+-------------+-----------+-----------+
       Datagram: Scenario #1; Header: Scenario #2; Partial: Scenario #3

4.4.  UPD Lite checksum Coverage field is not
     compressed and ROHC CRC

   It it is possible to replace present within compressed packets. If
     context(CFP) is zero, the transport-layer checksum Checksum Coverage field is compressed and
     it is not sent. This is the ROHC
   checksum by a stronger CRC, without removing case when the protection required
   by value of the transport-layer.

   Note well that Checksum
     Coverage field follows a stable inter-packet change pattern; the idea is
     field has either a constant value or it has a value equal to maintain the transport-layer checksum
   protection and keep the strong CRC
     packet length for header reconstruction
   verification. Specifically, it consists into having both most packets in a sequence (see 3.2.).

   Finally, the header
   compression CRC and following context parameter is needed to indicate
   whether the transport-layer checksum replaced with field should be inferred or taken from a
   single checksum with value previously
   saved in the following properties:

   - offers equal 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 stronger protection than transport-layer checksum
   - protects all bits covered not is
     controlled by the transport-layer checksum
   - offers equal or stronger robustness than value of the header compression CRC
   - protects Coverage Field Inferred (CFI) flag
     in the original transport-layer checksum

   A header compression CRC having these properties would allow context.

     If context(CFI) is nonzero, the
   transport-layer checksum to be recalculated at Checksum Coverage field is inferred
     from the decompressor side
   before packet length, similarly as for the entire decompressed header, including UDP Length field in
     ROHC RTP. If context(CFI) is zero, the recalculated
   checksum, Checksum Coverage field is verified and validated
     decompressed using context(UDP-Lite Checksum Coverage). Therefore,
     when context(CFI) is updated to a nonzero value, the CRC.

5.    ROHC UDP Lite profiles

   The profiles defined value of the
     Checksum Coverage field stored in this document borrows as much as possible the context must also be updated.

5.2.  Initialization

   Unless stated otherwise, the mechanisms defined of ROHC RTP and ROHC UDP
   found in [RFC-3095]. This section summarizes [RFC-3095] are used also for the
   necessary  additions ROHC RTP/UDP-Lite and exceptions required from section 5.11 the
   ROHC UDP-Lite profiles, respectively.

   In particular, the considerations of
   [RFC-3095].

   This chapter is incomplete and is 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 initial proposal existing context belonging to a stream compressed using
   ROHC RTP/UDP-Lite (profile 0x0007), similarly as for directions.

5.1. ROHC UDP.

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

   The structure of the IR and IR-DYN packets structure and the initialization
   procedures are the same as for the ROHC UDP, unless explicitly stated otherwise.

   For ROHC UDPLite, profiles for UDP [RFC-3095],
   with the exception of the dynamic part of a UDP packet is different than
   from [RFC-3095] (sections 5.11.1 and 5.7.7.5): a two-octet as specified for UDP. A 2-
   octet field containing the UDP Lite Checksum Coverage field checksum coverage is added before the
   Checksum field. This affects the format of dynamic chains in both IR
   and IR-DYN packets.

   Static part:

      +---+---+---+---+---+---+---+---+
      /          Source Port          /   2 octets
      +---+---+---+---+---+---+---+---+
      /       Destination Port        /   2 octets
      +---+---+---+---+---+---+---+---+

   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).

5.2.  States

5.2.2.  Compressor and modes

   ROHC UDPLite uses the same states, state decompressor logic and transitions as
   ROHC UDP, except when explicitly stated otherwise.

   It has not yet been determined whether ROHC UDPLite can use

   The following logic must be used by both the same
   modes as ROHC RTP, compressor and if so - how. This will require more
   explanations.

5.3.  Packet type format

   The general format of a ROHC UDPLite packet is the same as
   decompressor for ROHC
   UDP (see [RFC-3095] section 5.11). Padding assigning values to the parameters context(CFP) and CIDs are
   context(CFI) during initialization:

   Context(CFP)

     During context initialization, the same, as
   are value of context(CFP) MUST be
     set to a nonzero value if the feedback packet type (see [RFC-3095] section 5.7.6.1) and Checksum Coverage field differs from
     the
   feedback. length of the UDP-Lite packet, for any one IR and or IR-DYN packets differ as described in section 5.1.

   The general format of compressed packets is also packet
     sent (compressor) or received (decompressor); otherwise the same, but there
   are differences in specific formats as detailed below. These
   differences are introduced by value
     MUST be set to zero.

   Context(CFI)

     During context initialization, the UPD Lite semantics value of context(CFI) MUST be
     set to a nonzero value if the Checksum Coverage field and the Checksum.

   The same notation as in ROHC RTP is used in this section:
   <mode format is used in>-<packet type number>-<some property>

5.4.  IP/UPD Lite/RTP compression: ROHC RTP/UDPLite (Profile TBD)

   Unless stated otherwise, equal to
     the mechanisms length of ROHC RTP are used also for
   ROHC RTP/UDPLite.

5.4.1. Initialization

   The static context is initialized in the same way as for ROHC RTP
   ([RFC-3095], section 5.11.1).

5.4.2 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 types formats

     The notation used in this section is the same general packet format as defined in [RFC-3095]
   section 5.7. 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 same as for a compressed ROHC RTP header, header [RFC-3095, section 5.7],
   with an exception for the field
   pertaining modifications to the UDP Lite checksum Checksum field, as well as additional
   fields for handling multiple IP headers [IP-ONLY, section 3.3.] and
   for the addition UDP-Lite checksum coverage:

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

   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 an 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 UDP Lite 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
   fields field is inferred in a similar manner than for [RFC-3095] for every
   packet formats, with always present
   within the exception format of PT-0 and PT-1 where it this packet (see 5.3.1.).

   This packet is
   instead dependent named Coverage Extension, or CE, and its updating
   properties depend on the final two bits of the packet format.

5.4.2.1  Packet type 0: PT-0

   PT-0: TBA

   It has not yet been determined if a 3-bit CRC octet (see
   format below). A naming scheme of the form CE(<some property>) is suitable
   used to achieve uniquely identify the desired properties mentioned in section 4.4, and as of a consequence
   if the U/O-0 particular CE packet.

   Although this packet format of ROHC RTP could type defines its own format, it may be used
   considered as PT-0 an extension mechanism for this
   profile.

5.4.2.2  Packet packets of type 1: TBD

   Packet 2, 1 or 0
   [RFC-3095]. This is achieved by substitution of the packet type 1: TBA
   identifier of the first octet of the base header (the "outer"
   identifier) with one of the unused packet types from [RFC-3095]. The following
   substituted identifier is then moved to the first octet of the
   remainder of the base header bits should be useful when defining PT-1:

   - Packet (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 (2 bits) identifier
   +===+===+===+===+===+===+===+===+
   : 1 0, for                               :  (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).

   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
   - Checksum Coverage Flag (1 bit): 1, if 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 present
   - Checksum Flag (1 bit)         : 1, useful if field is present
   - CRC (? bits)                  : ROHC ?-bit CRC
                                     ([ROHC], section 5.9.2)
   - Other bits, depending 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 properties, based on ROHC
     RTP PT-0 2, 1
     and PT-1.

   Note 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 flags are used updating properties of the inner packet type,
     CE(OFF) updates context(CFP) to identify how a value of zero, i.e. it
     effectively turns off the values presence of the Checksum Coverage and 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 fields are Coverage) is equal to the packet length; otherwise it
     must be decompressed, based
   on 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 different scenarios described in section 3.2.

5.4.2.3  Packet types 2, IR, IR-DYN and extensions

   Packet context updating
     packets of type 2 2, 1 and extensions are the same as 0 [RFC-3095]. Packet types
   IR

5.4.  Compressor logic

   Should hdr(UDP-Lite Checksum Coverage) be different from context(UDP-
   Lite Checksum Coverage) and IR-DYN are the same as in [RFC-3095], except for different from the changes
   of section 5.1.

5.5.  Non-RTP IP/UPD Lite compression: ROHC UDPLite (Profile TBD)

   Unless stated otherwise, packet length when
   context(CFP) is zero, the mechanisms of ROHC UDP are used also for
   ROHC UDPLite, with Checksum Coverage field cannot be
   compressed. In addition, should hdr(UDP-Lite Checksum Coverage) be
   different from the same considerations regarding packet length when context(CFP) is zero and
   context(CFI) is nonzero, the UDP SN
   taking Checksum Coverage field cannot be
   compressed either. For both cases, the role of field must be sent
   uncompressed using a CE packet or the RTP Sequence Number ([RFC-3095] section 5.11).

5.5.1. Initialization

   The static context for ROHC UDPLite streams can must be initialized in
   similar ways as for ROHC UDP, however reinitialized
   using the modified an IR packet.

5.5.  Decompressor logic

   For packet
   from section 5.1 types other than IR, IR-DYN and with CE that are received when
   the profile value set to (TBD) or reusing
   an existing context of a stream compressed context(CFP) is zero, the Checksum Coverage field must
   be decompressed using ROHC RTP/UDPLite.

   Note: In the case where an existing value stored in the context if the value of
   context(CFI) is reused, zero; otherwise the stream may
   have originally been assumed a UDP Lite/RTP stream, based on field is inferred from the UDP
   Lite protocol identifier (as opposed to assuming profile 0x0001).

5.5.2. Packet types

   TBA 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, Krister Svanbro Mats Nordberg for
   reviews and discussions around this document.

8.  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.

9.  References

    [RFC-3095]  C.  Bormann, "Robust 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)", (ROHC): Framework and four profiles:
                RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.

    [UDPLite]   L. Larzon, M. Degermark, "The UDP Lite Protocol",

    [IP-ONLY]   Jonsson, L., "RObust Header Compression (ROHC): A
                compression profile for IP", Internet draft (work in
                progress), January 2002.
                <draft-ietf-tsvwg-udp-lite-00.txt>

    [RFC-1144]  V. Jacobson, "Compressing TCP/IP Headers for Low-Speed
                Serial Links", RFC 1144, February 1990. 2003, <draft-ietf-rohc-ip-only-
                01.txt>

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

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

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

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

    [RFC-1889]  H.  Schulzrinne, S. Casner, R. 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          Tel: +46 920 20 24 32
   Ericsson Erisoft AB                 Fax: +46 920 20 20 99
   Box 920
   SE-971 28 Lulea
   Sweden                      EMail: ghyslain.pelletier@epl.ericsson.se

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].

     UDP-Lite header fields and UDP fields:

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

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

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 (Pattern #1 and #2)

A.2.2.  Transmit as-is in all packets

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

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   :

    --- --- --- --- --- --- --- ---
   :                               :
   +  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 August 22, 2002. July 31, 2003.