rfc2508.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,348 行 · 第 1/4 页

Network Working Group                                          S. Casner
Request for Comments: 2508                                 Cisco Systems
Category: Standards Track                                    V. Jacobson
                                                           Cisco Systems
                                                           February 1999


       Compressing IP/UDP/RTP Headers for Low-Speed Serial Links

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This document describes a method for compressing the headers of
   IP/UDP/RTP datagrams to reduce overhead on low-speed serial links.
   In many cases, all three headers can be compressed to 2-4 bytes.

   Comments are solicited and should be addressed to the working group
   mailing list [e-mail] and/or the author(s).

   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.

1.  Introduction

   Since the Real-time Transport Protocol was published as an RFC [1],
   there has been growing interest in using RTP as one step to achieve
   interoperability among different implementations of network
   audio/video applications.  However, there is also concern that the
   12-byte RTP header is too large an overhead for 20-byte payloads when
   operating over low speed lines such as dial-up modems at 14.4 or 28.8
   kb/s.  (Some existing applications operating in this environment use
   an application-specific protocol with a header of a few bytes that
   has reduced functionality relative to RTP.)






Casner & Jacobson           Standards Track                     [Page 1]

RFC 2508             Compressing IP/UDP/RTP Headers        February 1999


   Header size may be reduced through compression techniques as has been
   done with great success for TCP [2].  In this case, compression might
   be applied to the RTP header alone, on an end-to-end basis, or to the
   combination of IP, UDP and RTP headers on a link-by-link basis.
   Compressing the 40 bytes of combined headers together provides
   substantially more gain than compressing 12 bytes of RTP header alone
   because the resulting size is approximately the same (2-4 bytes) in
   either case.  Compressing on a link-by-link basis also provides
   better performance because the delay and loss rate are lower.
   Therefore, the method defined here is for combined compression of IP,
   UDP and RTP headers on a link-by-link basis.

   This document defines a compression scheme that may be used with
   IPv4, IPv6 or packets encapsulated with more than one IP header,
   though the initial focus is on IPv4.  The IP/UDP/RTP compression
   defined here is intended to fit within the more general compression
   framework specified in [3] for use with both IPv6 and IPv4.  That
   framework defines TCP and non-TCP as two classes of transport above
   IP.  This specification creates IP/UDP/RTP as a third class extracted
   from the non-TCP class.

2.  Assumptions and Tradeoffs

   The goal of this compression scheme is to reduce the IP/UDP/RTP
   headers to two bytes for most packets in the case where no UDP
   checksums are being sent, or four bytes with checksums.  It is
   motivated primarily by the specific problem of sending audio and
   video over 14.4 and 28.8 dialup modems.  These links tend to provide
   full-duplex communication, so the protocol takes advantage of that
   fact, though the protocol may also be used with reduced performance
   on simplex links.  This compression scheme performs best on local
   links with low round-trip-time.

   This specification does not address segmentation and preemption of
   large packets to reduce the delay across the slow link experienced by
   small real-time packets, except to identify in Section 4 some
   interactions between segmentation and compression that may occur.
   Segmentation schemes may be defined separately and used in
   conjunction with the compression defined here.

   It should be noted that implementation simplicity is an important
   factor to consider in evaluating a compression scheme.
   Communications servers may need to support compression over perhaps
   as many as 100 dial-up modem lines using a single processor.
   Therefore, it may be appropriate to make some simplifications in the
   design at the expense of generality, or to produce a flexible design
   that is general but can be subsetted for simplicity.  Higher
   compression gain might be achieved by communicating more complex



Casner & Jacobson           Standards Track                     [Page 2]

RFC 2508             Compressing IP/UDP/RTP Headers        February 1999


   models for the changing header fields from the compressor to the
   decompressor, but that complexity is deemed unnecessary.  The next
   sections discuss some of the tradeoffs listed here.

