rfc2508.txt

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

RFC 2508             Compressing IP/UDP/RTP Headers        February 1999


   indicated by a checksum match.  For the scheme defined here, the
   difference in the 4- bit sequence number tells number of times the
   delta must be applied.  Note, however, that there is a nontrivial
   risk of an incorrect positive indication.  It may be advisable to
   request a FULL_HEADER or COMPRESSED_NON_TCP packet even if the
   "twice" algorithm succeeds.

   Some errors may not be detected, for example if 16 packets are lost
   in a row and the link level does not provide an error indication.  In
   that case, the decompressor will generate packets that are not valid.
   If UDP checksums are being transmitted, the receiver will probably
   detect the invalid packets and discard them, but the receiver does
   not have any means to signal the decompressor.  Therefore, it is
   RECOMMENDED that the decompressor verify the UDP checksum
   periodically, perhaps one out of 16 packets.  If an error is
   detected, the decompressor would invalidate the context and signal
   the compressor with a CONTEXT_STATE packet.

3.4.  Compression of RTCP Control Packets

   By relying on the RTP convention that data is carried on an even port
   number and the corresponding RTCP packets are carried on the next
   higher (odd) port number, one could tailor separate compression
   schemes to be applied to RTP and RTCP packets.  For RTCP, the
   compression could apply not only to the header but also the "data",
   that is, the contents of the different packet types.  The numbers in
   Sender Report (SR) and Receiver Report (RR) RTCP packets would not
   compress well, but the text information in the Source Description
   (SDES) packets could be compressed down to a bit mask indicating each
   item that was present but compressed out (for timing purposes on the
   SDES NOTE item and to allow the end system to measure the average
   RTCP packet size for the interval calculation).

   However, in the compression scheme defined here, no compression will
   be done on the RTCP headers and "data" for several reasons (though
   compression SHOULD still be applied to the IP and UDP headers).
   Since the RTP protocol specification suggests that the RTCP packet
   interval be scaled so that the aggregate RTCP bandwidth used by all
   participants in a session will be no more than 5% of the session
   bandwidth, there is not much to be gained from RTCP compression.
   Compressing out the SDES items would require a significant increase
   in the shared state that must be stored for each context ID.  And, in
   order to allow compression when SDES information for several sources
   was sent through an RTP "mixer", it would be necessary to maintain a
   separate RTCP session context for each SSRC identifier.  In a session
   with more than 255 participants, this would cause perfect thrashing
   of the context cache even when only one participant was sending data.




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


   Even though RTCP is not compressed, the fraction of the total
   bandwidth occupied by RTCP packets on the compressed link remains no
   more than 5% in most cases, assuming that the RTCP packets are sent
   as COMPRESSED_UDP packets.  Given that the uncompressed RTCP traffic
   consumes no more than 5% of the total session bandwidth, then for a
   typical RTCP packet length of 90 bytes, the portion of the compressed
   bandwidth used by RTCP will be no more than 5% if the size of the
   payload in RTP data packets is at least 108 bytes.  If the size of
   the RTP data payload is smaller, the fraction will increase, but is
   still less than 7% for a payload size of 37 bytes.  For large data
   payloads, the compressed RTCP fraction is less than the uncompressed
   RTCP fraction (for example, 4% at 1000 bytes).

3.5.  Compression of non-RTP UDP Packets

   As described earlier, the COMPRESSED_UDP packet MAY be used to
   compress UDP packets that don't carry RTP.  Whatever data follows the
   UDP header is unlikely to have some constant values in the bits that
   correspond to usually constant fields in the RTP header.  In
   particular, the SSRC field would likely change.  Therefore, it is
   necessary to keep track of the non-RTP UDP packet streams to avoid
   using up all the context slots as the "SSRC field" changes (since
   that field is part of what identifies a particular RTP context).
   Those streams may each be given a context, but the encoder would set
   a flag in the context to indicate that the changing SSRC field should
   be ignored and COMPRESSED_UDP packets should always be sent instead
   of COMPRESSED_RTP packets.

