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