tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 3095

 
 
 

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

Part 7 of 7, p. 152 to 168
Prev RFC Part

 


prevText      Top      Up      ToC       Page 152 
Appendix A.  Detailed classification of header fields

   Header compression is possible thanks to the fact that most header
   fields do not vary randomly from packet to packet.  Many of the
   fields exhibit static behavior or change in a more or less
   predictable way.  When designing a header compression scheme, it is
   of fundamental importance to understand the behavior of the fields in
   detail.

   In this appendix, all IP, UDP and RTP header fields are classified
   and analyzed in two steps.  First, we have a general classification
   in A.1 where the fields are classified on the basis of stable
   knowledge and assumptions.  The general classification does not take
   into account the change characteristics of changing fields because
   those will vary more or less depending on the implementation and on
   the application used.  A less stable but more detailed analysis of
   the change characteristics is then done in A.2.  Finally, A.3
   summarizes this appendix with conclusions about how the various
   header fields should be handled by the header compression scheme to
   optimize compression and functionality.

Top      Up      ToC       Page 153 
A.1.  General classification

   At a general level, the header fields are separated into 5 classes:

   INFERRED       These fields contain values that can be inferred from
                  other values, for example the size of the frame
                  carrying the packet, and thus do not have to be
                  handled at all by the compression scheme.

   STATIC         These fields are expected to be constant throughout
                  the lifetime of the packet stream.  Static information
                  must in some way be communicated once.

   STATIC-DEF     STATIC fields whose values define a packet stream.
                  They are in general handled as STATIC.

   STATIC-KNOWN   These STATIC fields are expected to have well-known
                  values and therefore do not need to be communicated
                  at all.

   CHANGING       These fields are expected to vary in some way:
                  randomly, within a limited value set or range, or in
                  some other manner.


   In this section, each of the IP, UDP and RTP header fields is
   assigned to one of these classes.  For all fields except those
   classified as CHANGING, the motives for the classification are also
   stated.  In section A.2, CHANGING fields are further examined and
   classified on the basis of their expected change behavior.

A.1.1.  IPv6 header fields

      +---------------------+-------------+----------------+
      | Field               | Size (bits) |    Class       |
      +---------------------+-------------+----------------+
      | Version             |      4      |     STATIC     |
      | Traffic Class       |      8      |    CHANGING    |
      | Flow Label          |     20      |   STATIC-DEF   |
      | Payload Length      |     16      |    INFERRED    |
      | Next Header         |      8      |     STATIC     |
      | Hop Limit           |      8      |    CHANGING    |
      | Source Address      |    128      |   STATIC-DEF   |
      | Destination Address |    128      |   STATIC-DEF   |
      +---------------------+-------------+----------------+

Top      Up      ToC       Page 154 
   Version

      The version field states which IP version is used.  Packets with
      different values in this field must be handled by different IP
      stacks.  All packets of a packet stream must therefore be of the
      same IP version.  Accordingly, the field is classified as STATIC.

   Flow Label

      This field may be used to identify packets belonging to a specific
      packet stream.  If not used, the value should be set to zero.
      Otherwise, all packets belonging to the same stream must have the
      same value in this field, it being one of the fields that define
      the stream.  The field is therefore classified as STATIC-DEF.

   Payload Length

      Information about packet length (and, consequently, payload
      length) is expected to be provided by the link layer.  The field
      is therefore classified as INFERRED.

   Next Header

      This field will usually have the same value in all packets of a
      packet stream.  It encodes the type of the subsequent header.
      Only when extension headers are sometimes present and sometimes
      not, will the field change its value during the lifetime of the
      stream.  The field is therefore classified as STATIC.

   Source and Destination addresses

      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.

   Total size of the fields in each class:

      +--------------+--------------+
      | Class        | Size (octets)|
      +--------------+--------------+
      | INFERRED     |      2       |
      | STATIC       |      1.5     |
      | STATIC-DEF   |     34.5     |
      | CHANGING     |      2       |
      +--------------+--------------+