4.  Interaction With Segmentation

   A segmentation scheme may be used in conjunction with RTP header
   compression to allow small, real-time packets to interrupt large,
   presumably non-real-time packets in order to reduce delay.  It is
   assumed that the large packets bypass the compressor and decompressor
   since the interleaving would modify the sequencing of packets at the
   decompressor and cause the appearance of errors.  Header compression
   should be less important for large packets since the overhead ratio
   is smaller.

   If some packets from an RTP session context are selected for
   segmentation (perhaps based on size) and some are not, there is a
   possibility of re-ordering.  This would reduce the compression
   efficiency because the large packets would appear as lost packets in
   the sequence space.  However, this should not cause more serious
   problems because the RTP sequence numbers should be reconstructed
   correctly and will allow the application to correct the ordering.





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


   Link errors detected by the segmentation scheme using its own
   sequencing information MAY be indicated to the compressor with an
   advisory CONTEXT_STATE message just as for link errors detected by
   the link layer itself.

   The context ID byte is placed first in the COMPRESSED_RTP header so
   that this byte MAY be shared with the segmentation layer if such
   sharing is feasible and has been negotiated.  Since the compressor
   may assign context ID values arbitrarily, the value can be set to
   match the context identifier from the segmentation layer.

5.  Negotiating Compression

   The use of IP/UDP/RTP compression over a particular link is a
   function of the link-layer protocol.  It is expected that such
   negotiation will be defined separately for PPP [4], for example.  The
   following items MAY be negotiated:

      o The size of the context ID.
      o The maximum size of the stack of headers in the context.
      o A context-specific table for decoding of delta values.

6.  Acknowledgments

   Several people have contributed to the design of this compression
   scheme and related problems.  Scott Petrack initiated discussion of
   RTP header compression in the AVT working group at Los Angeles in
   March, 1996.  Carsten Bormann has developed an overall architecture
   for compression in combination with traffic control across a low-
   speed link, and made several specific contributions to the scheme
   described here.  David Oran independently developed a note based on
   similar ideas, and suggested the use of PPP Multilink protocol for
   segmentation.  Mikael Degermark has contributed advice on integration
   of this compression scheme with the IPv6 compression framework.

















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


7.  References:

   [1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
       A Transport Protocol for real-time applications", RFC 1889,
       January 1996.

   [2] Jacobson, V., "TCP/IP Compression for Low-Speed Serial Links",
       RFC 1144, February 1990.

   [3] Degermark, M., Nordgren, B. and S. Pink, "Header Compression for
       IPv6", RFC 2507, February 1999.

   [4] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
       1661, July 1994.

   [5] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP
       Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.

8.  Security Considerations

   Because encryption eliminates the redundancy that this compression
   scheme tries to exploit, there is some inducement to forego
   encryption in order to achieve operation over a low-bandwidth link.
   However, for those cases where encryption of data and not headers is
   satisfactory, RTP does specify an alternative encryption method in
   which only the RTP payload is encrypted and the headers are left in
   the clear.  That would allow compression to still be applied.

   A malfunctioning or malicious compressor could cause the decompressor
   to reconstitute packets that do not match the original packets but
   still have valid IP, UDP and RTP headers and possibly even valid UDP
   check-sums.  Such corruption may be detected with end-to-end
   authentication and integrity mechanisms which will not be affected by
   the compression.  Constant portions of authentication headers will be
   compressed as described in [3].

   No authentication is performed on the CONTEXT_STATE control packet
   sent by this protocol.  An attacker with access to the link between
   the decompressor and compressor could inject false CONTEXT_STATE
   packets and cause compression efficiency to be reduced, probably
   resulting in congestion on the link.  However, an attacker with
   access to the link could also disrupt the traffic in many other ways.

   A potential denial-of-service threat exists when using compression
   techniques that have non-uniform receiver-end computational load.
   The attacker can inject pathological datagrams into the stream which
   are complex to decompress and cause the receiver to be overloaded and
   degrading processing of other streams.  However, this compression



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


   does not exhibit any significant non-uniformity.

   A security review of this protocol found no additional security
   considerations.

9.  Authors' Addresses

   Stephen L. Casner
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134-1706
   United States

   EMail: [e-mail]


   Van Jacobson
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134-1706
   United States

   EMail: [e-mail]




























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


10.  Full Copyright Statement

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
























Casner & Jacobson           Standards Track                    [Page 24]