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.
AbstractThis 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 ; 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. 11, 12], - a setup protocol that allows establishing special forwarding treatment for real-time information flows (RSVP ), - a transport protocol for real-time information (RTP/RTCP ).
In addition to these elements at the network and transport levels of the Internet Multimedia Conferencing Architecture , 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.
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. RFC 1144, ) 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 . Even this perfect solution only reduces the total header overhead by 1/4. It would have to be deployed in all applications,
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  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 ; a companion document describes the mapping of this technique to PPP . 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.
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 , the multiplex used by the H.324 modem-based videophone standard . 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  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.
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.
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 , providing the solution for the suspend/resume type approach. 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.)
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 . 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 , 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.
 Handley, M., Crowcroft, J., Bormann, C. and J. Ott, "The Internet Multimedia Conferencing Architecture", Work in Progress.  Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.  Scott Petrack, Ed Ellesson, "Framework for C/RTP: Compressed RTP Using Adaptive Differential Header Compression", contribution to the mailing list email@example.com, February 1996.  Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.  Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.  Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.  Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.  Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing", RFC 2687, September 1999.  Engan, M., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 2509, February 1999.  Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.  Shenker, S., Partridge, C. and R. Guerin. "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
 ITU-T Recommendation H.223, "Multiplexing protocol for low bit rate multimedia communication", International Telecommunication Union, Telecommunication Standardization Sector (ITU-T), March 1996.  ITU-T Recommendation H.324, "Terminal for low bit rate multimedia communication", International Telecommunication Union, Telecommunication Standardization Sector (ITU-T), March 1996.  ITU-T Recommendation H.245, "Control protocol for multimedia communication", International Telecommunication Union, Telecommunication Standardization Sector (ITU-T), March 1996.
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.