Top      Up      ToC       Page 155 
A.1.2.  IPv4 header fields

      +---------------------+-------------+----------------+
      | Field               | Size (bits) |     Class      |
      +---------------------+-------------+----------------+
      | Version             |      4      |     STATIC     |
      | Header Length       |      4      |  STATIC-KNOWN  |
      | Type Of Service     |      8      |    CHANGING    |
      | Packet Length       |     16      |    INFERRED    |
      | Identification      |     16      |    CHANGING    |
      | Reserved flag       |      1      |  STATIC-KNOWN  |
      | Don't Fragment flag |      1      |     STATIC     |
      | More Fragments flag |      1      |  STATIC-KNOWN  |
      | Fragment Offset     |     13      |  STATIC-KNOWN  |
      | Time To Live        |      8      |    CHANGING    |
      | Protocol            |      8      |     STATIC     |
      | Header Checksum     |     16      |    INFERRED    |
      | Source Address      |     32      |   STATIC-DEF   |
      | Destination Address |     32      |   STATIC-DEF   |
      +---------------------+-------------+----------------+

   Version

      The version field states which IP version is used.  Packets with
      different values in this field must be handled by different IP
      stacks.  All packets of a packet stream must therefore be of the
      same IP version.  Accordingly, the field is classified as STATIC.

   Header Length

      As long no options are present in the IP header, the header length
      is constant and well known.  If there are options, the fields
      would be STATIC, but it is assumed here that there are no options.
      The field is therefore classified as STATIC-KNOWN.

   Packet Length

      Information about packet length is expected to be provided by the
      link layer.  The field is therefore classified as INFERRED.

   Flags

      The Reserved flag must be set to zero and is therefore classified
      as STATIC-KNOWN.  The Don't Fragment (DF) flag will be constant
      for all packets in a stream and is therefore classified as STATIC.

Top      Up      ToC       Page 156 
      Finally, the More Fragments (MF) flag is expected to be zero
      because fragmentation is NOT expected, due to the small packet
      size expected.  The More Fragments flag is therefore classified as
      STATIC-KNOWN.

   Fragment Offset

      Under the assumption that no fragmentation occurs, the fragment
      offset is always zero.  The field is therefore classified as
      STATIC-KNOWN.

   Protocol

      This field will usually have the same value in all packets of a
      packet stream.  It encodes the type of the subsequent header.
      Only when extension headers are sometimes present and sometimes
      not, will the field change its value during the lifetime of a
      stream.  The field is therefore classified as STATIC.

   Header Checksum

      The header checksum protects individual hops from processing a
      corrupted header. When almost all IP header information is
      compressed away, there is no point in having this additional
      checksum; instead it can be regenerated at the decompressor side.
      The field is therefore classified as INFERRED.

   Source and Destination addresses

      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.

   Total size of the fields in each class:

      +--------------+----------------+
      | Class        | Size (octets)  |
      +--------------+----------------+
      | INFERRED     |       4        |
      | STATIC       | 1 oct + 5 bits |
      | STATIC-DEF   |       8        |
      | STATIC-KNOWN | 2 oct + 3 bits |
      | CHANGING     |       4        |
      +--------------+----------------+

Top      Up      ToC       Page 157 
A.1.3.  UDP header fields

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

   Source and Destination ports

      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.

   Length

      This field is redundant and is therefore classified as INFERRED.

   Total size of the fields in each class:

      +------------+---------------+
      | Class      | Size (octets) |
      +------------+---------------+
      | INFERRED   |       2       |
      | STATIC-DEF |       4       |
      | CHANGING   |       2       |
      +------------+---------------+