2.1.  Simplex vs. Full Duplex

   In the absence of other constraints, a compression scheme that worked
   over simplex links would be preferred over one that did not.
   However, operation over a simplex link requires periodic refreshes
   with an uncompressed packet header to restore compression state in
   case of error.  If an explicit error signal can be returned instead,
   the delay to recovery may be shortened substantially.  The overhead
   in the no-error case is also reduced.  To gain these performance
   improvements, this specification includes an explicit error
   indication sent on the reverse path.

   On a simplex link, it would be possible to use a periodic refresh
   instead.  Whenever the decompressor detected an error in a particular
   packet stream, it would simply discard all packets in that stream
   until an uncompressed header was received for that stream, and then
   resume decompression.  The penalty would be the potentially large
   number of packets discarded.  The periodic refresh method described
   in Section 3.3 of [3] applies to IP/UDP/RTP compression on simplex
   links or links with high delay as well as to other non-TCP packet
   streams.

2.2.  Segmentation and Layering

   Delay induced by the time required to send a large packet over the
   slow link is not a problem for one-way audio, for example, because
   the receiver can adapt to the variance in delay.  However, for
   interactive conversations, minimizing the end-to-end delay is
   critical.  Segmentation of large, non-real-time packets to allow
   small real-time packets to be transmitted between segments can reduce
   the delay.

   This specification deals only with compression and assumes
   segmentation, if included, will be handled as a separate layer.  It
   would be inappropriate to integrate segmentation and compression in
   such a way that the compression could not be used by itself in
   situations where segmentation was deemed unnecessary or impractical.
   Similarly, one would like to avoid any requirements for a reservation
   protocol.  The compression scheme can be applied locally on the two
   ends of a link independent of any other mechanisms except for the
   requirements that the link layer provide some packet type codes, a
   packet length indication, and good error detection.





Casner & Jacobson           Standards Track                     [Page 3]

RFC 2508             Compressing IP/UDP/RTP Headers        February 1999


   Conversely, separately compressing the IP/UDP and RTP layers loses
   too much of the compression gain that is possible by treating them
   together.  Crossing these protocol layer boundaries is appropriate
   because the same function is being applied across all layers.

3.  The Compression Algorithm

   The compression algorithm defined in this document draws heavily upon
   the design of TCP/IP header compression as described in RFC 1144 [2].
   Readers are referred to that RFC for more information on the
   underlying motivations and general principles of header compression.

3.1.  The basic idea

   In TCP header compression, the first factor-of-two reduction in data
   rate comes from the observation that half of the bytes in the IP and
   TCP headers remain constant over the life of the connection.  After
   sending the uncompressed header once, these fields may be elided from
   the compressed headers that follow.  The remaining compression comes
   from differential coding on the changing fields to reduce their size,
   and from eliminating the changing fields entirely for common cases by
   calculating the changes from the length of the packet.  This length
   is indicated by the link-level protocol.

   For RTP header compression, some of the same techniques may be
   applied.  However, the big gain comes from the observation that
   although several fields change in every packet, the difference from
   packet to packet is often constant and therefore the second-order
   difference is zero.  By maintaining both the uncompressed header and
   the first-order differences in the session state shared between the
   compressor and decompressor, all that must be communicated is an
   indication that the second-order difference was zero.  In that case,
   the decompressor can reconstruct the original header without any loss
   of information simply by adding the first-order differences to the
   saved uncompressed header as each compressed packet is received.

   Just as TCP/IP header compression maintains shared state for multiple
   simultaneous TCP connections, this IP/UDP/RTP compression SHOULD
   maintain state for multiple session contexts.  A session context is
   defined by the combination of the IP source and destination
   addresses, the UDP source and destination ports, and the RTP SSRC
   field.  A compressor implementation might use a hash function on
   these fields to index a table of stored session contexts.  The
   compressed packet carries a small integer, called the session context
   identifier or CID, to indicate in which session context that packet
   should be interpreted.  The decompressor can use the CID to index its
   table of stored session contexts directly.




Casner & Jacobson           Standards Track                     [Page 4]

