idnits 2.17.1 draft-ietf-issll-isslow-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1997) is 9903 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '5' is defined on line 531, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-mmusic-confarch-00 -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-08) exists of draft-degermark-ipv6-hc-02 -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-15) exists of draft-ietf-rsvp-spec-14 ** Obsolete normative reference: RFC 1717 (ref. '5') (Obsoleted by RFC 1990) ** Obsolete normative reference: RFC 1889 (ref. '6') (Obsoleted by RFC 3550) == Outdated reference: A later version (-05) exists of draft-ietf-avt-crtp-01 == Outdated reference: A later version (-06) exists of draft-ietf-issll-isslow-mcml-01 == Outdated reference: A later version (-05) exists of draft-ietf-issll-isslow-rtf-00 Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Carsten Bormann 3 Expires: September 1997 Universitaet Bremen 4 March 1997 6 Providing integrated services over low-bitrate links 7 draft-ietf-issll-isslow-01.txt 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. 29 Abstract 31 This document describes an architecture for providing integrated 32 services over low-bitrate links, such as modem lines, ISDN B- 33 channels, and sub-T1 links. It covers only the lower parts of the 34 Internet Multimedia Conferencing Architecture [1]; additional 35 components required for application services such as Internet 36 Telephony (e.g., a session initiation protocol) are outside the scope 37 of this document. The main components of the architecture are: a 38 real-time encapsulation format for asynchronous and synchronous low- 39 bitrate links, a header compression architecture optimized for real- 40 time flows, elements of negotiation protocols used between routers 41 (or between hosts and routers), and announcement protocols used by 42 applications to allow this negotiation to take place. 44 This document is a product of the IETF ISSLL working group. 45 Comments are solicited and should be addressed to the working group's 46 mailing list at issll@mercury.lcs.mit.edu and/or the author. 48 1. Introduction 50 As an extension to the ``best-effort'' services the Internet is well- 51 known for, additional types of services (``integrated services'') 52 that support the transport of real-time multimedia information are 53 being developed for and deployed in the Internet. Important elements 54 of this development are: 56 - parameters for forwarding mechanisms that are appropriate for 57 real-time information (in the intserv working group of the IETF) 59 - a setup protocol that allows establishing special forwarding 60 treatment for real-time information flows (RSVP [4], in the rsvp 61 working group of the IETF) 63 - a transport protocol for real-time information (RTP/RTCP [6], in 64 the avt working group of the IETF). 66 In addition to these elements at the network and transport levels of 67 the Internet Multimedia Conferencing Architecture [1], further 68 components are required to define application services such as 69 Internet Telephony, e.g., protocols for session initiation and 70 control. These components are outside the scope of this document. 72 Up to now, the newly developed services could not (or only very 73 inefficiently) be used over forwarding paths that include low-bitrate 74 links such as 14.4 and 28.8 kbit/s modems, 56 and 64 kbit/s ISDN B- 75 channels, or even sub-T1 links. The encapsulation formats used on 76 these links are not appropriate for the simultaneous transport of 77 arbitrary data and real-time information that has to meet stringent 78 delay requirements. A 1500 byte packet on a 28.8 kbit/s modem link 79 makes this link unavailable for the transmission of real-time 80 information for about 400 ms. This adds a worst-case delay that 81 causes real-time applications to operate with round-trip delays on 82 the order of at least a second -- unacceptable for real-time 83 conversation. In addition, the header overhead associated with the 84 protocol stacks used is prohibitive on low-bitrate links, where 85 compression down to a few dozen bytes per real-time information 86 packet is often desirable. E.g., the overhead of at least 44 87 (4+20+8+12) bytes for HDLC/PPP, IP, UDP, and RTP completely 88 overshadows the 19.75 bytes needed for a G.723.1 ACELP audio frame -- 89 a 14.4 kbit/s link is completely consumed by this header overhead 90 alone at 40 real-time frames per second (i.e., at 25 ms packetization 91 delay for one stream or 50 ms for two streams, with no space left for 92 data, yet). While the header overhead can be reduced by combining 93 several real-time information frames into one packet, this increases 94 the delay incurred while filling that packet and further detracts 95 from the goal of real-time transfer of multi-media information over 96 the Internet. 98 This document describes an approach for addressing these problems. 99 The main components of the architecture are: 101 - a real-time encapsulation format for asynchronous and 102 synchronous low-bitrate links, 104 - a header compression architecture optimized for real-time flows, 106 - elements of negotiation protocols used between routers (or 107 between hosts and routers), and 109 - announcement protocols used by applications to allow this 110 negotiation to take place. 112 2. Design Considerations 114 The main design goal for an architecture that addresses real-time 115 multimedia flows over low-bitrate links is that of minimizing the 116 end-to-end delay. More specifically, the worst case delay (after 117 removing possible outliers, which are equivalent to packet losses 118 from an application point of view) is what determines the playout 119 points selected by the applications and thus the delay actually 120 perceived by the user. 122 In addition, any such architecture should obviously undertake every 123 attempt to maximize the bandwidth actually available to media data; 124 overheads must be minimized. 126 An important component of the integrated services architecture is the 127 provision of reservations for real-time flows. One of the problems 128 that systems on low-bitrate links (routers or hosts) face when 129 performing admission control for such reservations is that they must 130 translate the bandwidth requested in the reservation to the one 131 actually consumed on the link. Methods such as data compression 132 and/or header compression can reduce the requirements on the link, 133 but admission control can only make use of the reduced requirements 134 in its calculations if it has enough information about the data 135 stream to know how effective the compression will be. One goal of 136 the architecture therefore is to provide the integrated services 137 admission control with this information. A beneficial side effect 138 may be to allow the systems to perform better compression than would 139 be possible without this information. This may make it worthwhile to 140 provide this information even when it is not intended to make a 141 reservation for a real-time flow. 143 3. The Need for a Concerted Approach 145 Many technical approaches come to mind for addressing these problems, 146 in particular a new form of low-delay encapsulation to address delay 147 and header compression methods to address overhead. This section 148 shows that any single one of these techniques is not sufficient to 149 solve the problem. 151 3.1. Real-Time Encapsulation 153 The purpose of defining a real-time link-layer encapsulation protocol 154 is to be able to introduce newly arrived real-time packets in the 155 link-layer data stream without having to wait for the currently 156 transmitted (possibly large) packet to end. Obviously, a real-time 157 encapsulation must be part of any complete solution as the problem of 158 delays induced by large frames on the link can only be solved on this 159 layer. 161 To be able to switch to a real-time packet quickly in an interface 162 driver, it is first necessary to identify packets that belong to 163 real-time flows. This can be done using a heuristic approach (e.g., 164 favor the transmission of highly periodic flows of small packets 165 transported in IP/UDP). Preferably, one also could make use of the 166 protocol defined for identifying flows that require special 167 treatment, i.e. RSVP. Of the two service types defined for use with 168 RSVP now, the guaranteed service will only be available in certain 169 environments; for this and various other reasons, the service type 170 chosen for many adaptive audio/video applications will be the 171 controlled-load service. Controlled-load does not provide control 172 parameters for target delay; this makes it very hard to identify 173 those packet streams that would benefit most from being transported 174 in a real-time encapsulation format. This calls for a way to provide 175 additional parameters in integrated services flow setup protocols to 176 control the real-time encapsulation. 178 Real-time encapsulation is not sufficient on its own, however: Even 179 if the relevant flows can be appropriately identified for real-time 180 treatment, most applications simply are not possible on low-bitrate 181 links with the header overhead implied by the combination of 182 HDLC/PPP, IP, UDP, and RTP, i.e. they absolutely require header 183 compression. 185 3.2. Header Compression 187 Header compression can be performed in a variety of elements and at a 188 variety of levels in the protocol architecture. As internet 189 telephony vendors ship applications, the approach that is most 190 obvious to them is to reduce overhead by performing header 191 compression at the application level, i.e. above transport protocols 192 such as UDP[1]. 194 Generally, header compression operates by installing state at both 195 ends of a path that allows the receiving end to reconstruct 196 information omitted at the sending end. Many good techniques for 197 header compression (RFC 1144, [2]) operate on the assumption that the 198 path will not reorder the frames generated. This assumption does not 199 _________________________ 200 [1] or actually by using a non-standard, efficiently coded head- 201 er in the first place. 203 hold for end-to-end compression; therefore additional overhead is 204 required for resequencing state changes and compressed packets making 205 use of these state changes. 207 Assume that a very good application level header compression solution 208 for RTP flows could be able to save 11 out of the 12 bytes of an RTP 209 header [3]. Even this perfect solution only reduces the total header 210 overhead by 1/4. It would have to be deployed in all applications, 211 even those that operate on systems that are attached to higher- 212 bitrate links. 214 Because of this limited effectiveness, the AVT group that is 215 responsible for RTP within the IETF has decided to not further pursue 216 application level header compression. 218 For router and IP stack vendors, the obvious approach is to define 219 header compression that can be negotiated between peer routers. 221 Advanced header compression techniques now being defined in the IETF 222 [2] certainly can relieve the link from significant parts of the 223 IP/UDP overhead (i.e., of 28 of the 44 bytes mentioned above). 225 One of the design principles of the header compression contemplated 226 for IPv6 is that it stops at layers the semantics of which cannot be 227 inferred from information in lower layer (outer) headers. Therefore, 228 the original IPv6 header compression cannot compress the data that is 229 contained within UDP packets. 231 Any additional header compression technique runs into a problem: If 232 it assumes specific application semantics (i.e., those of RTP and a 233 payload data format) based on heuristics, it runs the risk of being 234 triggered falsely and (e.g. in case of packet loss) reconstructing 235 packets that are catastrophically incorrect for the application 236 actually being used. A header compression technique that can be 237 operated based on heuristics but does not cause incorrect 238 decompression even if the heuristics failed is described in [7]. 240 With all of these techniques, the total IP/UDP/RTP header overhead 241 for an audio stream can be reduced to two bytes per packet. This 242 technology need only be deployed at bottleneck links; high-speed 243 links can transfer the real-time streams without routers or switches 244 expending CPU cycles to perform header compression. 246 4. Principles of Real-Time Encapsulation for Low-Bitrate Links 248 The main design goal for a real-time encapsulation is to minimize the 249 delay incurred by real-time packets that become available for sending 250 while a long data packet is being sent. To achieve this, the 251 encapsulation must be able to either abort or suspend the transfer of 252 the long data packet. An additional goal is to minimize the overhead 253 required for the transmission of packets from periodic flows. This 254 strongly argues for being able to suspend a packet, i.e. segment it 255 into parts between which the real-time packets can be transferred. 257 Cell-oriented multiplexing techniques such as ATM that introduce 258 regular points where cells from a different packet can be 259 interpolated are too inefficient for low-bitrate links; also, they 260 are not supported by chips used to support the link layer in low- 261 bitrate routers and host interfaces. 263 Instead, the real-time encapsulation should as far as possible make 264 use of the capabilities of the chips that have been deployed. On 265 synchronous lines, these chips support HDLC framing; on asynchronous 266 lines, an asynchronous variant of HDLC that usually is implemented in 267 software is being used. Both variants of HDLC provide a delimiting 268 mechanism to indicate the end of a frame over the link. The obvious 269 solution to the segmentation problem is to combine this mechanism 270 with an indication of whether the delimiter terminates or suspends 271 the current packet. 273 This indication could be in an octet appended to each frame 274 information field; however, seven out of eight bits of the octet 275 would be wasted. Instead, the bit could be carried at the start of 276 the next frame in conjunction with multiplexing information (PPP 277 protocol identifier etc.) that will be required here anyway. Since 278 the real-time flows will in general be periodic, this multiplexing 279 information could convey (part of) the compressed form of the header 280 for the packet. If packets from the real-time flow generally are of 281 constant length (or have a defined maximum length that is often 282 used), the continuation of the suspended packet could be immediately 283 attached to it, without expending a further frame delimiter, i.e., 284 the interpolation of the real-time packet would then have zero 285 overhead. Since packets from low-delay real-time flows generally 286 will not require the ability to be further suspended, the 287 continuation bit could be reserved for the non-real-time packet 288 stream. 290 One real-time encapsulation format with these (and other) functions 291 is described in ITU-T H.223, the multiplex used by the H.324 292 videophone standard. It was investigated whether compatibility could 293 be achieved with this specification, which will be used in future 294 videophone-enabled (H.324 capable) modems. However, since the 295 multiplexing capabilities of H.223 are limited to 15 schedules 296 (definitions of sequences of packet types that can be identified in a 297 multiplex header), for general Internet usage a superset or a more 298 general encapsulation would have been required. Also, a PPP-style 299 negotiation protocol was needed instead of using (and necessarily 300 extending) ITU-T H.245 for setting the parameters of the multiplex. 301 In the PPP context, the interactions with the encapsulations for data 302 compression and link layer encryption needed to be defined (including 303 operation in the presence of padding). But most important, H.223 304 requires synchronous HDLC chips that can be configured to send frames 305 without an attached CRC, which is not possible with all chips 306 deployed in commercially available routers; so complete compatibility 307 was unachievable. 309 Instead of adopting H.223, it was decided to pursue an approach that 310 is oriented towards compatibility both with existing hardware and 311 existing software (in particular PPP) implementations. The next 312 subsection groups these implementations according to their 313 capabilities. 315 4.1. Implementation models 317 This section introduces a number of terms for types of 318 implementations that are likely to emerge. It is important to have 319 these different implementation models in mind as there is no single 320 approach that fits all models best. 322 4.1.1. Sender types 324 There are two fundamental approaches to real-time transmission on 325 low-bitrate links: 327 Sender type 1 328 The PPP real-time framing implementation is able to control the 329 transmission of each byte being transmitted with some known, 330 bounded delay (e.g., due to FIFOs). For example, this is 331 generally true of PC host implementations, which directly access 332 serial interface chips byte by byte or by filling a very small 333 FIFO. For type 1 senders, a suspend/resume type approach will 334 be typically used: When a long frame is to be sent, the attempt 335 is to send it undivided; only if higher priority packets come up 336 during the transmission will the lower-priority long frame be 337 suspended and later resumed. This approach allows the minimum 338 variation in access delay for high-priority packets; also, 339 fragmentation overhead is only incurred when actually needed. 341 Sender type 2 342 With type 2 senders, the interface between the PPP real-time 343 framing implementation and the transmission hardware is not in 344 terms of streams of bytes, but in terms of frames, e.g., in the 345 form of multiple (prioritized) send queues directly supported by 346 hardware. This is often true of router systems for synchronous 347 links, in particular those that have to support a large number 348 of low-bitrate links. As type 2 senders have no way to suspend 349 a frame once it has been handed down for transmission, they 350 typically will use a queues-of-fragments approach, where long 351 packets are always split into units that are small enough to 352 maintain the access delay goals for higher-priority traffic. 353 There is a trade-off between the variation in access delay 354 resulting from a large fragment size and the overhead that is 355 incurred for every long packet by choosing a small fragment 356 size. 358 4.1.2. Receiver types 360 Although the actual work of formulating transmission streams for 361 real-time applications is performed at the sender, the ability of the 362 receiver to immediately make use of the information received depends 363 on its characteristics: 365 Receiver type 1 366 Type 1 receivers have full control over the stream of bytes 367 received within PPP frames, i.e., bytes received are available 368 immediately to the PPP real-time framing implementation (with 369 some known, bounded delay e.g. due to FIFOs etc.). 371 Receiver type 2 372 With type 2 receivers, the PPP real-time framing implementation 373 only gets hold of a frame when it has been received completely, 374 i.e., the final flag has been processed (typically by some HDLC 375 chip that directly fills a memory buffer). 377 4.2. Conclusion 379 As a result of the diversity in capabilities of current 380 implementations, there are now two specifications for real-time 381 encapsulation: One, the multi-class extension to the PPP multi-link 382 protocol, is providing the solution for the queues-of-fragments 383 approach by extending the single-stream PPP multi-link protocol by 384 multiple classes [8]. The other encapsulation, PPP in a real-time 385 oriented HDLC-like framing, builds on this specification end extends 386 it by a way to dynamically delimit multiple fragments within one HDLC 387 frame [9], providing the solution for the suspend/resume type 388 approach. 390 5. Principles of Header Compression for Real-Time Flows 392 A good baseline for a discussion about header compression is in the 393 IPv6 header compression draft [2]. The techniques used there can 394 reduce the 28 bytes of IPv4/UDP header to about 6 bytes (depending on 395 the number of concurrent streams); with the remaining 4 bytes of 396 HDLC/PPP overhead and 12 bytes for RTP the total header overhead can 397 be about halved but still exceeds the size of a G.723.1 ACELP frame. 398 Note that, in contrast to IPv6 header compression, the environment 399 discussed here assumes the existence of a full-duplex PPP link and 400 thus can rely on negotiation where IPv6 header compression requires 401 repeated transmission of the same information. (The use of the 402 architecture of the present document with link layer multicasting has 403 not yet been examined.) 405 Additional design effort was required for RTP header compression. 406 Applying the concepts of IPv6 header compression, of the (at least) 407 12 bytes in an RTP header, 7 bytes (timestamp, sequence, and marker 408 bit) would qualify as RANDOM; DELTA encoding cannot generally be used 409 without further information since the lower layer header does not 410 unambiguously identify the semantics and there is no TCP checksum 411 that can be relied on to detect incorrect decompression. Only a more 412 semantics-oriented approach can provide better compression (just as 413 RFC 1144 can provide very good compression of TCP headers by making 414 use of semantic knowledge of TCP and its checksumming method). 416 For RTP packets, differential encoding of the sequence number and 417 timestamps is an efficient approach for certain cases of payload data 418 formats. E.g., speech flows generally have sequence numbers and 419 timestamp fields that increase by 1 and by the frame size in 420 timestamp units, resp.; the CRTP (compressed RTP) specification makes 421 use of this relationship by encoding these fields only when the 422 second order difference is non-zero [7]. 424 6. Announcement Protocols Used by Applications 426 As argued, the compressor can operate best if it can make use of 427 information that clearly identifies real-time streams and provides 428 information about the payload data format in use. 430 If these systems are routers, this consent must be installed as 431 router state; if these systems are hosts, it must be known to their 432 networking kernels. Sources of real-time information flows are 433 already describing characteristics of these flows to their kernels 434 and to the routers in the form of TSpecs in RSVP PATH messages [4]. 435 Since these messages make use of the router alert option, they are 436 seen by all routers on the path; path state about the packet stream 437 is normally installed at each of these routers that implement RSVP. 438 Additional RSVP objects could be defined that are included in PATH 439 messages by those applications that desire good performance over low- 440 bitrate links; these objects would be coded to be ignored by routers 441 that are not interested in them (class number 11bbbbbb). 443 Note that the path state is available in the routers even when no 444 reservation is made; this allows informed compression of best-effort 445 traffic. It is not quite clear, though, how path state could be 446 teared down quickly when a source ceases to transmit. 448 7. Elements of Hop-By-Hop Negotiation Protocols 450 The IPv6 header compression draft attempts to account for simplex and 451 multicast links by providing information about the compressed streams 452 only in the forward direction. E.g., a full IP/UDP header must be 453 sent after F_MAX_TIME (currently 3 seconds), which is a negligible 454 total overhead (e.g. one full header every 150 G.723.1 packets), but 455 must be considered carefully in scheduling the real-time 456 transmissions. Both simplex and multicast links are not prevailing 457 in the low-bitrate environment (although multicast functionality may 458 become more important with wireless systems); in this document, we 459 therefore assume full-duplex capability. 461 As compression techniques will improve, a negotiation between the two 462 peers on the link would provide the best flexibility in 463 implementation complexity and potential for extensibility. The peer 464 routers/hosts can decide which real-time packet streams are to be 465 compressed, which header fields are not to be sent at all, which 466 multiplexing information should be used on the link, and how the 467 remaining header fields should be encoded. PPP, a well-tried suite 468 of negotiation protocols, is already used on most of the low-bitrate 469 links and seems to provide the obvious approach. Cooperation from 470 PPP is also needed to negotiate the use of real-time encapsulations 471 between systems that are not configured to automatically do so. 472 Therefore, PPP options that can be negotiated at the link setup (LCP) 473 phase are included in [8], and [9] (and need to be put into [7], FIX 474 ME). 476 8. Security Considerations 478 Header compression protocols that make use of assumptions about 479 application protocols need to be carefully analyzed whether it is 480 possible to subvert other applications by maliciously or 481 inadvertently enabling their use. 483 It is generally not possible to do significant hop-by-hop header 484 compression on encrypted streams. With certain security policies, it 485 may be possible to run an encrypted tunnel to a network access server 486 that does header compression on the decapsulated packets and sends 487 them over an encrypted link encapsulation; see also the short mention 488 of interactions between real-time encapsulation and encryption in 489 section 4 above. If the security requirements permit, a special RTP 490 payload data format that encrypts only the data may preferably be 491 used. 493 9. Author's Address 495 Carsten Bormann 496 Universitaet Bremen FB3 TZI 497 Postfach 330440 498 D-28334 Bremen, GERMANY 499 cabo@tzi.uni-bremen.de 500 phone +49.421.218-7024 501 fax +49.421.218-7000 503 Acknowledgements 505 Much of the early discussion that led to this document was done with 506 Scott Petrack of IBM Israel and Cary Fitzgerald of Cisco Systems. 508 Steve Casner, Mikael Degermark, Steve Jackowski, Dave Oran, and the 509 other members of the ISSLL subgroup on low bitrate links (ISSLOW) 510 have helped making this architecture a reality. 512 10. References 514 [1] Mark Handley, Jon Crowcroft, Carsten Bormann, ``The Internet 515 Multimedia Conferencing Architecture,'' Internet-Draft draft- 516 ietf-mmusic-confarch-00.txt, Work in Progress, February 1996. 518 [2] M. Degermark, B. Nordgren, S. Pink, ``Header Compression for 519 IPv6,'' Internet-Draft draft-degermark-ipv6-hc-02.txt, Work in 520 Progress, November 1996. 522 [3] Scott Petrack, Ed Ellesson, ``Framework for C/RTP: Compressed 523 RTP Using Adaptive Differential Header Compression'', 524 contribution to the mailing list rem-conf@es.net, February 1996. 526 [4] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, 527 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 528 Specification, Internet-Draft draft-ietf-rsvp-spec-14.txt, Work 529 in Progress, November 1996. 531 [5] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, ``The 532 PPP Multilink Protocol (MP)'', RFC 1990, August 1996 (obsoletes 533 RFC1717). 535 [6] H. Schulzrinne, S. Casner, R. Frederick & V. Jacobson, ``RTP: A 536 Transport Protocol for Real-Time Applications'', RFC 1889, 537 January 1996. 539 [7] S. Casner, V. Jacobson, ``Compressing IP/UDP/RTP Headers for 540 Low-Speed Serial Links'', Internet-Draft draft-ietf-avt- 541 crtp-01.txt, Work in Progress, November 1996. 543 [8] C. Bormann, ``The Multi-Class Extension to Multi-Link PPP'', 544 internet Draft draft-ietf-issll-isslow-mcml-01.txt, Work in 545 Progress, March 1997. 547 [9] C. Bormann, ``PPP in a real-time oriented HDLC-like framing, 548 internet Draft draft-ietf-issll-isslow-rtf-00.txt, Work in 549 Progress, March 1997.