A.1.4.  RTP header fields

      +-----------------+-------------+----------------+
      | Field           | Size (bits) |     Class      |
      +-----------------+-------------+----------------+
      | Version         |      2      |  STATIC-KNOWN  |
      | Padding         |      1      |     STATIC     |
      | Extension       |      1      |     STATIC     |
      | CSRC Counter    |      4      |    CHANGING    |
      | Marker          |      1      |    CHANGING    |
      | Payload Type    |      7      |    CHANGING    |
      | Sequence Number |     16      |    CHANGING    |
      | Timestamp       |     32      |    CHANGING    |
      | SSRC            |     32      |   STATIC-DEF   |
      | CSRC            |   0(-480)   |    CHANGING    |
      +-----------------+-------------+----------------+

Top      Up      ToC       Page 158 
   Version

      Only one working RTP version exists, namely version 2.  The field
      is therefore classified as STATIC-KNOWN.

   Padding

      The use of this field is application-dependent, but when payload
      padding is used it is likely to be present in all packets.  The
      field is therefore classified as STATIC.

   Extension

      If RTP extensions are used by the application, these extensions
      are likely to be present in all packets (but the use of extensions
      is very uncommon).  However, for safety's sake this field is
      classified as STATIC and not STATIC-KNOWN.

   SSRC

      This field is part of the definition of a stream and must thus be
      constant for all packets in the stream.  The field is therefore
      classified as STATIC-DEF.

   Total size of the fields in each class:

      +--------------+---------------+
      | Class        | Size (octets) |
      +--------------+---------------+
      | STATIC       |    2 bits     |
      | STATIC-DEF   |      4        |
      | STATIC-KNOWN |    2 bits     |
      | CHANGING     |  7.5(-67.5)   |
      +--------------+---------------+

Top      Up      ToC       Page 159 
A.1.5.  Summary for IP/UDP/RTP

   Summarizing this for IP/UDP/RTP one obtains

      +----------------+----------------+----------------+
      | Class \ IP ver | IPv6 (octets)  | IPv4 (octets)  |
      +----------------+----------------+----------------+
      | INFERRED       |        4       |        6       |
      | STATIC         | 1 oct + 6 bits | 1 oct + 7 bits |
      | STATIC-DEF     |       42.5     |       16       |
      | STATIC-KNOWN   |     2 bits     | 2 oct + 5 bits |
      | CHANGING       |   11.5(-71.5)  |   13.5(-73.5)  |
      +----------------+----------------+----------------+
      | Total          |    60(-120)    |    40(-100)    |
      +----------------+----------------+----------------+

A.2.  Analysis of change patterns of header fields

   To design suitable mechanisms for efficient compression of all header
   fields, their change patterns must be analyzed.  For this reason, an
   extended classification is done based on the general classification
   in A.1, considering the fields which were labeled CHANGING in that
   classification.  Different applications will use the fields in
   different ways, which may affect their behavior.  For the fields
   whose behavior is variable, typical behavior for conversational audio
   and video will be discussed.

   The CHANGING fields are separated into five different subclasses:

   STATIC               These are fields that were classified as
                        CHANGING on a general basis, but are classified
                        as STATIC here due to certain additional
                        assumptions.

   SEMISTATIC           These fields are STATIC most of the time.
                        However, occasionally the value changes but
                        reverts to its original value after a known
                        number of packets.

   RARELY-CHANGING (RC) These are fields that change their values
                        occasionally and then keep their new values.

   ALTERNATING          These fields alternate between a small number
                        of different values.

   IRREGULAR            These, finally, are the fields for which no
                        useful change pattern can be identified.

Top      Up      ToC       Page 160 
   To further expand the classification possibilities without increasing
   complexity, the classification can be done either according to the
   values of the field and/or according to the values of the deltas for
   the field.

   When the classification is done, other details are also stated
   regarding possible additional knowledge about the field values and/or
   field deltas, according to the classification.  For fields classified
   as STATIC or SEMISTATIC, the case could be that the value of the
   field is not only STATIC but also well KNOWN a priori (two states for
   SEMISTATIC fields).  For fields with non-irregular change behavior,
   it could be known that changes usually are within a LIMITED range
   compared to the maximal change for the field.  For other fields, the
   values are completely UNKNOWN.

