doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc2689.txt b/doc/rfc/rfc2689.txt
new file mode 100644
index 0000000..12bb05b
--- /dev/null
+++ b/doc/rfc/rfc2689.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+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
+   technology need only be deployed at bottleneck links; high-speed
+   links can transfer the real-time streams without routers or switches
+   expending CPU cycles to perform header compression.
+
+4.  Principles of Real-Time Encapsulation for Low-Bitrate Links
+
+   The main design goal for a real-time encapsulation is to minimize the
+   delay incurred by real-time packets that become available for sending
+   while a long data packet is being sent.  To achieve this, the
+   encapsulation must be able to either abort or suspend the transfer of
+   the long data packet.  As an additional goal is to minimize the
+   overhead required for the transmission of packets from periodic
+   flows, this strongly argues for being able to suspend a packet, i.e.
+   segment it into parts between which the real-time packets can be
+   transferred.
+
+
+
+Bormann                      Informational                      [Page 5]
+
+RFC 2689       Integrated Services over Low-bitrate Links September 1999
+
+
+4.1.  Using existing IP fragmentation
+
+   Transmitting only part of a packet, to allow higher-priority traffic
+   to intervene and then resuming its transmission later on, is a kind
+   of fragmentation.  Fragmentation is an existing functionality of the
+   IP layer: An IPv4 header already contains fields that allow a large
+   IP datagram to be fragmented into small parts.  A sender's "real-time
+   PPP" implementation might simply indicate a small MTU to its IP stack
+   and thus cause all larger datagrams to be fragmented down to a size
+   that allows the access delay goals to be met (this assumes that the
+   IP stack is able to priority-tag fragments, or that the PPP
+   implementation is able to correlate the fragments to the initial one
+   that carries the information relevant for prioritizing, or that only
+   initial fragments can be high-priority).  (Also, a PPP implementation
+   can negotiate down the MTU of its peer, causing the peer to fragment
+   to a small size, which might be considered a crude form of
+   negotiating an access delay goal with the peer system -- if that
+   system supports priority queueing at the fragment level.)
+
+   Unfortunately, a full, 20 byte IP header is needed for each fragment
+   (larger when IP options are used).  This limits the minimum size of
+   fragments that can be used without too much overhead.  (Also, the
+   size of non-final fragments must be a multiple of 8 bytes, further
+   limiting the choice.)  With path MTU discovery, IP level
+   fragmentation causes TCP implementations to use small MSSs -- this
+   further increases the per-packet overhead to 40 bytes per fragment.
+
+   In any case, fragmentation at the IP level persists on the path
+   further down to the datagram receiver, increasing the transmission
+   overheads and router load throughout the network.  With its high
+   overhead and the adverse effect on the Internet, IP level
+   fragmentation can only be a stop-gap mechanism when no other
+   fragmentation protocol is available in the peer implementation.
+
+4.2.  Link-Layer Mechanisms
+
+   Cell-oriented multiplexing techniques such as ATM that introduce
+   regular points where cells from a different packet can be
+   interpolated are too inefficient for low-bitrate links; also, they
+   are not supported by chips used to support the link layer in low-
+   bitrate routers and host interfaces.
+
+
+
+
+
+
+
+
+
+
+Bormann                      Informational                      [Page 6]
+
+RFC 2689       Integrated Services over Low-bitrate Links September 1999
+
+
+   Instead, the real-time encapsulation should as far as possible make
+   use of the capabilities of the chips that have been deployed.  On
+   synchronous lines, these chips support HDLC framing; on asynchronous
+   lines, an asynchronous variant of HDLC that usually is implemented in
+   software is being used.  Both variants of HDLC provide a delimiting
+   mechanism to indicate the end of a frame over the link.  The obvious
+   solution to the segmentation problem is to combine this mechanism
+   with an indication of whether the delimiter terminates or suspends
+   the current packet.
+
+   This indication could be in an octet appended to each frame
+   information field; however, seven out of eight bits of the octet
+   would be wasted.  Instead, the bit could be carried at the start of
+   the next frame in conjunction with multiplexing information (PPP
+   protocol identifier etc.) that will be required here anyway.  Since
+   the real-time flows will in general be periodic, this multiplexing
+   information could convey (part of) the compressed form of the header
+   for the packet.  If packets from the real-time flow generally are of
+   constant length (or have a defined maximum length that is often
+   used), the continuation of the suspended packet could be immediately
+   attached to it, without expending a further frame delimiter, i.e.,
+   the interpolation of the real-time packet would then have zero
+   overhead.  Since packets from low-delay real-time flows generally
+   will not require the ability to be further suspended, the
+   continuation bit could be reserved for the non-real-time packet
+   stream.
+
+   One real-time encapsulation format with these (and other) functions
+   is described in ITU-T H.223 [13], the multiplex used by the H.324
+   modem-based videophone standard [14].  It was investigated whether
+   compatibility could be achieved with this specification, which will
+   be used in future videophone-enabled (H.324 capable) modems.
+   However, since the multiplexing capabilities of H.223 are limited to
+   15 schedules (definitions of sequences of packet types that can be
+   identified in a multiplex header), for general Internet usage a
+   superset or a more general encapsulation would have been required.
+   Also, a PPP-style negotiation protocol was needed instead of using
+   (and necessarily extending) ITU-T H.245 [15] for setting the
+   parameters of the multiplex.  In the PPP context, the interactions
+   with the encapsulations for data compression and link layer
+   encryption needed to be defined (including operation in the presence
+   of padding).  But most important, H.223 requires synchronous HDLC
+   chips that can be configured to send frames without an attached CRC,
+   which is not possible with all chips deployed in commercially
+   available routers; so complete compatibility was unachievable.
+
+
+
+
+
+
+Bormann                      Informational                      [Page 7]
+
+RFC 2689       Integrated Services over Low-bitrate Links September 1999
+
+
+   Instead of adopting H.223, it was decided to pursue an approach that
+   is oriented towards compatibility both with existing hardware and
+   existing software (in particular PPP) implementations.  The next
+   subsection groups these implementations according to their
+   capabilities.
+
+4.3.  Implementation models
+
+   This section introduces a number of terms for types of
+   implementations that are likely to emerge.  It is important to have
+   these different implementation models in mind as there is no single
+   approach that fits all models best.
+
+4.3.1.  Sender types
+
+   There are two fundamental approaches to real-time transmission on
+   low-bitrate links:
+
+   Sender type 1
+      The PPP real-time framing implementation is able to control the
+      transmission of each byte being transmitted with some known,
+      bounded delay (e.g., due to FIFOs).  For example, this is
+      generally true of PC host implementations, which directly access
+      serial interface chips byte by byte or by filling a very small
+      FIFO.  For type 1 senders, a suspend/resume type approach will be
+      typically used: When a long frame is to be sent, the attempt is to
+      send it undivided; only if higher priority packets come up during
+      the transmission will the lower-priority long frame be suspended
+      and later resumed.  This approach allows the minimum variation in
+      access delay for high-priority packets; also, fragmentation
+      overhead is only incurred when actually needed.
+
+   Sender type 2
+      With type 2 senders, the interface between the PPP real-time
+      framing implementation and the transmission hardware is not in
+      terms of streams of bytes, but in terms of frames, e.g., in the
+      form of multiple (prioritized) send queues directly supported by
+      hardware.  This is often true of router systems for synchronous
+      links, in particular those that have to support a large number of
+      low-bitrate links.  As type 2 senders have no way to suspend a
+      frame once it has been handed down for transmission, they
+      typically will use a queues-of-fragments approach, where long
+      packets are always split into units that are small enough to
+      maintain the access delay goals for higher-priority traffic.
+      There is a trade-off between the variation in access delay
+      resulting from a large fragment size and the overhead that is
+      incurred for every long packet by choosing a small fragment size.
+
+
+
+
+Bormann                      Informational                      [Page 8]
+
+RFC 2689       Integrated Services over Low-bitrate Links September 1999
+
+
+4.3.2.  Receiver types
+
+   Although the actual work of formulating transmission streams for
+   real-time applications is performed at the sender, the ability of the
+   receiver to immediately make use of the information received depends
+   on its characteristics:
+
+   Receiver type 1
+      Type 1 receivers have full control over the stream of bytes
+      received within PPP frames, i.e., bytes received are available
+      immediately to the PPP real-time framing implementation (with some
+      known, bounded delay e.g. due to FIFOs etc.).
+
+   Receiver type 2
+      With type 2 receivers, the PPP real-time framing implementation
+      only gets hold of a frame when it has been received completely,
+      i.e., the final flag has been processed (typically by some HDLC
+      chip that directly fills a memory buffer).
+
+4.4.  Conclusion
+
+   As a result of the diversity in capabilities of current
+   implementations, there are now two specifications for real-time
+   encapsulation: One, the multi-class extension to the PPP multi-link
+   protocol, is providing the solution for the queues-of-fragments
+   approach by extending the single-stream PPP multi-link protocol by
+   multiple classes [8].  The other encapsulation, PPP in a real-time
+   oriented HDLC-like framing, builds on this specification end extends
+   it by a way to dynamically delimit multiple fragments within one HDLC
+   frame [9], providing the solution for the suspend/resume type
+   approach.
+
+5.  Principles of Header Compression for Real-Time Flows
+
+   A good baseline for a discussion about header compression is in the
+   new IP header compression specification that was designed in
+   conjunction with the development of IPv6 [2].  The techniques used
+   there can reduce the 28 bytes of IPv4/UDP header to about 6 bytes
+   (depending on the number of concurrent streams); with the remaining 4
+   bytes of HDLC/PPP overhead and 12 bytes for RTP the total header
+   overhead can be about halved but still exceeds the size of a G.723.1
+   ACELP frame.  Note that, in contrast to IP header compression, the
+   environment discussed here assumes the existence of a full-duplex PPP
+   link and thus can rely on negotiation where IP header compression
+   requires repeated transmission of the same information.  (The use of
+   the architecture of the present document with link layer multicasting
+   has not yet been examined.)
+
+
+
+
+Bormann                      Informational                      [Page 9]
+
+RFC 2689       Integrated Services over Low-bitrate Links September 1999
+
+
+   Additional design effort was required for RTP header compression.
+   Applying the concepts of IP header compression, of the (at least) 12
+   bytes in an RTP header, 7 bytes (timestamp, sequence, and marker bit)
+   would qualify as RANDOM; DELTA encoding cannot generally be used
+   without further information since the lower layer header does not
+   unambiguously identify the semantics and there is no TCP checksum
+   that can be relied on to detect incorrect decompression.  Only a more
+   semantics-oriented approach can provide better compression (just as
+   RFC 1144 can provide very good compression of TCP headers by making
+   use of semantic knowledge of TCP and its checksumming method).
+
+   For RTP packets, differential encoding of the sequence number and
+   timestamps is an efficient approach for certain cases of payload data
+   formats.  E.g., speech flows generally have sequence numbers and
+   timestamp fields that increase by 1 and by the frame size in
+   timestamp units, resp.; the CRTP (compressed RTP) specification makes
+   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 rem-conf@es.net, 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: cabo@tzi.org
+
+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]
+