rfc2689.txt

RFC 的详细文档！

Network Working Group                                         C. Bormann
Request for Comments: 2689                       Universitaet Bremen TZI
Category: Informational                                   September 1999


          Providing Integrated Services over Low-bitrate Links

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   This document describes an architecture for providing integrated
   services over low-bitrate links, such as modem lines, ISDN B-
   channels, and sub-T1 links.  It covers only the lower parts of the
   Internet Multimedia Conferencing Architecture [1]; additional
   components required for application services such as Internet
   Telephony (e.g., a session initiation protocol) are outside the scope
   of this document.  The main components of the architecture are: a
   real-time encapsulation format for asynchronous and synchronous low-
   bitrate links, a header compression architecture optimized for real-
   time flows, elements of negotiation protocols used between routers
   (or between hosts and routers), and announcement protocols used by
   applications to allow this negotiation to take place.

1.  Introduction

   As an extension to the "best-effort" services the Internet is well-
   known for, additional types of services ("integrated services") that
   support the transport of real-time multimedia information are being
   developed for, and deployed in the Internet.  Important elements of
   this development are:

   -  parameters for forwarding mechanisms that are appropriate for
      real-time information [11, 12],

   -  a setup protocol that allows establishing special forwarding
      treatment for real-time information flows (RSVP [4]),

   -  a transport protocol for real-time information (RTP/RTCP [6]).




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


   In addition to these elements at the network and transport levels of
   the Internet Multimedia Conferencing Architecture [1], further
   components are required to define application services such as
   Internet Telephony, e.g., protocols for session initiation and
   control.  These components are outside the scope of this document.

   Up to now, the newly developed services could not (or only very
   inefficiently) be used over forwarding paths that include low-bitrate
   links such as 14.4, 33.6, and 56 kbit/s modems, 56 and 64 kbit/s ISDN
   B-channels, or even sub-T1 links.  The encapsulation formats used on
   these links are not appropriate for the simultaneous transport of
   arbitrary data and real-time information that has to meet stringent
   delay requirements.  Transmission of a 1500 byte packet on a 28.8
   kbit/s modem link makes this link unavailable for the transmission of
   real-time information for about 400 ms.  This adds a worst-case delay
   that causes real-time applications to operate with round-trip delays
   on the order of at least a second -- unacceptable for real-time
   conversation.  In addition, the header overhead associated with the
   protocol stacks used is prohibitive on low-bitrate links, where
   compression down to a few dozen bytes per real-time information
   packet is often desirable.  E.g., the overhead of at least 44
   (4+20+8+12) bytes for HDLC/PPP, IP, UDP, and RTP completely
   overshadows typical audio payloads such as the 19.75 bytes needed for
   a G.723.1 ACELP audio frame -- a 14.4 kbit/s link is completely
   consumed by this header overhead alone at 40 real-time frames per
   second total (i.e., at 25 ms packetization delay for one stream or 50
   ms for two streams, with no space left for data, yet).  While the
   header overhead can be reduced by combining several real-time
   information frames into one packet, this increases the delay incurred
   while filling that packet and further detracts from the goal of
   real-time transfer of multi-media information over the Internet.

   This document describes an approach for addressing these problems.
   The main components of the architecture are:

   -  a real-time encapsulation format for asynchronous and synchronous
      low-bitrate links,

   -  a header compression architecture optimized for real-time flows,

   -  elements of negotiation protocols used between routers (or between
      hosts and routers), and

   -  announcement protocols used by applications to allow this
      negotiation to take place.






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


2.  Design Considerations

   The main design goal for an architecture that addresses real-time
   multimedia flows over low-bitrate links is that of minimizing the
   end-to-end delay.  More specifically, the worst case delay (after
   removing possible outliers, which are equivalent to packet losses
   from an application point of view) is what determines the playout
   points selected by the applications and thus the delay actually
   perceived by the user.

   In addition, any such architecture should obviously undertake every
   attempt to maximize the bandwidth actually available to media data;
   overheads must be minimized.

   An important component of the integrated services architecture is the
   provision of reservations for real-time flows.  One of the problems
   that systems on low-bitrate links (routers or hosts) face when
   performing admission control for such reservations is that they must
   translate the bandwidth requested in the reservation to the one
   actually consumed on the link.  Methods such as data compression
   and/or header compression can reduce the requirements on the link,
   but admission control can only make use of the reduced requirements
   in its calculations if it has enough information about the data
   stream to know how effective the compression will be.  One goal of
   the architecture therefore is to provide the integrated services
   admission control with this information.  A beneficial side effect
   may be to allow the systems to perform better compression than would
   be possible without this information.  This may make it worthwhile to
   provide this information even when it is not intended to make a
   reservation for a real-time flow.