Top      Up      ToC       Page 161 
   Table A.1 classifies all the CHANGING fields on the basis of their
   expected change patterns, especially for conversational audio and
   video.

   +------------------------+-------------+-------------+-------------+
   |         Field          | Value/Delta |    Class    |  Knowledge  |
   +========================+=============+=============+=============+
   |             Sequential |    Delta    |    STATIC   |    KNOWN    |
   |             -----------+-------------+-------------+-------------+
   | IPv4 Id:    Seq. jump  |    Delta    |      RC     |   LIMITED   |
   |             -----------+-------------+-------------+-------------+
   |             Random     |    Value    |  IRREGULAR  |   UNKNOWN   |
   +------------------------+-------------+-------------+-------------+
   | IP TOS / Tr. Class     |    Value    |      RC     |   UNKNOWN   |
   +------------------------+-------------+-------------+-------------+
   | IP TTL / Hop Limit     |    Value    | ALTERNATING |   LIMITED   |
   +------------------------+-------------+-------------+-------------+
   |               Disabled |    Value    |    STATIC   |    KNOWN    |
   | UDP Checksum: ---------+-------------+-------------+-------------+
   |               Enabled  |    Value    |  IRREGULAR  |   UNKNOWN   |
   +------------------------+-------------+-------------+-------------+
   |                 No mix |    Value    |    STATIC   |    KNOWN    |
   | RTP CSRC Count: -------+-------------+-------------+-------------+
   |                 Mixed  |    Value    |      RC     |   LIMITED   |
   +------------------------+-------------+-------------+-------------+
   | RTP Marker             |    Value    |  SEMISTATIC | KNOWN/KNOWN |
   +------------------------+-------------+-------------+-------------+
   | RTP Payload Type       |    Value    |      RC     |   UNKNOWN   |
   +------------------------+-------------+-------------+-------------+
   | RTP Sequence Number    |    Delta    |    STATIC   |    KNOWN    |
   +------------------------+-------------+-------------+-------------+
   | RTP Timestamp          |    Delta    |      RC     |   LIMITED   |
   +------------------------+-------------+-------------+-------------+
   |                 No mix |      -      |      -      |      -      |
   | RTP CSRC List:  -------+-------------+-------------+-------------+
   |                 Mixed  |    Value    |      RC     |   UNKNOWN   |
   +------------------------+-------------+-------------+-------------+

      Table A.1 : Classification of CHANGING header fields

   The following subsections discuss the various header fields in
   detail.  Note that table A.1 and the discussions below do not
   consider changes caused by loss or reordering before the compression
   point.

Top      Up      ToC       Page 162 
A.2.1.  IPv4 Identification

   The Identification field (IP ID) of the IPv4 header is there to
   identify which fragments constitute a datagram when reassembling
   fragmented datagrams.  The IPv4 specification does not specify
   exactly how this field is to be assigned values, only that each
   packet should get an IP ID that is unique for the source-destination
   pair and protocol for the time the datagram (or any of its fragments)
   could be alive in the network.  This means that assignment of IP ID
   values can be done in various ways, which we have separated into
   three classes.

   Sequential jump

      This is the most common assignment policy in today's IP stacks.  A
      single IP ID counter is used for all packet streams.  When the
      sender is running more than one packet stream simultaneously, the
      IP ID can increase by more than one between packets in a stream.
      The IP ID values will be much more predictable and require less
      bits to transfer than random values, and the packet-to-packet
      increment (determined by the number of active outgoing packet
      streams and sending frequencies) will usually be limited.

   Random

      Some IP stacks assign IP ID values using a pseudo-random number
      generator.  There is thus no correlation between the ID values of
      subsequent datagrams.  Therefore there is no way to predict the IP
      ID value for the next datagram.  For header compression purposes,
      this means that the IP ID field needs to be sent uncompressed
      with each datagram, resulting in two extra octets of header.  IP
      stacks in cellular terminals SHOULD NOT use this IP ID assignment
      policy.

   Sequential

      This assignment policy keeps a separate counter for each outgoing
      packet stream and thus the IP ID value will increment by one for
      each packet in the stream, except at wrap around.  Therefore, the
      delta value of the field is constant and well known a priori.
      When RTP is used on top of UDP and IP, the IP ID value follows
      the RTP Sequence Number.  This assignment policy is the most
      desirable for header compression purposes.  However, its usage is
      not as common as it perhaps should be.  The reason may be that it
      can be realized only when UDP and IP are implemented together so
      that UDP, which separates packet streams by the Port
      identification fields, can make IP use separate ID counters for
      each packet stream.

