idnits 2.17.00 (12 Aug 2021) /tmp/idnits32172/draft-ietf-issll-isslow-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages 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 (June 1999) is 8369 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 541, 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' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 1717 (ref. '5') (Obsoleted by RFC 1990) ** Obsolete normative reference: RFC 1889 (ref. '6') (Obsoleted by RFC 3550) == Outdated reference: draft-ietf-issll-isslow-mcml has been published as RFC 2686 == Outdated reference: draft-ietf-issll-isslow-rtf has been published as RFC 2687 ** Obsolete normative reference: RFC 2509 (ref. '10') (Obsoleted by RFC 3544) -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Carsten Bormann 2 Expires: December 1999 Universitaet Bremen TZI 3 June 1999 5 Providing integrated services over low-bitrate links 6 draft-ietf-issll-isslow-06.txt 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 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 1. Introduction 46 As an extension to the ``best-effort'' services the Internet is well- 47 known for, additional types of services (``integrated services'') 48 that support the transport of real-time multimedia information are 49 being developed for, and deployed in the Internet. Important 50 elements of this development are: 52 - parameters for forwarding mechanisms that are appropriate for 53 real-time information [11, 12], 55 - a setup protocol that allows establishing special forwarding 56 treatment for real-time information flows (RSVP [4]), 58 - a transport protocol for real-time information (RTP/RTCP [6]). 60 In addition to these elements at the network and transport levels of 61 the Internet Multimedia Conferencing Architecture [1], further 62 components are required to define application services such as 63 Internet Telephony, e.g., protocols for session initiation and 64 control. These components are outside the scope of this document. 66 Up to now, the newly developed services could not (or only very 67 inefficiently) be used over forwarding paths that include low-bitrate 68 links such as 14.4, 33.6, and 56 kbit/s modems, 56 and 64 kbit/s ISDN 69 B-channels, or even sub-T1 links. The encapsulation formats used on 70 these links are not appropriate for the simultaneous transport of 71 arbitrary data and real-time information that has to meet stringent 72 delay requirements. Transmission of a 1500 byte packet on a 28.8 73 kbit/s modem link makes this link unavailable for the transmission of 74 real-time information for about 400 ms. This adds a worst-case delay 75 that causes real-time applications to operate with round-trip delays 76 on the order of at least a second -- unacceptable for real-time 77 conversation. In addition, the header overhead associated with the 78 protocol stacks used is prohibitive on low-bitrate links, where 79 compression down to a few dozen bytes per real-time information 80 packet is often desirable. E.g., the overhead of at least 44 81 (4+20+8+12) bytes for HDLC/PPP, IP, UDP, and RTP completely 82 overshadows typical audio payloads such as the 19.75 bytes needed for 83 a G.723.1 ACELP audio frame -- a 14.4 kbit/s link is completely 84 consumed by this header overhead alone at 40 real-time frames per 85 second total (i.e., at 25 ms packetization delay for one stream or 50 86 ms for two streams, with no space left for data, yet). While the 87 header overhead can be reduced by combining several real-time 88 information frames into one packet, this increases the delay incurred 89 while filling that packet and further detracts from the goal of real- 90 time transfer of multi-media information over the Internet. 92 This document describes an approach for addressing these problems. 93 The main components of the architecture are: 95 - a real-time encapsulation format for asynchronous and 96 synchronous low-bitrate links, 98 - a header compression architecture optimized for real-time flows, 100 - elements of negotiation protocols used between routers (or 101 between hosts and routers), and 103 - announcement protocols used by applications to allow this 104 negotiation to take place. 106 2. Design Considerations 108 The main design goal for an architecture that addresses real-time 109 multimedia flows over low-bitrate links is that of minimizing the 110 end-to-end delay. More specifically, the worst case delay (after 111 removing possible outliers, which are equivalent to packet losses 112 from an application point of view) is what determines the playout 113 points selected by the applications and thus the delay actually 114 perceived by the user. 116 In addition, any such architecture should obviously undertake every 117 attempt to maximize the bandwidth actually available to media data; 118 overheads must be minimized. 120 An important component of the integrated services architecture is the 121 provision of reservations for real-time flows. One of the problems 122 that systems on low-bitrate links (routers or hosts) face when 123 performing admission control for such reservations is that they must 124 translate the bandwidth requested in the reservation to the one 125 actually consumed on the link. Methods such as data compression 126 and/or header compression can reduce the requirements on the link, 127 but admission control can only make use of the reduced requirements 128 in its calculations if it has enough information about the data 129 stream to know how effective the compression will be. One goal of 130 the architecture therefore is to provide the integrated services 131 admission control with this information. A beneficial side effect 132 may be to allow the systems to perform better compression than would 133 be possible without this information. This may make it worthwhile to 134 provide this information even when it is not intended to make a 135 reservation for a real-time flow. 137 3. The Need for a Concerted Approach 139 Many technical approaches come to mind for addressing these problems, 140 in particular a new form of low-delay encapsulation to address delay 141 and header compression methods to address overhead. This section 142 shows that these techniques should be combined to solve the problem. 144 3.1. Real-Time Encapsulation 146 The purpose of defining a real-time link-layer encapsulation protocol 147 is to be able to introduce newly arrived real-time packets into the 148 link-layer data stream without having to wait for the currently 149 transmitted (possibly large) packet to end. Obviously, a real-time 150 encapsulation must be part of any complete solution as the problem of 151 delays induced by large frames on the link can only be solved on this 152 layer. 154 To be able to switch to a real-time packet quickly in an interface 155 driver, it is first necessary to identify packets that belong to 156 real-time flows. This can be done using a heuristic approach (e.g., 157 favor the transmission of highly periodic flows of small packets 158 transported in IP/UDP, or use the IP precedence fields in a specific 159 way defined within an organization). Preferably, one also could make 160 use of a protocol defined for identifying flows that require special 161 treatment, i.e. RSVP. Of the two service types defined for use with 162 RSVP now, the guaranteed service will only be available in certain 163 environments; for this and various other reasons, the service type 164 chosen for many adaptive audio/video applications will most likely be 165 the controlled-load service. Controlled-load does not provide 166 control parameters for target delay; thus it does not unambiguously 167 identify those packet streams that would benefit most from being 168 transported in a real-time encapsulation format. This calls for a 169 way to provide additional parameters in integrated services flow 170 setup protocols to control the real-time encapsulation. 172 Real-time encapsulation is not sufficient on its own, however: Even 173 if the relevant flows can be appropriately identified for real-time 174 treatment, most applications simply cannot operate properly on low- 175 bitrate links with the header overhead implied by the combination of 176 HDLC/PPP, IP, UDP, and RTP, i.e. they absolutely require header 177 compression. 179 3.2. Header Compression 181 Header compression can be performed in a variety of elements and at a 182 variety of levels in the protocol architecture. As many vendors of 183 Internet Telephony products for PCs ship applications, the approach 184 that is most obvious to them is to reduce overhead by performing 185 header compression at the application level, i.e. above transport 186 protocols such as UDP (or actually by using a non-standard, 187 efficiently coded header in the first place). 189 Generally, header compression operates by installing state at both 190 ends of a path that allows the receiving end to reconstruct 191 information omitted at the sending end. Many good techniques for 192 header compression (RFC 1144, [2]) operate on the assumption that the 193 path will not reorder the frames generated. This assumption does not 194 hold for end-to-end compression; therefore additional overhead is 195 required for resequencing state changes and for compressed packets 196 making use of these state changes. 198 Assume that a very good application level header compression solution 199 for RTP flows could be able to save 11 out of the 12 bytes of an RTP 200 header [3]. Even this perfect solution only reduces the total header 201 overhead by 1/4. It would have to be deployed in all applications, 202 even those that operate on systems that are attached to higher- 203 bitrate links. 205 Because of this limited effectiveness, the AVT group that is 206 responsible for RTP within the IETF has decided to not further pursue 207 application level header compression. 209 For router and IP stack vendors, the obvious approach is to define 210 header compression that can be negotiated between peer routers. 212 Advanced header compression techniques now being defined in the IETF 213 [2] certainly can relieve the link from significant parts of the 214 IP/UDP overhead (i.e., most of 28 of the 44 bytes mentioned above). 216 One of the design principles of the new IP header compression 217 developed in conjunction with IPv6 is that it stops at layers the 218 semantics of which cannot be inferred from information in lower layer 219 (outer) headers. Therefore, this header compression technique alone 220 cannot compress the data that is contained within UDP packets. 222 Any additional header compression technique runs into a problem: If 223 it assumes specific application semantics (i.e., those of RTP and a 224 payload data format) based on heuristics, it runs the risk of being 225 triggered falsely and (e.g. in case of packet loss) reconstructing 226 packets that are catastrophically incorrect for the application 227 actually being used. A header compression technique that can be 228 operated based on heuristics but does not cause incorrect 229 decompression even if the heuristics failed is described in [7]; a 230 companion document describes the mapping of this technique to PPP 231 [10]. 233 With all of these techniques, the total IP/UDP/RTP header overhead 234 for an audio stream can be reduced to two bytes per packet. This 235 technology need only be deployed at bottleneck links; high-speed 236 links can transfer the real-time streams without routers or switches 237 expending CPU cycles to perform header compression. 239 4. Principles of Real-Time Encapsulation for Low-Bitrate Links 241 The main design goal for a real-time encapsulation is to minimize the 242 delay incurred by real-time packets that become available for sending 243 while a long data packet is being sent. To achieve this, the 244 encapsulation must be able to either abort or suspend the transfer of 245 the long data packet. As an additional goal is to minimize the 246 overhead required for the transmission of packets from periodic 247 flows, this strongly argues for being able to suspend a packet, i.e. 248 segment it into parts between which the real-time packets can be 249 transferred. 251 4.1. Using existing IP fragmentation 253 Transmitting only part of a packet, to allow higher-priority traffic 254 to intervene and then resuming its transmission later on, is a kind 255 of fragmentation. Fragmentation is an existing functionality of the 256 IP layer: An IPv4 header already contains fields that allow a large 257 IP datagram to be fragmented into small parts. A sender's ``real- 258 time PPP'' implementation might simply indicate a small MTU to its IP 259 stack and thus cause all larger datagrams to be fragmented down to a 260 size that allows the access delay goals to be met (this assumes that 261 the IP stack is able to priority-tag fragments, or that the PPP 262 implementation is able to correlate the fragments to the initial one 263 that carries the information relevant for prioritizing, or that only 264 initial fragments can be high-priority). (Also, a PPP implementation 265 can negotiate down the MTU of its peer, causing the peer to fragment 266 to a small size, which might be considered a crude form of 267 negotiating an access delay goal with the peer system -- if that 268 system supports priority queueing at the fragment level.) 270 Unfortunately, a full, 20 byte IP header is needed for each fragment 271 (larger when IP options are used). This limits the minimum size of 272 fragments that can be used without too much overhead. (Also, the 273 size of non-final fragments must be a multiple of 8 bytes, further 274 limiting the choice.) With path MTU discovery, IP level 275 fragmentation causes TCP implementations to use small MSSs -- this 276 further increases the per-packet overhead to 40 bytes per fragment. 278 In any case, fragmentation at the IP level persists on the path 279 further down to the datagram receiver, increasing the transmission 280 overheads and router load throughout the network. With its high 281 overhead and the adverse effect on the Internet, IP level 282 fragmentation can only be a stop-gap mechanism when no other 283 fragmentation protocol is available in the peer implementation. 285 4.2. Link-Layer Mechanisms 287 Cell-oriented multiplexing techniques such as ATM that introduce 288 regular points where cells from a different packet can be 289 interpolated are too inefficient for low-bitrate links; also, they 290 are not supported by chips used to support the link layer in low- 291 bitrate routers and host interfaces. 293 Instead, the real-time encapsulation should as far as possible make 294 use of the capabilities of the chips that have been deployed. On 295 synchronous lines, these chips support HDLC framing; on asynchronous 296 lines, an asynchronous variant of HDLC that usually is implemented in 297 software is being used. Both variants of HDLC provide a delimiting 298 mechanism to indicate the end of a frame over the link. The obvious 299 solution to the segmentation problem is to combine this mechanism 300 with an indication of whether the delimiter terminates or suspends 301 the current packet. 303 This indication could be in an octet appended to each frame 304 information field; however, seven out of eight bits of the octet 305 would be wasted. Instead, the bit could be carried at the start of 306 the next frame in conjunction with multiplexing information (PPP 307 protocol identifier etc.) that will be required here anyway. Since 308 the real-time flows will in general be periodic, this multiplexing 309 information could convey (part of) the compressed form of the header 310 for the packet. If packets from the real-time flow generally are of 311 constant length (or have a defined maximum length that is often 312 used), the continuation of the suspended packet could be immediately 313 attached to it, without expending a further frame delimiter, i.e., 314 the interpolation of the real-time packet would then have zero 315 overhead. Since packets from low-delay real-time flows generally 316 will not require the ability to be further suspended, the 317 continuation bit could be reserved for the non-real-time packet 318 stream. 320 One real-time encapsulation format with these (and other) functions 321 is described in ITU-T H.223 [13], the multiplex used by the H.324 322 modem-based videophone standard [14]. It was investigated whether 323 compatibility could be achieved with this specification, which will 324 be used in future videophone-enabled (H.324 capable) modems. 325 However, since the multiplexing capabilities of H.223 are limited to 326 15 schedules (definitions of sequences of packet types that can be 327 identified in a multiplex header), for general Internet usage a 328 superset or a more general encapsulation would have been required. 329 Also, a PPP-style negotiation protocol was needed instead of using 330 (and necessarily extending) ITU-T H.245 [15] for setting the 331 parameters of the multiplex. In the PPP context, the interactions 332 with the encapsulations for data compression and link layer 333 encryption needed to be defined (including operation in the presence 334 of padding). But most important, H.223 requires synchronous HDLC 335 chips that can be configured to send frames without an attached CRC, 336 which is not possible with all chips deployed in commercially 337 available routers; so complete compatibility was unachievable. 339 Instead of adopting H.223, it was decided to pursue an approach that 340 is oriented towards compatibility both with existing hardware and 341 existing software (in particular PPP) implementations. The next 342 subsection groups these implementations according to their 343 capabilities. 345 4.3. Implementation models 347 This section introduces a number of terms for types of 348 implementations that are likely to emerge. It is important to have 349 these different implementation models in mind as there is no single 350 approach that fits all models best. 352 4.3.1. Sender types 354 There are two fundamental approaches to real-time transmission on 355 low-bitrate links: 357 Sender type 1 358 The PPP real-time framing implementation is able to control the 359 transmission of each byte being transmitted with some known, 360 bounded delay (e.g., due to FIFOs). For example, this is 361 generally true of PC host implementations, which directly access 362 serial interface chips byte by byte or by filling a very small 363 FIFO. For type 1 senders, a suspend/resume type approach will 364 be typically used: When a long frame is to be sent, the attempt 365 is to send it undivided; only if higher priority packets come up 366 during the transmission will the lower-priority long frame be 367 suspended and later resumed. This approach allows the minimum 368 variation in access delay for high-priority packets; also, 369 fragmentation overhead is only incurred when actually needed. 371 Sender type 2 372 With type 2 senders, the interface between the PPP real-time 373 framing implementation and the transmission hardware is not in 374 terms of streams of bytes, but in terms of frames, e.g., in the 375 form of multiple (prioritized) send queues directly supported by 376 hardware. This is often true of router systems for synchronous 377 links, in particular those that have to support a large number 378 of low-bitrate links. As type 2 senders have no way to suspend 379 a frame once it has been handed down for transmission, they 380 typically will use a queues-of-fragments approach, where long 381 packets are always split into units that are small enough to 382 maintain the access delay goals for higher-priority traffic. 383 There is a trade-off between the variation in access delay 384 resulting from a large fragment size and the overhead that is 385 incurred for every long packet by choosing a small fragment 386 size. 388 4.3.2. Receiver types 390 Although the actual work of formulating transmission streams for 391 real-time applications is performed at the sender, the ability of the 392 receiver to immediately make use of the information received depends 393 on its characteristics: 395 Receiver type 1 396 Type 1 receivers have full control over the stream of bytes 397 received within PPP frames, i.e., bytes received are available 398 immediately to the PPP real-time framing implementation (with 399 some known, bounded delay e.g. due to FIFOs etc.). 401 Receiver type 2 402 With type 2 receivers, the PPP real-time framing implementation 403 only gets hold of a frame when it has been received completely, 404 i.e., the final flag has been processed (typically by some HDLC 405 chip that directly fills a memory buffer). 407 4.4. Conclusion 409 As a result of the diversity in capabilities of current 410 implementations, there are now two specifications for real-time 411 encapsulation: One, the multi-class extension to the PPP multi-link 412 protocol, is providing the solution for the queues-of-fragments 413 approach by extending the single-stream PPP multi-link protocol by 414 multiple classes [8]. The other encapsulation, PPP in a real-time 415 oriented HDLC-like framing, builds on this specification end extends 416 it by a way to dynamically delimit multiple fragments within one HDLC 417 frame [9], providing the solution for the suspend/resume type 418 approach. 420 5. Principles of Header Compression for Real-Time Flows 422 A good baseline for a discussion about header compression is in the 423 new IP header compression specification that was designed in 424 conjunction with the development of IPv6 [2]. The techniques used 425 there can reduce the 28 bytes of IPv4/UDP header to about 6 bytes 426 (depending on the number of concurrent streams); with the remaining 4 427 bytes of HDLC/PPP overhead and 12 bytes for RTP the total header 428 overhead can be about halved but still exceeds the size of a G.723.1 429 ACELP frame. Note that, in contrast to IP header compression, the 430 environment discussed here assumes the existence of a full-duplex PPP 431 link and thus can rely on negotiation where IP header compression 432 requires repeated transmission of the same information. (The use of 433 the architecture of the present document with link layer multicasting 434 has not yet been examined.) 436 Additional design effort was required for RTP header compression. 437 Applying the concepts of IP header compression, of the (at least) 12 438 bytes in an RTP header, 7 bytes (timestamp, sequence, and marker bit) 439 would qualify as RANDOM; DELTA encoding cannot generally be used 440 without further information since the lower layer header does not 441 unambiguously identify the semantics and there is no TCP checksum 442 that can be relied on to detect incorrect decompression. Only a more 443 semantics-oriented approach can provide better compression (just as 444 RFC 1144 can provide very good compression of TCP headers by making 445 use of semantic knowledge of TCP and its checksumming method). 447 For RTP packets, differential encoding of the sequence number and 448 timestamps is an efficient approach for certain cases of payload data 449 formats. E.g., speech flows generally have sequence numbers and 450 timestamp fields that increase by 1 and by the frame size in 451 timestamp units, resp.; the CRTP (compressed RTP) specification makes 452 use of this relationship by encoding these fields only when the 453 second order difference is non-zero [7]. 455 6. Announcement Protocols Used by Applications 457 As argued, the compressor can operate best if it can make use of 458 information that clearly identifies real-time streams and provides 459 information about the payload data format in use. 461 If these systems are routers, this consent must be installed as 462 router state; if these systems are hosts, it must be known to their 463 networking kernels. Sources of real-time information flows are 464 already describing characteristics of these flows to their kernels 465 and to the routers in the form of TSpecs in RSVP PATH messages [4]. 466 Since these messages make use of the router alert option, they are 467 seen by all routers on the path; path state about the packet stream 468 is normally installed at each of these routers that implement RSVP. 469 Additional RSVP objects could be defined that are included in PATH 470 messages by those applications that desire good performance over low- 471 bitrate links; these objects would be coded to be ignored by routers 472 that are not interested in them (class number 11bbbbbb as defined in 473 [4], section 3.10). 475 Note that the path state is available in the routers even when no 476 reservation is made; this allows informed compression of best-effort 477 traffic. It is not quite clear, though, how path state could be torn 478 down quickly when a source ceases to transmit. 480 7. Elements of Hop-By-Hop Negotiation Protocols 482 The IP header compression specification attempts to account for 483 simplex and multicast links by providing information about the 484 compressed streams only in the forward direction. E.g., a full 485 IP/UDP header must be sent after F_MAX_TIME (currently 3 seconds), 486 which is a negligible total overhead (e.g. one full header every 150 487 G.723.1 packets), but must be considered carefully in scheduling the 488 real-time transmissions. Both simplex and multicast links are not 489 prevailing in the low-bitrate environment (although multicast 490 functionality may become more important with wireless systems); in 491 this document, we therefore assume full-duplex capability. 493 As compression techniques will improve, a negotiation between the two 494 peers on the link would provide the best flexibility in 495 implementation complexity and potential for extensibility. The peer 496 routers/hosts can decide which real-time packet streams are to be 497 compressed, which header fields are not to be sent at all, which 498 multiplexing information should be used on the link, and how the 499 remaining header fields should be encoded. PPP, a well-tried suite 500 of negotiation protocols, is already used on most of the low-bitrate 501 links and seems to provide the obvious approach. Cooperation from 502 PPP is also needed to negotiate the use of real-time encapsulations 503 between systems that are not configured to automatically do so. 504 Therefore, PPP options that can be negotiated at the link setup (LCP) 505 phase are included in [8], [9], and [10]. 507 8. Security Considerations 509 Header compression protocols that make use of assumptions about 510 application protocols need to be carefully analyzed whether it is 511 possible to subvert other applications by maliciously or 512 inadvertently enabling their use. 514 It is generally not possible to do significant hop-by-hop header 515 compression on encrypted streams. With certain security policies, it 516 may be possible to run an encrypted tunnel to a network access server 517 that does header compression on the decapsulated packets and sends 518 them over an encrypted link encapsulation; see also the short mention 519 of interactions between real-time encapsulation and encryption in 520 section 4 above. If the security requirements permit, a special RTP 521 payload data format that encrypts only the data may preferably be 522 used. 524 9. References 526 [1] Mark Handley, Jon Crowcroft, Carsten Bormann, Joerg Ott. ``The 527 Internet Multimedia Conferencing Architecture'', Work in 528 Progress (draft-ietf-mmusic-confarch-00.txt), July 1997. 530 [2] M. Degermark, B. Nordgren, S. Pink, ``IP Header Compression'', 531 RFC 2507, February 1999. 533 [3] Scott Petrack, Ed Ellesson, ``Framework for C/RTP: Compressed 534 RTP Using Adaptive Differential Header Compression'', 535 contribution to the mailing list rem-conf@es.net, February 1996. 537 [4] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, 538 ``Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 539 Specification'', RFC 2205, September 1997. 541 [5] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, ``The 542 PPP Multilink Protocol (MP)'', RFC 1990, August 1996 (obsoletes 543 RFC1717). 545 [6] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, ``RTP: A 546 Transport Protocol for Real-Time Applications'', RFC 1889, 547 January 1996. 549 [7] S. Casner, V. Jacobson, ``Compressing IP/UDP/RTP Headers for 550 Low-Speed Serial Links'', RFC 2508, February 1999. 552 [8] C. Bormann, ``The Multi-Class Extension to Multi-Link PPP'', 553 Work in Progress (draft-ietf-issll-isslow-mcml-06.txt), August 554 1998. 556 [9] C. Bormann, ``PPP in a real-time oriented HDLC-like framing'', 557 Work in Progress (draft-ietf-issll-isslow-rtf-05.txt), August 558 1998. 560 [10] M. Engan, S. Casner, C. Bormann, ``IP Header Compression over 561 PPP'', RFC 2509, February 1999. 563 [11] J. Wroclawski. ``Specification of the Controlled-Load Network 564 Element Service'', RFC 2211, September 1997. 566 [12] S. Shenker, C. Partridge, R. Guerin. ``Specification of 567 Guaranteed Quality of Service'', RFC 2212, September 1997. 569 [13] ITU-T Recommendation H.223, ``Multiplexing protocol for low bit 570 rate multimedia communication'', International Telecommunication 571 Union, Telecommunication Standardization Sector (ITU-T), March 572 1996. 574 [14] ITU-T Recommendation H.324, ``Terminal for low bit rate 575 multimedia communication'', International Telecommunication 576 Union, Telecommunication Standardization Sector (ITU-T), March 577 1996. 579 [15] ITU-T Recommendation H.245, ``Control protocol for multimedia 580 communication'', International Telecommunication Union, 581 Telecommunication Standardization Sector (ITU-T), March 1996. 583 10. Author's Address 585 Carsten Bormann 586 Universitaet Bremen FB3 TZI 587 Postfach 330440 588 D-28334 Bremen, GERMANY 589 cabo@tzi.org 590 phone +49.421.218-7024 591 fax +49.421.218-7000 593 Acknowledgements 595 Much of the early discussion that led to this document was done with 596 Scott Petrack and Cary Fitzgerald. Steve Casner, Mikael Degermark, 597 Steve Jackowski, Dave Oran, the other members of the ISSLL subgroup 598 on low bitrate links (ISSLOW), and in particular the ISSLL WG co- 599 chairs Eric Crawley and John Wroclawski have helped in making this 600 architecture a reality.