INTERNET-DRAFT Carsten Bormann Expires: December 1996 Universitaet Bremen June 1996 Providing integrated services over low-bitrate links draft-ietf-issll-isslow-00.txt Status of this memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. 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. Annexes contain initial strawman proposals for the elements of the architecture, complemented by a list of issues that need to be resolved to proceed. This document is a submission to the IETF ISSLL working-group-in- creation. Comments are solicited and should be addressed to the working group's mailing list at issll@mercury.lcs.mit.edu and/or the author. Bormann [Page 1] INTERNET-DProviding integrated services over low-bitrate links June 1996 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 (in the intserv working group of the IETF) - a setup protocol that allows establishing special forwarding treatment for real-time information flows (RSVP [4], in the rsvp working group of the IETF) - a transport protocol for real-time information (RTP/RTCP, in the avt working group of the IETF)[1]. 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 and 28.8 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. 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 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 (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. _________________________ [1] Note that this document only is concerned with the network and transport parts of the Internet Multimedia Conferencing Archi- tecture [1]. To define application services such as Internet Telephony, additional components are required, e.g., protocols for session initiation and control. These components are outside the scope of this document. Bormann [Page 2] INTERNET-DProviding integrated services over low-bitrate links June 1996 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. 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 Given that there are so many technical approaches to addressing the problem, one wonders whether maybe one of these techniques could suffice or whether maybe they could be applied independently of each Bormann [Page 3] INTERNET-DProviding integrated services over low-bitrate links June 1996 other, reducing the need for synchronization between IETF working groups and the need for verbose architecture papers such as the present one. This section therefore examines the opportunities of using each of a number of these techniques in isolation. 3.1. Defining a Real-Time Encapsulation Only The purpose of defining a real-time link-layer encapsulation protocol is to be able to introduce newly arrived real-time packets in the link-layer data stream without having to wait for the currently transmitted (possibly large) packet to end. To be able to do this in an interface driver, it is first necessary to identify packets that belong to these flows. If one does not want to resort to a heuristic approach (e.g., favor the transmission of highly periodic flows of small packets transported in IP/UDP[2]), one should make use of the 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 obvious service type for most adaptive audio/video applications will be the controlled-load service. Controlled-load does not provide control parameters for target delay; this makes it very hard to identify those packet streams that would benefit most of being transported in a real-time encapsulation format. 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. It is not sufficient on its own, however: Even if the relevant flows can be appropriately identified for real-time treatment, most applications simply are not possible 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. Using Application Header Compression Only For the internet telephone vendors, the approach that comes to mind immediately is to reduce overhead by building header compression into the applications[3]. Generally, header compression operates by installing state at both ends of a link that allows the receiving end to reconstruct information omitted at the sending end. Many good techniques for _________________________ [2] Which could turn out to be a DNS implementation gone wild or a malicious attempt to gain preferential access to an Internet re- source. [3] or actually by using a non-standard, efficiently coded head- er in the first place. Bormann [Page 4] INTERNET-DProviding integrated services over low-bitrate links June 1996 header compression (RFC 1144, [2]) operate on the assumption that the link 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 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, even those that operate on systems that are attached to higher- bitrate links. 3.3. Using Hop-By-Hop Header Compression Only For router 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., of 28 of the 44 bytes mentioned above). One of the design principles of the header compression contemplated for IPv6 is that it stops at layers the semantics of which cannot be inferred from information in lower layer (outer) headers. Therefore, IPv6 header compression cannot compress the data within UDP packets. Any additional header compression technique runs into a difficult 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. If it does not presume application semantics, it will only be able to achieve limited compression, as it needs to carry sufficient information in each packet that, even in the presence of packet loss on the link, only packets are ever reconstructed that are correct bit-by-bit. Together with link layer overheads, it is likely that more than half of the 19.75 bytes used for a G.723.1 ACELP frame would be needed for header overhead. 4. A Real-Time Encapsulation Format 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. 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 Bormann [Page 5] INTERNET-DProviding integrated services over low-bitrate links June 1996 into parts between which the real-time packets can be transferred. 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. 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. A real-time encapsulation with these (and other) functions is described in ITU-T H.223. It may be desirable to strive for compatibility 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), it may be desirable to define a superset or a more general encapsulation. It may also be desirable to rely on a PPP- style negotiation protocol instead of using (and necessarily extending) ITU-T H.245 for setting the parameters of the multiplex. The interactions with the encapsulations for data compression and link layer encryption need to be defined (including operation in the presence of padding). Finally, 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; additional flexibility is needed here. Annex A provides further considerations about real-time Bormann [Page 6] INTERNET-DProviding integrated services over low-bitrate links June 1996 encapsulations. 5. A Header Compression Architecture for Real-Time Flows A good baseline for a discussion about header compression is in the IPv6 header compression draft [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 IPv6 header compression, the present document assumes the existence of a full-duplex PPP link and thus can rely on negotiation where IPv6 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 is required for RTP header compression. Applying the concepts of IPv6 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.; for encodings such as G.723.1, a seven-bit (leaving space for the marker bit) field that conveys both would provide security against +- 2 seconds of delay jitter for G.723.1 (the compressor would need to drop or more expensively code all packets outside that jitter window). For a certain subset of these cases, the encoding of these fields is essentially optional as errors caused by incorrect decompression after single packet loss on the link are of minor significance in the playout process; the compressor would have to reorder or drop misordered packets (the RTP marker bit could be inserted into one of the two unused bits for a G.723.1 ACELP payload data format). Annex C provides further considerations about RTP header compression. 6. Announcement Protocols Used by Applications It should be obvious from the discussion of header compression that the compressor can operate best if it can make use of information Bormann [Page 7] INTERNET-DProviding integrated services over low-bitrate links June 1996 that clearly identifies real-time streams and provides information about the payload data format in use. For the more aggressive compression methods that in certain cases can induce information loss, the systems on the low-bitrate link should have consent from the application to actually go this far. 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). 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 to the author how path state could be teared down quickly when a source ceases to transmit. To be able do deploy informed header compression before RSVP, an additional form of application announcements could be defined that do not require RSVP to be available at the transmitting host; it would be advisable to use the router alert option on these messages, too. Alternatively, UDP encapsulation of RSVP could be used (note that a way needs to be available to inform the local kernel if the system is directly on a low-bitrate link). Annex D provides further considerations about announcement protocols. 7. Elements of Hop-By-Hop Negotiation Protocols The IPv6 header compression draft 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 Bormann [Page 8] INTERNET-DProviding integrated services over low-bitrate links June 1996 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. 8. A Plan for Further Work This section proposes a rough work plan to develop and deploy this architecture. This plan obviously needs to be discussed between the parties involved. The overall responsibility for this work could be in the domain of the newly created IETF issll (Integrated Services over Specific Link Layers) working group. The pppext working group would be the logical place to discuss the real-time encapsulation and pertinent negotiation protocols. Work on RTP compression, including compression methods specific to particular payload data formats should be done within the avt working group; this should include media-specific input for the negotiation protocols (a format for describing information about media flows has been defined in the mmusic working group). The rsvp working group should agree to the way PATH messages are used and provide a code point for the new RSVP object. Initial deployment of the real-time encapsulation could be in network access servers and access routers, with IP stacks on hosts following. Outreach activities are probably required to receive timely input from application vendors. In addition to the work described in this document, additional work is required to define the service mappings for controlled-load and guaranteed services on serial links; the latter also requires techniques to find out about the delay of the link. The following schedule is suggested: Item Draft WG last date call date 1: Realtime Header-compression and packet framing protocol 8/96 2/97 2: Controlled Load Service over ISSLOW 8/96 TBD 3: Link Delay Measurement Protocol TBD 4: Guaranteed Service over ISSLOW TBD Obviously, item 1 requires particularly close coordination with pppext (for the framing format) and avt (for RTP header compression), as well as with the group working on IPv6 header compression, ipngwg. Bormann [Page 9] INTERNET-DProviding integrated services over low-bitrate links June 1996 9. 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. 10. Author's Address Carsten Bormann Universitaet Bremen FB3 MZH 5180 Postfach 330440 D-28334 Bremen GERMANY cabo@informatik.uni-bremen.de phone +49.421.218-7024 Acknowledgements Much of the discussion in this document is based on discussions with Scott Petrack of IBM Israel and Cary Fitzgerald of Cisco Systems. 11. References [1] Mark Handley, Jon Crowcroft, Carsten Bormann, ``The Internet Multimedia Conferencing Architecture,'' Internet-Draft draft- ietf-mmusic-confarch-00.txt, Work in Progress, February 1996. [2] M. Degermark, B. Nordgren, S. Pink, ``Header Compression for IPv6,'' Internet-Draft draft-degermark-ipv6-hc-00.txt, Work in Progress, February 1996. [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] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification, Internet-Draft draft-ietf-rsvp-spec-10.txt, Work in Progress, February 1996. [5] K. Sklower, B. Lloyd, G. McGregor, D. Carr, The PPP Multilink Bormann [Page 10] INTERNET-DProviding integrated services over low-bitrate links June 1996 Protocol (MP), RFC 1717, November 1994. Bormann [Page 11] INTERNET-DProviding integrated services over low-bitrate links June 1996 A. Strawman for a real-time encapsulation This annex provides one possible design for a real-time encapsulation (RTE). The approach chosen here is to be close to H.223 in spirit, but not necessarily be fully compliant to it. Several reasons can be given for this: 1) It is not clear that many serial chips used in current router products can turn off the per-frame CRC as is required by H.223. Being compatible may thus simply be impossible. 2) Full compliance to H.223 requires H.245, which in turn requires X.691 (ASN.1 packed encoding rules or PER). Very few products are available for generating PER ASN.1 encoding. H.245 is a complex standard that is changing rapidly already only a few months after being standardized. 3) H.223 is limited to 15 simultaneous table indices (see below), which may be to small for even 56 kbit/s links. Extending this limit would lose compliance in the general case (an extension mechanism that allows compliance in the basic case is possible, though). 4) H.223 is intended to be used over synchronous links. Much initial use of RTE will be over links that are used with asynchronous protocols. There is little incentive to be compatible with H.223 in this case. 5) H.223 is standardized in the H.324 context, i.e. for use directly over synchronous modem links. Today's modems generally require the use of V.42 to enable HDLC-style synchronous operation while connecting to asynchronous PC interfaces. It is not clear to the author that consumer modems will offer a way to interface to their synchronous data pumps in a way that H.223 can be part of a mass-market product. Obviously, for each of these reasons there are quite plausible counter-arguments; the author of this draft is open to suggestions. A.1. Terminology This document uses the following terms as in RFC 1662: datagram The unit of transmission in the network layer (such as IP). A datagram may be encapsulated in one or more packets passed to the data link layer. frameThe unit of transmission at the data link layer. A frame may include a header and/or a trailer, along with some number of units of data. packetThe basic unit of encapsulation, which is passed across the Bormann [Page 12] INTERNET-DProviding integrated services over low-bitrate links June 1996 interface between the network layer and the data link layer. A packet is usually mapped to a frame; the exceptions are when data link layer fragmentation is being performed, or when multiple packets are incorporated into a single frame. In addition, we use the following terms (better suggestions are welcome): segment A part of a packet that is encapsulated as part of a frame. blockA part of a frame that is used to carry a segment. final block A block carrying the last or only segment of a packet. continued block A block carrying any but the final segment of a packet. A.2. Principles RTE should be as close as possible to generic PPP encapsulation. Frames are delimited by HDLC flags. For asynchronous operation, we retain the octet-stuffing method defined in RFC1662; for synchronous operation we retain bit-stuffing. As an additional requirement, a PPP LCP frame (that could be sent in RFC 1662 form when one peer returns to the PPP Starting state) must not be confused with a valid RTE frame. Therefore, RTE is designed such that no RTE frame can start with a 0xff byte (or the equivalent octet-stuffed sequence). (Note that there is no need to simultaneously cope with address/control field compressed packets, as RTE is intended as an alternative to that PPP feature.) Since on many synchronous HDLC chips the CRC generation/checking cannot be switched off, a frame end imposes an overhead of at least 24 bits (32 if single-flag delimiting is not possible). As many blocks will be very small, this is significant overhead; therefore, RTE provides for more than one block to be carried in a frame. To achieve maximum compression, we distinguish three types of blocks: 1) ``Small'' constant-size blocks from real-time flows, 2) ``Small'' variable-size blocks, e.g. from real-time flows, and 3) ``Large'' variable-size blocks, e.g. from non-real-time flows. To achieve small delays, type 3 blocks can be preempted by type 1 and type 2 blocks, i.e. transmission of a type 3 block can be suspended to make way for a type 1 or 2 block with real-time requirements. Since the need for this is generally not known at the time the type 3 block is started, a way is needed to unambiguously signify the end of Bormann [Page 13] INTERNET-DProviding integrated services over low-bitrate links June 1996 the block during its transmission; the end of the frame is used as this indication. The information whether this end-of-frame condition signifies the end of the final block of the packet or just the end of a continued block, can be represented in one bit; this bit is packed into additional header information at the start of the next frame[4]. A CRC is added to packets transported in one or more type 3 blocks so that incorrect reception of the continuation status can be detected. The header information at the start of a frame contains an index into a frame composition table. The table entry identifies the PPP protocol identifiers of the blocks that are to be sent in this frame. It also contains length information for the type 1 blocks. The frame header is protected by a short CRC: 1) For links that can switch off the CRC generation (including most asynchronous links), it is useful to have some protection of the table index. 2) Even if the frame level CRC generation cannot be switched off, it minimizes delay to release the contents of blocks to the network layer before the end of the frame has been reached; the frame header must be verified early for this to be safe. The coding of the continuation bit, table index, and header CRC is chosen to reserve a 0xff initial header byte to signify that the HDLC frame contains RFC1662 encapsulated data instead of RTE data. A.3. Example This section presents a simple example scenario and some frames taken from that scenario. An RTE link is being used by an Internet videophone attached to an asynchronous serial line. Two real-time flows have been identified via RSVP: A G.723.1 audio stream of 20 byte audio units and a H.263 video stream of variable size video units, both encapsulated in RTP/UDP/IP. For this application, the data link layer peers agree to set the frame composition table for this direction as follows: Index Sequence ------------------------------------------------------------------- _________________________ [4] Note that it also would be possible to define an alternative closing delimiter for HDLC frames that are suspended. This would be very hard to implement with most chips for synchronous HDLC, but in many cases quite easy for asynchronous HDLC. Since diverg- ing encapsulations for synchronous and asynchronous HDLC would be a bad thing, this is not pursued further. Bormann [Page 14] INTERNET-DProviding integrated services over low-bitrate links June 1996 n0 type 3 block, protocol ID 0x21. ------------------------------------------------------------------- n1 type 1 block, compression table index 1, length 20 bytes; type 3 block, protocol ID 0x21. ------------------------------------------------------------------- n2 type 2 block, frame delimited, compression table index 2. ------------------------------------------------------------------- n3 type 1 block, compression table index 1, length 20 bytes; type 2 block, frame delimited, compression table index 2. ------------------------------------------------------------------- Note that the compression table is defined by the combined RTP and UDP/IP/PPP header compression, this in turn includes a protocol ID and other information about the flow being compressed. All IP packets from flows other than the two specifically reserved are sent with index n0. As the frame CRC is elided, the additional type 3 per-packet CRC generates no additional overhead compared to a normal, address and control field compressed PPP frame. Each time an audio frame needs to be sent, a frame is sent with header index n1. A type 3 block containing information from any other IP packet can (but need not) be attached to this frame; including a continuation block of a type 3 packet that was interrupted to make way for the audio frame. Assuming that no CRC is needed for the audio frame itself, the overhead for transmitting the audio frame is at most one flag byte and one header byte; if no frame needed to be interrupted, the encapsulation overhead is zero. A similar procedure is used for transmitting the video packets. Note that this example assumes that both type 2 and type 3 blocks are terminated by a frame delimiter; for certain cases on synchronous links where the CRC cannot be switched off, it may be advantageous to precede type 2 blocks by a length indication. In this case, a number of combinations of type 1 and type 2 blocks followed by a single type 3 block could be expressed by appropriate table entries without additional overhead. A.4. Encapsulation issues 1) What is the degree of H.223 compatibility required? 2) Are type 2 blocks really useful? 3) What is the stacking level of preemption that is actually required? H.223 only provides for one level (the H.223 equivalent of a type 3 block terminates or continues the last block of this type). 4) Are there implementations that would have trouble handing up a type 1 block immediately that is followed in the same frame by a Bormann [Page 15] INTERNET-DProviding integrated services over low-bitrate links June 1996 long type 3 block? Are there enough implementations that would not have trouble doing that that the concatenation feature is worthwhile? 5) Would it be useful to pursue a to-be-suspended indication at the end of a frame modeled on self-describing padding, i.e. using special end-of-frame bytes with escapes (maybe just for synchronous PPP, in combination with an alternative delimiter style mechanism with asynchronous PPP)? Bormann [Page 16] INTERNET-DProviding integrated services over low-bitrate links June 1996 A.5. A simple approach: SRTE The previous subsections outlined a way to define an encapsulation similar to H.223. This section attempts to define a simpler encapsulation with less functionality. A.5.1. Suspending frames The suspension flag is contained in the last byte of each frame information field. If the byte has the value SUSPEND (TBD), the frame is suspended; the byte is not part of the frame. If the byte has the value TERMINATE (TBD), the frame is terminated; the byte is not part of the frame. If the byte has any other value, the frame is terminated; the byte is part of the fragment. (Assuming an equal distribution of final bytes, the average overhead of this scheme for non-suspended frames is 1/128 byte; the overhead for suspended frames is 1 byte.) A.5.2. Resuming frames A special protocol identifier and header is used for identifying blocks that resume packets. Two problems need to be solved: 1) Of possibly multiple suspended packets, the correct packet needs to be resumed. 2) Loss of frames should be detected reliably. The first problem can be solved by giving a ``stream number'' to each packet. Only packets with different stream numbers can overtake each other. A small number of streams (three or four) should be sufficient. As the stream number composed of all one bits is never used to reliably exclude a 0xFF first header byte, three bits are reserved to carry the stream number in the SRTE header. The second problem can be made less likely by sequentially numbering the blocks in each stream. A high degree of safety requires a long serial number or a checksum over the packet. In this subsection, we will assume that a 3-bit sequence number is sufficient. Together, serial and stream number will fit in slightly less than one byte. A.5.3. Reducing insertion overhead The resumption header has one optional additional byte that indicates the length of a block that is inserted in front of the packet to be resumed, as well as two bits to indicate a stream number between 0 and 3. This reduces the overhead of insertion to the size of an SRTE header. The inserted packet may be delivered immediately to the network layer if the stream was negotiated to not require frame CRC protection. Bormann [Page 17] INTERNET-DProviding integrated services over low-bitrate links June 1996 A.5.4. Reducing RTE header overhead An option can be negotiated that instructs the receiver to prepend a certain byte string to each packet of a particular stream. This can e.g. be used to encode the PPP protocol identifier. A.5.5. Resulting frame format 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | R | I | sequence | stream | +---+---+---+---+---+---+---+---+ : length L (if I) | stream: +.......................+.......+ : : : Inserted packet : : (length L) : : : +---+---+---+---+---+---+---+---+ | data | : : +...............................+ : SUSPEND/TERMINATE : +---+---+---+---+---+---+---+---+ | Frame | | CRC | +---+---+---+---+---+---+---+---+ A.5.6. Information to be negotiated For each of the seven streams, the following information may be negotiated: 1) Implicitly prepended header bytes. 2) Immediate delivery before frame end. For the whole link, SRTE needs to be negotiated before SRTE frames can be sent. The use of frames starting with 0xFF indicates that the peer has switched back to LCP. Bormann [Page 18] INTERNET-DProviding integrated services over low-bitrate links June 1996 A.6. Other approaches: The PPP multilink approach One way to achieve fragmentation with the PPP suite of standards as defined today is the PPP multilink protocol [5]. The multilink protocol provides for sequence numbering and begin/end bits, allowing big packets to be split into fragments. While the serial sequence numbering does not allow suspension of a fragment being sent, it is possible to send intervening packets that are not encapsulated in multilink headers. This is not the ideal solution for a number of reasons. First, because of the single monotonically increasing serial number, there is only one level of suspension: ``Big'' packets that are sent via multilink can be suspended by ``small'' packets sent outside of multilink; the latter are not suspendable. Second, the begin/end bits are in the multilink header. To make a big packet suspendable, it must be sent with the ``end'' bit off, and (unless the packet was suspended a small number of bytes before its end) an empty fragment has to be sent afterwards to ``close'' the packet. The minimum overhead for sending a big packet thus is twice the multilink header size (six bytes, including a compressed multilink protocol field) plus one PPP framing (three bytes). Each suspension costs another six bytes (not counting the overhead of the framing for the intervening packet). On the other hand, the multilink approach can be built using existing standards; multilink capability is now widely deployed and only the sending side needs to be aware that they are using this for giving priority to real-time packets. Bormann [Page 19] INTERNET-DProviding integrated services over low-bitrate links June 1996 B. Interactions between real-time encapsulation and higher layers It is not possible to just plug in real-time encapsulation into any working PPP system. Real-time encapsulation and the ability to preempt frames causes the link to no longer be strictly sequence- preserving. Appropriate precautions are required for those higher- layer protocols that require sequence-preserving semantics. B.1. Link layer compression protocols that assume sequence-preserving semantics Most header and data compression protocols assume sequence-preserving transmission of their frames by the PPP encapsulation. This includes RFC1144 TCP/IP header compression. One solution is to simply send all frames that are subject to a specific kind of compression within one priority group. For RFC1144, this implies using the same priority for all TCP traffic. Another solution is to set up one instance of the compression mechanism per priority group. This, obviously, requires cooperation from the receiving end (it also has to set up multiple instances and has to map priority groups to those instances). It also generally requires related information to remain in one priority group; e.g., for RFC1144, it will not be possible to prioritize ACKs over data. A third way of handling the problem is similar to the first way, but keeps track of the number of frames in transit. It is then possible to increase the priority as soon as no frames from a lower priority are in transit any longer. The priority can be decreased at any time. B.2. Multilink RFC 1717 multilink requires sequence-preserving semantics. Similar considerations apply as with compression protocols. An additional way to handle the issue is available as RFC 1717 allows packets to be sent outside the multilink; the multilink itself could be kept at one priority level. B.3. Network layer protocols that assume sequence-preserving semantics For network layer protocols that assume sequence-preserving semantics, such as the PPP bridging protocols, similar considerations apply as with compression protocols. Note that the term ``related information'' needs to be defined carefully. Generally, the PPP protocol id will suffice to group packets this way, but multiple protocol ids may need to be in one group (generally, this is true for the network control protocols and the corresponding data transfer protocol ids). Bormann [Page 20] INTERNET-DProviding integrated services over low-bitrate links June 1996 C. Strawman for a combined RTP and UDP/IP/PPP header compression A header compression mechanism for ISSLOW should make use of mechanisms available in RTE wherever significant performance increases can be gained. Generally, one would expect all IP packets to be compressed using IPv6 header compression [2]. Several levels of additional compression are conceivable for RTP data. At the UDP/IP level, there is rarely a requirement to transmit the IPv4 identification field (saving two bytes). For many applications, it will also not be necessary to transmit the UDP checksum; this optimization obviously needs to be selected by the application or by manual configuration. For regular constant-size audio data (e.g., G.723.1), it may be acceptable to entirely compress away all headers for most packets; only the RTP payload data for these packets would then be transmitted in a type 1 block. Data from any packets that start a new talkspurt, as well as any packets that occur after a packet loss, would be preceded by a special block that provides a new value for timestamp and sequence number. The decompressor can reconstruct the RTP information by, for each block, incrementing the sequence number by one and incrementing the timestamp by a negotiated frame period. This requires the compressor to resequence the packets in case of misordering. If detection of losses on the link is desired or if the compressor should not resequence the data, a single-byte modulo of the sequence number can be retained[5]. For video data (e.g., H.263), the RTP marker bit is used to indicate end of frame; the next frame carries a different timestamp value. Since packets for video generally are variable-size, there is little problem in preceding them with a variable-length header that provides a short modulo of the sequence number, an end-of-frame bit, and a new-timestamp bit that, if on, is followed by a new timestamp value. Payload types, synchronization source, contributing sources etc., as well as IP/UDP level information can be negotiated in the compression table and/or sent as special blocks whenever their values change (and at a regular repetition rate [2]). For larger multipoint conferences, it may be worthwhile to include a number of IP source addresses and RTP source identifiers in the compression table and include an index into this table in the compressed RTP block. An equivalent effect can be achieved, at the _________________________ [5] Note that this would be similar in effect to the sequence number option available for audio (``AL2'') data in H.223, except that it would be end-to-end. Bormann [Page 21] INTERNET-DProviding integrated services over low-bitrate links June 1996 cost of a larger frame-composition table, by using multiple compression table indices. [As an internet-draft on IP/UDP/RTP compression is forthcoming, no additional work has been done on this section.] Bormann [Page 22] INTERNET-DProviding integrated services over low-bitrate links June 1996 D. Strawman for an RSVP application announcement format The main purpose of the RSVP application announcement object is to give consenting peer data link layers license to apply compression methods that would be catastrophic for data other than RTP. In addition, any options that influence end-to-end performance aspects (e.g., using reordering at compressors to save a sequence number byte) should be controlled by the RSVP application announcement. For certain scenarios, in particular during initial deployment, it may be useful to be able to configure peer data link layer implementations to apply certain heuristics to derive information that otherwise would be provided in RSVP application announcements. This generally should only be done near the user that might suffer if these heuristics are chosen incorrectly, e.g. on the data link that connects a user's PC to the Internet, giving the user the chance to reconfigure the stack in case of trouble. One possible way to represent information about the session to be compressed beyond that available in RSVP filter specs is provided by the SDP syntax. Bormann [Page 23]