Top      Up      ToC       Page 163 
      In order to avoid violating [IPv4], packets sharing the same IP
      address pair and IP protocol number cannot use the same IP ID
      values.  Therefore, implementations of sequential policies must
      make the ID number spaces disjoint for packet streams of the same
      IP protocol going between the same pair of nodes.  This can be
      done in a number of ways, all of which introduce occasional
      jumps, and thus makes the policy less than perfectly sequential.
      For header compression purposes less frequent jumps are
      preferred.

   It should be noted that the ID is an IPv4 mechanism and is therefore
   not a problem for IPv6.  For IPv4 the ID could be handled in three
   different ways.  First, we have the inefficient but reliable solution
   where the ID field is sent as-is in all packets, increasing the
   compressed headers by two octets.  This is the best way to handle the
   ID field if the sender uses random assignment of the ID field.
   Second, there can be solutions with more flexible mechanisms
   requiring less bits for the ID handling as long as sequential jump
   assignment is used.  Such solutions will probably require even more
   bits if random assignment is used by the sender.  Knowledge about the
   sender's assignment policy could therefore be useful when choosing
   between the two solutions above.  Finally, even for IPv4, header
   compression could be designed without any additional information for
   the ID field included in compressed headers.  To use such schemes, it
   must be known which assignment policy for the ID field is being used
   by the sender.  That might not be possible to know, which implies
   that the applicability of such solutions is very uncertain.  However,
   designers of IPv4 stacks for cellular terminals SHOULD use an
   assignment policy close to sequential.

A.2.2.  IP Traffic-Class / Type-Of-Service

   The Traffic-Class (IPv6) or Type-Of-Service (IPv4) field is expected
   to be constant during the lifetime of a packet stream or to change
   relatively seldom.

A.2.3.  IP Hop-Limit / Time-To-Live

   The Hop-Limit (IPv6) or Time-To-Live (IPv4) field is expected to be
   constant during the lifetime of a packet stream or to alternate
   between a limited number of values due to route changes.

A.2.4.  UDP Checksum

   The UDP checksum is optional.  If disabled, its value is constantly
   zero and could be compressed away.  If enabled, its value depends on
   the payload, which for compression purposes is equivalent to it
   changing randomly with every packet.

Top      Up      ToC       Page 164 
A.2.5.  RTP CSRC Counter

   This is a counter indicating the number of CSRC items present in the
   CSRC list.  This number is expected to be almost constant on a
   packet- to-packet basis and change by small amounts.  As long as no
   RTP mixer is used, the value of this field is zero.

A.2.6.  RTP Marker

   For audio the marker bit should be set only in the first packet of a
   talkspurt, while for video it should be set in the last packet of
   every picture.  This means that in both cases the RTP marker is
   classified as SEMISTATIC with well-known values for both states.

A.2.7.  RTP Payload Type

   Changes of the RTP payload type within a packet stream are expected
   to be rare.  Applications could adapt to congestion by changing
   payload type and/or frame sizes, but that is not expected to happen
   frequently.

A.2.8.  RTP Sequence Number

   The RTP Sequence Number will be incremented by one for each packet
   sent.