RFC 2508             Compressing IP/UDP/RTP Headers        February 1999


   Because the RTP compression is lossless, it may be applied to any UDP
   traffic that benefits from it.  Most likely, the only packets that
   will benefit are RTP packets, but it is acceptable to use heuristics
   to determine whether or not the packet is an RTP packet because no
   harm is done if the heuristic gives the wrong answer.  This does
   require executing the compression algorithm for all UDP packets, or
   at least those with even port numbers (see section 3.4).

   Most compressor implementations will need to maintain a "negative
   cache" of packet streams that have failed to compress as RTP packets
   for some number of attempts in order to avoid further attempts.
   Failing to compress means that some fields in the potential RTP
   header that are expected to remain constant most of the time, such as
   the payload type field, keep changing.  Even if the other such fields
   remain constant, a packet stream with a constantly changing SSRC
   field SHOULD be entered in the negative cache to avoid consuming all
   of the available session contexts.  The negative cache is indexed by
   the source and destination IP address and UDP port pairs but not the
   RTP SSRC field since the latter may be changing.  When RTP
   compression fails, the IP and UDP headers MAY still be compressed.

   Fragmented IP Packets that are not initial fragments and packets that
   are not long enough to contain a complete UDP header MUST NOT be sent
   as FULL_HEADER packets.  Furthermore, packets that do not
   additionally contain at least 12 bytes of UDP data MUST NOT be used
   to establish RTP context.  If such a packet is sent as a FULL_HEADER
   packet, it MAY be followed by COMPRESSED_UDP packets but MUST NOT be
   followed by COMPRESSED_RTP packets.

3.2.  Header Compression for RTP Data Packets

   In the IPv4 header, only the total length, packet ID, and header
   check-sum fields will normally change.  The total length is redundant
   with the length provided by the link layer, and since this
   compression scheme must depend upon the link layer to provide good
   error detection (e.g., PPP's CRC [4]), the header checksum may also
   be elided.  This leaves only the packet ID, which, assuming no IP
   fragmentation, would not need to be communicated.  However, in order
   to maintain lossless compression, changes in the packet ID will be
   transmitted.  The packet ID usually increments by one or a small
   number for each packet.  (Some systems increment the ID with the
   bytes swapped, which results in slightly less compression.)  In the
   IPv6 base header, there is no packet ID nor header checksum and only
   the payload length field changes.







Casner & Jacobson           Standards Track                     [Page 5]

RFC 2508             Compressing IP/UDP/RTP Headers        February 1999


   In the UDP header, the length field is redundant with the IP total
   length field and the length indicated by the link layer.  The UDP
   check-sum field will be a constant zero if the source elects not to
   generate UDP checksums.  Otherwise, the checksum must be communicated
   intact in order to preserve the lossless compression.  Maintaining
   end-to-end error detection for applications that require it is an
   important principle.

   In the RTP header, the SSRC identifier is constant in a given context
   since that is part of what identifies the particular context.  For
   most packets, only the sequence number and the timestamp will change
   from packet to packet.  If packets are not lost or misordered
   upstream from the compressor, the sequence number will increment by
   one for each packet.  For audio packets of constant duration, the
   timestamp will increment by the number of sample periods conveyed in
   each packet.  For video, the timestamp will change on the first
   packet of each frame, but then stay constant for any additional
   packets in the frame.  If each video frame occupies only one packet,
   but the video frames are generated at a constant rate, then again the
   change in the timestamp from frame to frame is constant.  Note that
   in each of these cases the second-order difference of the sequence
   number and timestamp fields is zero, so the next packet header can be
   constructed from the previous packet header by adding the first-order
   differences for these fields that are stored in the session context
   along with the previous uncompressed header.  When the second-order
   difference is not zero, the magnitude of the change is usually much
   smaller than the full number of bits in the field, so the size can be
   reduced by encoding the new first-order difference and transmitting
   it rather than the absolute value.

   The M bit will be set on the first packet of an audio talkspurt and
   the last packet of a video frame.  If it were treated as a constant
   field such that each change required sending the full RTP header,
   this would reduce the compression significantly.  Therefore, one bit
   in the compressed header will carry the M bit explicitly.

   If the packets are flowing through an RTP mixer, most commonly for
   audio, then the CSRC list and CC count will also change.  However,
   the CSRC list will typically remain constant during a talkspurt or
   longer, so it need be sent only when it changes.

3.3.  The protocol

   The compression protocol must maintain a collection of shared
   information in a consistent state between the compressor and
   decompressor.  There is a separate session context for each
   IP/UDP/RTP packet stream, as defined by a particular combination of
   the IP source and destination addresses, UDP source and destination