From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2689.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc2689.txt (limited to 'doc/rfc/rfc2689.txt') 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] + -- cgit v1.2.3