A.2.9.  RTP Timestamp

   In the audio case:

      As long as there are no pauses in the audio stream, the RTP
      Timestamp will be incremented by a constant delta, corresponding
      to the number of samples in the speech frame.  It will thus mostly
      follow the RTP Sequence Number.  When there has been a silent
      period and a new talkspurt begins, the timestamp will jump in
      proportion to the length of the silent period.  However, the
      increment will probably be within a relatively limited range.

   In the video case:

      Between two consecutive packets, the timestamp will either be
      unchanged or increase by a multiple of a fixed value corresponding
      to the picture clock frequency.  The timestamp can also decrease
      by a multiple of the fixed value if B-pictures are used.  The
      delta interval, expressed as a multiple of the picture clock
      frequency, is in most cases very limited.

Top      Up      ToC       Page 165 
A.2.10.  RTP Contributing Sources (CSRC)

   The participants in a session, which are identified by the CSRC
   fields, are expected to be almost the same on a packet-to-packet
   basis with relatively few additions and removals.  As long as RTP
   mixers are not used, no CSRC fields are present at all.

A.3.  Header compression strategies

   This section elaborates on what has been done in previous sections.
   On the basis of the classifications, recommendations are given on how
   to handle the various fields in the header compression process.
   Seven different actions are possible; these are listed together with
   the fields to which each action applies.

A.3.1.  Do not send at all

   The fields that have well known values a priori do not have to be
   sent at all.  These are:

   - IPv6 Payload Length
   - IPv4 Header Length
   - IPv4 Reserved Flag
   - IPv4 Last Fragment Flag
   - IPv4 Fragment Offset

   - UDP Checksum (if disabled)
   - RTP Version

A.3.2.  Transmit only initially

   The fields that are constant throughout the lifetime of the packet
   stream have to be transmitted and correctly delivered to the
   decompressor only once.  These are:

   - IP Version
   - IP Source Address
   - IP Destination Address
   - IPv6 Flow Label
   - IPv4 May Fragment Flag
   - UDP Source Port
   - UDP Destination Port
   - RTP Padding Flag
   - RTP Extension Flag
   - RTP SSRC

Top      Up      ToC       Page 166 
A.3.3.  Transmit initially, but be prepared to update

   The fields that are changing only occasionally must be transmitted
   initially but there must also be a way to update these fields with
   new values if they change.  These fields are:

   - IPv6 Next Header
   - IPv6 Traffic Class
   - IPv6 Hop Limit
   - IPv4 Protocol
   - IPv4 Type Of Service (TOS)
   - IPv4 Time To Live (TTL)
   - RTP CSRC Counter
   - RTP Payload Type
   - RTP CSRC List

   Since the values of the IPv4 Protocol and the IPv6 Next Header fields
   are in effect linked to the type of the subsequent header, they
   deserve special treatment when subheaders are inserted or removed.

A.3.4.  Be prepared to update or send as-is frequently

   For fields that normally either are constant or have values deducible
   from some other field, but that frequently diverge from that
   behavior, there must be an efficient way to update the field value or
   send it as-is in some packets.  These fields are:

   - IPv4 Identification (if not sequentially assigned)
   - RTP Marker
   - RTP Timestamp

A.3.5.  Guarantee continuous robustness

   For fields that behave like a counter with a fixed delta for ALL
   packets, the only requirement on the transmission encoding is that
   packet losses between compressor and decompressor must be tolerable.
   If several such fields exist, all these can be communicated together.
   Such fields can also be used to interpret the values for fields
   listed in the previous section.  Fields that have this counter
   behavior are:

   - IPv4 Identification (if sequentially assigned)
   - RTP Sequence Number

Top      Up      ToC       Page 167 
A.3.6.  Transmit as-is in all packets

   Fields that have completely random values for each packet must be
   included as-is in all compressed headers.  Those fields are:

   - IPv4 Identification (if randomly assigned)
   - UDP Checksum (if enabled)

A.3.7.  Establish and be prepared to update delta

   Finally, there is a field that is usually increasing by a fixed delta
   and is correlated to another field.  For this field it would make
   sense to make that delta part of the context state.  The delta must
   then be initiated and updated in the same way as the fields listed in
   A.3.3.  The field to which this applies is:

   - RTP Timestamp

Top      Up      ToC       Page 168 
Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.