idnits 2.17.1 draft-ietf-issll-isslow-04.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-16) 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: ---------------------------------------------------------------------------- == Line 305 has weird spacing: '...ts, or that ...' == Line 307 has weird spacing: '...for prioritiz...' -- 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 (August 1998) is 9376 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 547, 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-05 -- 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: A later version (-05) exists of draft-ietf-avt-crtp-04 == Outdated reference: A later version (-06) exists of draft-ietf-issll-isslow-mcml-04 == Outdated reference: A later version (-05) exists of draft-ietf-issll-isslow-rtf-03 -- 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: 11 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Carsten Bormann 3 Expires: February 1999 Universitaet Bremen TZI 4 August 1998 6 Providing integrated services over low-bitrate links 7 draft-ietf-issll-isslow-04.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), ftp.ietf.org (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 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[1]. 188 Generally, header compression operates by installing state at both 189 ends of a path that allows the receiving end to reconstruct 190 information omitted at the sending end. Many good techniques for 191 header compression (RFC 1144, [2]) operate on the assumption that the 192 path will not reorder the frames generated. This assumption does not 193 hold for end-to-end compression; therefore additional overhead is 194 required for resequencing state changes and for compressed packets 195 making use of these state changes. 197 Assume that a very good application level header compression solution 198 for RTP flows could be able to save 11 out of the 12 bytes of an RTP 199 header [3]. Even this perfect solution only reduces the total header 200 _________________________ 201 [1] or actually by using a non-standard, efficiently coded head- 202 er in the first place. 204 overhead by 1/4. It would have to be deployed in all applications, 205 even those that operate on systems that are attached to higher- 206 bitrate links. 208 Because of this limited effectiveness, the AVT group that is 209 responsible for RTP within the IETF has decided to not further pursue 210 application level header compression. 212 For router and IP stack vendors, the obvious approach is to define 213 header compression that can be negotiated between peer routers. 215 Advanced header compression techniques now being defined in the IETF 216 [2] certainly can relieve the link from significant parts of the 217 IP/UDP overhead (i.e., most of 28 of the 44 bytes mentioned above). 219 One of the design principles of the new IP header compression 220 developed in conjunction with IPv6 is that it stops at layers the 221 semantics of which cannot be inferred from information in lower layer 222 (outer) headers. Therefore, this header compression technique alone 223 cannot compress the data that is contained within UDP packets. 225 Any additional header compression technique runs into a problem: If 226 it assumes specific application semantics (i.e., those of RTP and a 227 payload data format) based on heuristics, it runs the risk of being 228 triggered falsely and (e.g. in case of packet loss) reconstructing 229 packets that are catastrophically incorrect for the application 230 actually being used. A header compression technique that can be 231 operated based on heuristics but does not cause incorrect 232 decompression even if the heuristics failed is described in [7]; a 233 companion document describes the mapping of this technique to PPP 234 [10]. 236 With all of these techniques, the total IP/UDP/RTP header overhead 237 for an audio stream can be reduced to two bytes per packet. This 238 technology need only be deployed at bottleneck links; high-speed 239 links can transfer the real-time streams without routers or switches 240 expending CPU cycles to perform header compression. 242 4. Principles of Real-Time Encapsulation for Low-Bitrate Links 244 The main design goal for a real-time encapsulation is to minimize the 245 delay incurred by real-time packets that become available for sending 246 while a long data packet is being sent. To achieve this, the 247 encapsulation must be able to either abort or suspend the transfer of 248 the long data packet. As an additional goal is to minimize the 249 overhead required for the transmission of packets from periodic 250 flows, this strongly argues for being able to suspend a packet, i.e. 251 segment it into parts between which the real-time packets can be 252 transferred. 254 4.1. Using existing IP fragmentation 256 Transmitting only part of a packet, to allow higher-priority traffic 257 to intervene and then resuming its transmission later on, is a kind 258 of fragmentation. Fragmentation is an existing functionality of the 259 IP layer: An IPv4 header already contains fields that allow a large 260 IP datagram to be fragmented into small parts. A sender's ``real- 261 time PPP'' implementation might simply indicate a small MTU to its IP 262 stack and thus cause all larger datagrams to be fragmented down to a 263 size that allows the access delay goals to be met[2]. (Also, a PPP 264 implementation can negotiate down the MTU of its peer, causing the 265 peer to fragment to a small size, which might be considered a crude 266 form of negotiating an access delay goal with the peer system -- if 267 that system supports priority queueing at the fragment level.) 269 Unfortunately, a full, 20 byte IP header is needed for each fragment 270 (larger when IP options are used). This limits the minimum size of 271 fragments that can be used without too much overhead. (Also, the 272 size of non-final fragments must be a multiple of 8 bytes, further 273 limiting the choice.) With path MTU discovery, IP level 274 fragmentation causes TCP implementations to use small MSSs -- this 275 further increases the per-packet overhead to 40 bytes per fragment. 277 In any case, fragmentation at the IP level persists on the path 278 further down to the datagram receiver, increasing the transmission 279 overheads and router load throughout the network. With its high 280 overhead and the adverse effect on the Internet, IP level 281 fragmentation can only be a stop-gap mechanism when no other 282 fragmentation protocol is available in the peer implementation. 284 4.2. Link-Layer Mechanisms 286 Cell-oriented multiplexing techniques such as ATM that introduce 287 regular points where cells from a different packet can be 288 interpolated are too inefficient for low-bitrate links; also, they 289 are not supported by chips used to support the link layer in low- 290 bitrate routers and host interfaces. 292 Instead, the real-time encapsulation should as far as possible make 293 use of the capabilities of the chips that have been deployed. On 294 synchronous lines, these chips support HDLC framing; on asynchronous 295 lines, an asynchronous variant of HDLC that usually is implemented in 296 software is being used. Both variants of HDLC provide a delimiting 297 mechanism to indicate the end of a frame over the link. The obvious 298 solution to the segmentation problem is to combine this mechanism 299 with an indication of whether the delimiter terminates or suspends 300 the current packet. 302 This indication could be in an octet appended to each frame 303 _________________________ 304 [2] This assumes that the IP stack is able to priority-tag frag- 305 ments, or that the PPP implementation is able to correlate the 306 fragments to the initial one that carries the information relevant 307 for prioritizing, or that only initial fragments can be high- 308 priority. 310 information field; however, seven out of eight bits of the octet 311 would be wasted. Instead, the bit could be carried at the start of 312 the next frame in conjunction with multiplexing information (PPP 313 protocol identifier etc.) that will be required here anyway. Since 314 the real-time flows will in general be periodic, this multiplexing 315 information could convey (part of) the compressed form of the header 316 for the packet. If packets from the real-time flow generally are of 317 constant length (or have a defined maximum length that is often 318 used), the continuation of the suspended packet could be immediately 319 attached to it, without expending a further frame delimiter, i.e., 320 the interpolation of the real-time packet would then have zero 321 overhead. Since packets from low-delay real-time flows generally 322 will not require the ability to be further suspended, the 323 continuation bit could be reserved for the non-real-time packet 324 stream. 326 One real-time encapsulation format with these (and other) functions 327 is described in ITU-T H.223 [13], the multiplex used by the H.324 328 modem-based videophone standard [14]. It was investigated whether 329 compatibility could be achieved with this specification, which will 330 be used in future videophone-enabled (H.324 capable) modems. 331 However, since the multiplexing capabilities of H.223 are limited to 332 15 schedules (definitions of sequences of packet types that can be 333 identified in a multiplex header), for general Internet usage a 334 superset or a more general encapsulation would have been required. 335 Also, a PPP-style negotiation protocol was needed instead of using 336 (and necessarily extending) ITU-T H.245 [15] for setting the 337 parameters of the multiplex. In the PPP context, the interactions 338 with the encapsulations for data compression and link layer 339 encryption needed to be defined (including operation in the presence 340 of padding). But most important, H.223 requires synchronous HDLC 341 chips that can be configured to send frames without an attached CRC, 342 which is not possible with all chips deployed in commercially 343 available routers; so complete compatibility was unachievable. 345 Instead of adopting H.223, it was decided to pursue an approach that 346 is oriented towards compatibility both with existing hardware and 347 existing software (in particular PPP) implementations. The next 348 subsection groups these implementations according to their 349 capabilities. 351 4.3. Implementation models 353 This section introduces a number of terms for types of 354 implementations that are likely to emerge. It is important to have 355 these different implementation models in mind as there is no single 356 approach that fits all models best. 358 4.3.1. Sender types 360 There are two fundamental approaches to real-time transmission on 361 low-bitrate links: 363 Sender type 1 364 The PPP real-time framing implementation is able to control the 365 transmission of each byte being transmitted with some known, 366 bounded delay (e.g., due to FIFOs). For example, this is 367 generally true of PC host implementations, which directly access 368 serial interface chips byte by byte or by filling a very small 369 FIFO. For type 1 senders, a suspend/resume type approach will 370 be typically used: When a long frame is to be sent, the attempt 371 is to send it undivided; only if higher priority packets come up 372 during the transmission will the lower-priority long frame be 373 suspended and later resumed. This approach allows the minimum 374 variation in access delay for high-priority packets; also, 375 fragmentation overhead is only incurred when actually needed. 377 Sender type 2 378 With type 2 senders, the interface between the PPP real-time 379 framing implementation and the transmission hardware is not in 380 terms of streams of bytes, but in terms of frames, e.g., in the 381 form of multiple (prioritized) send queues directly supported by 382 hardware. This is often true of router systems for synchronous 383 links, in particular those that have to support a large number 384 of low-bitrate links. As type 2 senders have no way to suspend 385 a frame once it has been handed down for transmission, they 386 typically will use a queues-of-fragments approach, where long 387 packets are always split into units that are small enough to 388 maintain the access delay goals for higher-priority traffic. 389 There is a trade-off between the variation in access delay 390 resulting from a large fragment size and the overhead that is 391 incurred for every long packet by choosing a small fragment 392 size. 394 4.3.2. Receiver types 396 Although the actual work of formulating transmission streams for 397 real-time applications is performed at the sender, the ability of the 398 receiver to immediately make use of the information received depends 399 on its characteristics: 401 Receiver type 1 402 Type 1 receivers have full control over the stream of bytes 403 received within PPP frames, i.e., bytes received are available 404 immediately to the PPP real-time framing implementation (with 405 some known, bounded delay e.g. due to FIFOs etc.). 407 Receiver type 2 408 With type 2 receivers, the PPP real-time framing implementation 409 only gets hold of a frame when it has been received completely, 410 i.e., the final flag has been processed (typically by some HDLC 411 chip that directly fills a memory buffer). 413 4.4. Conclusion 415 As a result of the diversity in capabilities of current 416 implementations, there are now two specifications for real-time 417 encapsulation: One, the multi-class extension to the PPP multi-link 418 protocol, is providing the solution for the queues-of-fragments 419 approach by extending the single-stream PPP multi-link protocol by 420 multiple classes [8]. The other encapsulation, PPP in a real-time 421 oriented HDLC-like framing, builds on this specification end extends 422 it by a way to dynamically delimit multiple fragments within one HDLC 423 frame [9], providing the solution for the suspend/resume type 424 approach. 426 5. Principles of Header Compression for Real-Time Flows 428 A good baseline for a discussion about header compression is in the 429 new IP header compression specification that was designed in 430 conjunction with the development of IPv6 [2]. The techniques used 431 there can reduce the 28 bytes of IPv4/UDP header to about 6 bytes 432 (depending on the number of concurrent streams); with the remaining 4 433 bytes of HDLC/PPP overhead and 12 bytes for RTP the total header 434 overhead can be about halved but still exceeds the size of a G.723.1 435 ACELP frame. Note that, in contrast to IP header compression, the 436 environment discussed here assumes the existence of a full-duplex PPP 437 link and thus can rely on negotiation where IP header compression 438 requires repeated transmission of the same information. (The use of 439 the architecture of the present document with link layer multicasting 440 has not yet been examined.) 442 Additional design effort was required for RTP header compression. 443 Applying the concepts of IP header compression, of the (at least) 12 444 bytes in an RTP header, 7 bytes (timestamp, sequence, and marker bit) 445 would qualify as RANDOM; DELTA encoding cannot generally be used 446 without further information since the lower layer header does not 447 unambiguously identify the semantics and there is no TCP checksum 448 that can be relied on to detect incorrect decompression. Only a more 449 semantics-oriented approach can provide better compression (just as 450 RFC 1144 can provide very good compression of TCP headers by making 451 use of semantic knowledge of TCP and its checksumming method). 453 For RTP packets, differential encoding of the sequence number and 454 timestamps is an efficient approach for certain cases of payload data 455 formats. E.g., speech flows generally have sequence numbers and 456 timestamp fields that increase by 1 and by the frame size in 457 timestamp units, resp.; the CRTP (compressed RTP) specification makes 458 use of this relationship by encoding these fields only when the 459 second order difference is non-zero [7]. 461 6. Announcement Protocols Used by Applications 463 As argued, the compressor can operate best if it can make use of 464 information that clearly identifies real-time streams and provides 465 information about the payload data format in use. 467 If these systems are routers, this consent must be installed as 468 router state; if these systems are hosts, it must be known to their 469 networking kernels. Sources of real-time information flows are 470 already describing characteristics of these flows to their kernels 471 and to the routers in the form of TSpecs in RSVP PATH messages [4]. 472 Since these messages make use of the router alert option, they are 473 seen by all routers on the path; path state about the packet stream 474 is normally installed at each of these routers that implement RSVP. 475 Additional RSVP objects could be defined that are included in PATH 476 messages by those applications that desire good performance over low- 477 bitrate links; these objects would be coded to be ignored by routers 478 that are not interested in them (class number 11bbbbbb). 480 Note that the path state is available in the routers even when no 481 reservation is made; this allows informed compression of best-effort 482 traffic. It is not quite clear, though, how path state could be 483 teared down quickly when a source ceases to transmit. 485 7. Elements of Hop-By-Hop Negotiation Protocols 487 The IP header compression specification attempts to account for 488 simplex and multicast links by providing information about the 489 compressed streams only in the forward direction. E.g., a full 490 IP/UDP header must be sent after F_MAX_TIME (currently 3 seconds), 491 which is a negligible total overhead (e.g. one full header every 150 492 G.723.1 packets), but must be considered carefully in scheduling the 493 real-time transmissions. Both simplex and multicast links are not 494 prevailing in the low-bitrate environment (although multicast 495 functionality may become more important with wireless systems); in 496 this document, we therefore assume full-duplex capability. 498 As compression techniques will improve, a negotiation between the two 499 peers on the link would provide the best flexibility in 500 implementation complexity and potential for extensibility. The peer 501 routers/hosts can decide which real-time packet streams are to be 502 compressed, which header fields are not to be sent at all, which 503 multiplexing information should be used on the link, and how the 504 remaining header fields should be encoded. PPP, a well-tried suite 505 of negotiation protocols, is already used on most of the low-bitrate 506 links and seems to provide the obvious approach. Cooperation from 507 PPP is also needed to negotiate the use of real-time encapsulations 508 between systems that are not configured to automatically do so. 509 Therefore, PPP options that can be negotiated at the link setup (LCP) 510 phase are included in [8], [9], and [10]. 512 8. Security Considerations 514 Header compression protocols that make use of assumptions about 515 application protocols need to be carefully analyzed whether it is 516 possible to subvert other applications by maliciously or 517 inadvertently enabling their use. 519 It is generally not possible to do significant hop-by-hop header 520 compression on encrypted streams. With certain security policies, it 521 may be possible to run an encrypted tunnel to a network access server 522 that does header compression on the decapsulated packets and sends 523 them over an encrypted link encapsulation; see also the short mention 524 of interactions between real-time encapsulation and encryption in 525 section 4 above. If the security requirements permit, a special RTP 526 payload data format that encrypts only the data may preferably be 527 used. 529 9. References 531 [1] Mark Handley, Jon Crowcroft, Carsten Bormann, Joerg Ott. ``The 532 Internet Multimedia Conferencing Architecture'', Work in 533 Progress (draft-ietf-mmusic-confarch-00.txt), July 1997. 535 [2] M. Degermark, B. Nordgren, S. Pink, ``IP Header Compression'', 536 Work in Progress (draft-degermark-ipv6-hc-05.txt), December 537 1997. 539 [3] Scott Petrack, Ed Ellesson, ``Framework for C/RTP: Compressed 540 RTP Using Adaptive Differential Header Compression'', 541 contribution to the mailing list rem-conf@es.net, February 1996. 543 [4] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, 544 ``Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 545 Specification'', RFC 2205, September 1997. 547 [5] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, ``The 548 PPP Multilink Protocol (MP)'', RFC 1990, August 1996 (obsoletes 549 RFC1717). 551 [6] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, ``RTP: A 552 Transport Protocol for Real-Time Applications'', RFC 1889, 553 January 1996. 555 [7] S. Casner, V. Jacobson, ``Compressing IP/UDP/RTP Headers for 556 Low-Speed Serial Links'', Work in Progress (draft-ietf-avt- 557 crtp-04.txt), November 1997. 559 [8] C. Bormann, ``The Multi-Class Extension to Multi-Link PPP'', 560 Work in Progress (draft-ietf-issll-isslow-mcml-04.txt), August 561 1998. 563 [9] C. Bormann, ``PPP in a real-time oriented HDLC-like framing'', 564 Work in Progress (draft-ietf-issll-isslow-rtf-03.txt), August 565 1998. 567 [10] M. Engan, S. Casner, C. Bormann, ``IP Header Compression over 568 PPP'', Work in Progress (draft-engan-ip-compress-02.txt), 569 December 1997. 571 [11] J. Wroclawski. ``Specification of the Controlled-Load Network 572 Element Service'', RFC 2211, September 1997. 574 [12] S. Shenker, C. Partridge, R. Guerin. ``Specification of 575 Guaranteed Quality of Service'', RFC 2212, September 1997. 577 [13] ITU-T Recommendation H.223, ``Multiplexing protocol for low bit 578 rate multimedia communication'', International Telecommunication 579 Union, Telecommunication Standardization Sector (ITU-T), March 580 1996. 582 [14] ITU-T Recommendation H.324, ``Terminal for low bit rate 583 multimedia communication'', International Telecommunication 584 Union, Telecommunication Standardization Sector (ITU-T), March 585 1996. 587 [15] ITU-T Recommendation H.245, ``Control protocol for multimedia 588 communication'', International Telecommunication Union, 589 Telecommunication Standardization Sector (ITU-T), March 1996. 591 10. Author's Address 593 Carsten Bormann 594 Universitaet Bremen FB3 TZI 595 Postfach 330440 596 D-28334 Bremen, GERMANY 597 cabo@tzi.org 598 phone +49.421.218-7024 599 fax +49.421.218-7000 601 Acknowledgements 603 Much of the early discussion that led to this document was done with 604 Scott Petrack and Cary Fitzgerald. Steve Casner, Mikael Degermark, 605 Steve Jackowski, Dave Oran, the other members of the ISSLL subgroup 606 on low bitrate links (ISSLOW), and in particular the ISSLL WG co- 607 chairs Eric Crawley and John Wroclawski have helped in making this 608 architecture a reality.