rfc2689.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   use of this relationship by encoding these fields only when the
   second order difference is non-zero [7].

6.  Announcement Protocols Used by Applications

   As argued, the compressor can operate best if it can make use of
   information that clearly identifies real-time streams and provides
   information about the payload data format in use.

   If these systems are routers, this consent must be installed as
   router state; if these systems are hosts, it must be known to their
   networking kernels.  Sources of real-time information flows are
   already describing characteristics of these flows to their kernels
   and to the routers in the form of TSpecs in RSVP PATH messages [4].
   Since these messages make use of the router alert option, they are
   seen by all routers on the path; path state about the packet stream
   is normally installed at each of these routers that implement RSVP.
   Additional RSVP objects could be defined that are included in PATH
   messages by those applications that desire good performance over low-
   bitrate links; these objects would be coded to be ignored by routers
   that are not interested in them (class number 11bbbbbb as defined in
   [4], section 3.10).

   Note that the path state is available in the routers even when no
   reservation is made; this allows informed compression of best-effort
   traffic.  It is not quite clear, though, how path state could be torn
   down quickly when a source ceases to transmit.








Bormann                      Informational                     [Page 10]

RFC 2689       Integrated Services over Low-bitrate Links September 1999


7.  Elements of Hop-By-Hop Negotiation Protocols

   The IP header compression specification attempts to account for
   simplex and multicast links by providing information about the
   compressed streams only in the forward direction.  E.g., a full
   IP/UDP header must be sent after F_MAX_TIME (currently 3 seconds),
   which is a negligible total overhead (e.g. one full header every 150
   G.723.1 packets), but must be considered carefully in scheduling the
   real-time transmissions.  Both simplex and multicast links are not
   prevailing in the low-bitrate environment (although multicast
   functionality may become more important with wireless systems); in
   this document, we therefore assume full-duplex capability.

   As compression techniques will improve, a negotiation between the two
   peers on the link would provide the best flexibility in
   implementation complexity and potential for extensibility.  The peer
   routers/hosts can decide which real-time packet streams are to be
   compressed, which header fields are not to be sent at all, which
   multiplexing information should be used on the link, and how the
   remaining header fields should be encoded.  PPP, a well-tried suite
   of negotiation protocols, is already used on most of the low-bitrate
   links and seems to provide the obvious approach.  Cooperation from
   PPP is also needed to negotiate the use of real-time encapsulations
   between systems that are not configured to automatically do so.
   Therefore, PPP options that can be negotiated at the link setup (LCP)
   phase are included in [8], [9], and [10].

8.  Security Considerations

   Header compression protocols that make use of assumptions about
   application protocols need to be carefully analyzed whether it is
   possible to subvert other applications by maliciously or
   inadvertently enabling their use.

   It is generally not possible to do significant hop-by-hop header
   compression on encrypted streams.  With certain security policies, it
   may be possible to run an encrypted tunnel to a network access server
   that does header compression on the decapsulated packets and sends
   them over an encrypted link encapsulation; see also the short mention
   of interactions between real-time encapsulation and encryption in
   section 4 above.  If the security requirements permit, a special RTP
   payload data format that encrypts only the data may preferably be
   used.








Bormann                      Informational                     [Page 11]

RFC 2689       Integrated Services over Low-bitrate Links September 1999


9.  References


    [1]  Handley, M., Crowcroft, J., Bormann, C. and J. Ott, "The
         Internet Multimedia Conferencing Architecture", Work in
         Progress.

    [2]  Degermark, M., Nordgren, B. and S. Pink, "IP Header
         Compression", RFC 2507, February 1999.

    [3]  Scott Petrack, Ed Ellesson, "Framework for C/RTP: Compressed
         RTP Using Adaptive Differential Header Compression",
         contribution to the mailing list [e-mail], February
         1996.

    [4]  Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
         "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
         Specification", RFC 2205, September 1997.

    [5]  Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T.
         Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August
         1996.

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

    [7]  Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for
         Low-Speed Serial Links", RFC 2508, February 1999.

    [8]  Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC
         2686, September 1999.

    [9]  Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing",
         RFC 2687, September 1999.

   [10]  Engan, M., Casner, S. and C. Bormann, "IP Header Compression
         over PPP", RFC 2509, February 1999.

   [11]  Wroclawski, J.,   "Specification of the Controlled-Load Network
         Element Service", RFC 2211, September 1997.

   [12]  Shenker, S., Partridge, C. and R. Guerin.  "Specification of
         Guaranteed Quality of Service", RFC 2212, September 1997.







Bormann                      Informational                     [Page 12]

RFC 2689       Integrated Services over Low-bitrate Links September 1999


   [13]  ITU-T Recommendation H.223, "Multiplexing protocol for low bit
         rate multimedia communication", International Telecommunication
         Union, Telecommunication Standardization Sector (ITU-T), March
         1996.

   [14]  ITU-T Recommendation H.324, "Terminal for low bit rate
         multimedia communication", International Telecommunication
         Union, Telecommunication Standardization Sector (ITU-T), March
         1996.

   [15]  ITU-T Recommendation H.245, "Control protocol for multimedia
         communication", International Telecommunication Union,
         Telecommunication Standardization Sector (ITU-T), March 1996.

10.  Author's Address

   Carsten Bormann
   Universitaet Bremen FB3 TZI
   Postfach 330440
   D-28334 Bremen, GERMANY

   Phone: +49.421.218-7024
   Fax:   +49.421.218-7000
   EMail: [e-mail]

Acknowledgements

   Much of the early discussion that led to this document was done with
   Scott Petrack and Cary Fitzgerald.  Steve Casner, Mikael Degermark,
   Steve Jackowski, Dave Oran, the other members of the ISSLL subgroup
   on low bitrate links (ISSLOW), and in particular the ISSLL WG co-
   chairs Eric Crawley and John Wroclawski have helped in making this
   architecture a reality.


















Bormann                      Informational                     [Page 13]

RFC 2689       Integrated Services over Low-bitrate Links September 1999


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.

Acknowledgement

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



















Bormann                      Informational                     [Page 14]