3.  The Need for a Concerted Approach

   Many technical approaches come to mind for addressing these problems,
   in particular a new form of low-delay encapsulation to address delay
   and header compression methods to address overhead.  This section
   shows that these techniques should be combined to solve the problem.

3.1.  Real-Time Encapsulation

   The purpose of defining a real-time link-layer encapsulation protocol
   is to be able to introduce newly arrived real-time packets into the
   link-layer data stream without having to wait for the currently
   transmitted (possibly large) packet to end.  Obviously, a real-time
   encapsulation must be part of any complete solution as the problem of
   delays induced by large frames on the link can only be solved on this
   layer.




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


   To be able to switch to a real-time packet quickly in an interface
   driver, it is first necessary to identify packets that belong to
   real-time flows.  This can be done using a heuristic approach (e.g.,
   favor the transmission of highly periodic flows of small packets
   transported in IP/UDP, or use the IP precedence fields in a specific
   way defined within an organization).  Preferably, one also could make
   use of a protocol defined for identifying flows that require special
   treatment, i.e. RSVP.  Of the two service types defined for use with
   RSVP now, the guaranteed service will only be available in certain
   environments; for this and various other reasons, the service type
   chosen for many adaptive audio/video applications will most likely be
   the controlled-load service.  Controlled-load does not provide
   control parameters for target delay; thus it does not unambiguously
   identify those packet streams that would benefit most from being
   transported in a real-time encapsulation format.  This calls for a
   way to provide additional parameters in integrated services flow
   setup protocols to control the real-time encapsulation.

   Real-time encapsulation is not sufficient on its own, however: Even
   if the relevant flows can be appropriately identified for real-time
   treatment, most applications simply cannot operate properly on low-
   bitrate links with the header overhead implied by the combination of
   HDLC/PPP, IP, UDP, and RTP, i.e. they absolutely require header
   compression.

3.2.  Header Compression

   Header compression can be performed in a variety of elements and at a
   variety of levels in the protocol architecture.  As many vendors of
   Internet Telephony products for PCs ship applications, the approach
   that is most obvious to them is to reduce overhead by performing
   header compression at the application level, i.e. above transport
   protocols such as UDP (or actually by using a non-standard,
   efficiently coded header in the first place).

   Generally, header compression operates by installing state at both
   ends of a path that allows the receiving end to reconstruct
   information omitted at the sending end.  Many good techniques for
   header compression (RFC 1144, [2]) operate on the assumption that the
   path will not reorder the frames generated.  This assumption does not
   hold for end-to-end compression; therefore additional overhead is
   required for resequencing state changes and for compressed packets
   making use of these state changes.

   Assume that a very good application level header compression solution
   for RTP flows could be able to save 11 out of the 12 bytes of an RTP
   header [3].  Even this perfect solution only reduces the total header
   overhead by 1/4.  It would have to be deployed in all applications,



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


   even those that operate on systems that are attached to higher-
   bitrate links.

   Because of this limited effectiveness, the AVT group that is
   responsible for RTP within the IETF has decided to not further pursue
   application level header compression.

   For router and IP stack vendors, the obvious approach is to define
   header compression that can be negotiated between peer routers.

   Advanced header compression techniques now being defined in the IETF
   [2] certainly can relieve the link from significant parts of the
   IP/UDP overhead (i.e., most of 28 of the 44 bytes mentioned above).

   One of the design principles of the new IP header compression
   developed in conjunction with IPv6 is that it stops at layers the
   semantics of which cannot be inferred from information in lower layer
   (outer) headers.  Therefore, this header compression technique alone
   cannot compress the data that is contained within UDP packets.

   Any additional header compression technique runs into a problem: If
   it assumes specific application semantics (i.e., those of RTP and a
   payload data format) based on heuristics, it runs the risk of being
   triggered falsely and (e.g. in case of packet loss) reconstructing
   packets that are catastrophically incorrect for the application
   actually being used.  A header compression technique that can be
   operated based on heuristics but does not cause incorrect
   decompression even if the heuristics failed is described in [7]; a
   companion document describes the mapping of this technique to PPP
   [10].

   With all of these techniques, the total IP/UDP/RTP header overhead
   for an audio stream can be reduced to two bytes per packet.  This