idnits 2.17.1 draft-ietf-issll-isslow-00.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-26) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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. ** There are 4 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** 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 99 has weird spacing: '...1] Note that ...' == Line 101 has weird spacing: '...]. To defin...' == Line 103 has weird spacing: '...session initi...' == Line 447 has weird spacing: '... date cal...' == Line 661 has weird spacing: '.... This would...' == (4 more instances...) -- 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 1996) is 10177 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) == 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-00 -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Carsten Bormann 3 Expires: December 1996 Universitaet Bremen 4 June 1996 6 Providing integrated services over low-bitrate links 7 draft-ietf-issll-isslow-00.txt 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. 29 Abstract 31 This document describes an architecture for providing integrated 32 services over low-bitrate links, such as modem lines, ISDN B- 33 channels, and sub-T1 links. It covers only the lower parts of the 34 Internet Multimedia Conferencing Architecture [1]; additional 35 components required for application services such as Internet 36 Telephony (e.g., a session initiation protocol) are outside the scope 37 of this document. The main components of the architecture are: a 38 real-time encapsulation format for asynchronous and synchronous low- 39 bitrate links, a header compression architecture optimized for real- 40 time flows, elements of negotiation protocols used between routers 41 (or between hosts and routers), and announcement protocols used by 42 applications to allow this negotiation to take place. 44 Annexes contain initial strawman proposals for the elements of the 45 architecture, complemented by a list of issues that need to be 46 resolved to proceed. 48 This document is a submission to the IETF ISSLL working-group-in- 49 creation. 50 Comments are solicited and should be addressed to the working group's 51 mailing list at issll@mercury.lcs.mit.edu and/or the author. 53 1. Introduction 55 As an extension to the ``best-effort'' services the Internet is well- 56 known for, additional types of services (``integrated services'') 57 that support the transport of real-time multimedia information are 58 being developed for and deployed in the Internet. Important elements 59 of this development are: 61 - parameters for forwarding mechanisms that are appropriate for 62 real-time information (in the intserv working group of the IETF) 64 - a setup protocol that allows establishing special forwarding 65 treatment for real-time information flows (RSVP [4], in the rsvp 66 working group of the IETF) 68 - a transport protocol for real-time information (RTP/RTCP, in the 69 avt working group of the IETF)[1]. 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 the 19.75 bytes needed for a G.723.1 ACELP audio frame -- 88 a 14.4 kbit/s link is completely consumed by this header overhead 89 alone at 40 real-time frames per second (i.e., at 25 ms packetization 90 delay for one stream or 50 ms for two streams, with no space left for 91 data, yet). While the header overhead can be reduced by combining 92 several real-time information frames into one packet, this increases 93 the delay incurred while filling that packet and further detracts 94 from the goal of real-time transfer of multi-media information over 95 the Internet. 97 This document describes an approach for addressing these problems. 98 _________________________ 99 [1] Note that this document only is concerned with the network 100 and transport parts of the Internet Multimedia Conferencing Archi- 101 tecture [1]. To define application services such as Internet 102 Telephony, additional components are required, e.g., protocols for 103 session initiation and control. These components are outside the 104 scope of this document. 106 The main components of the architecture are: 108 - a real-time encapsulation format for asynchronous and 109 synchronous low-bitrate links, 111 - a header compression architecture optimized for real-time flows, 113 - elements of negotiation protocols used between routers (or 114 between hosts and routers), and 116 - announcement protocols used by applications to allow this 117 negotiation to take place. 119 2. Design Considerations 121 The main design goal for an architecture that addresses real-time 122 multimedia flows over low-bitrate links is that of minimizing the 123 end-to-end delay. More specifically, the worst case delay (after 124 removing possible outliers, which are equivalent to packet losses 125 from an application point of view) is what determines the playout 126 points selected by the applications and thus the delay actually 127 perceived by the user. 129 In addition, any such architecture should obviously undertake every 130 attempt to maximize the bandwidth actually available to media data; 131 overheads must be minimized. 133 An important component of the integrated services architecture is the 134 provision of reservations for real-time flows. One of the problems 135 that systems on low-bitrate links (routers or hosts) face when 136 performing admission control for such reservations is that they must 137 translate the bandwidth requested in the reservation to the one 138 actually consumed on the link. Methods such as data compression 139 and/or header compression can reduce the requirements on the link, 140 but admission control can only make use of the reduced requirements 141 in its calculations if it has enough information about the data 142 stream to know how effective the compression will be. One goal of 143 the architecture therefore is to provide the integrated services 144 admission control with this information. A beneficial side effect 145 may be to allow the systems to perform better compression than would 146 be possible without this information. This may make it worthwhile to 147 provide this information even when it is not intended to make a 148 reservation for a real-time flow. 150 3. The Need for a Concerted Approach 152 Given that there are so many technical approaches to addressing the 153 problem, one wonders whether maybe one of these techniques could 154 suffice or whether maybe they could be applied independently of each 155 other, reducing the need for synchronization between IETF working 156 groups and the need for verbose architecture papers such as the 157 present one. This section therefore examines the opportunities of 158 using each of a number of these techniques in isolation. 160 3.1. Defining a Real-Time Encapsulation Only 162 The purpose of defining a real-time link-layer encapsulation protocol 163 is to be able to introduce newly arrived real-time packets in the 164 link-layer data stream without having to wait for the currently 165 transmitted (possibly large) packet to end. To be able to do this in 166 an interface driver, it is first necessary to identify packets that 167 belong to these flows. If one does not want to resort to a heuristic 168 approach (e.g., favor the transmission of highly periodic flows of 169 small packets transported in IP/UDP[2]), one should make use of the 170 protocol defined for identifying flows that require special 171 treatment, i.e. RSVP. Of the two service types defined for use with 172 RSVP now, the guaranteed service, will only be available in certain 173 environments. For this and various other reasons, the obvious 174 service type for most adaptive audio/video applications will be the 175 controlled-load service. Controlled-load does not provide control 176 parameters for target delay; this makes it very hard to identify 177 those packet streams that would benefit most of being transported in 178 a real-time encapsulation format. 180 Obviously, a real-time encapsulation must be part of any complete 181 solution as the problem of delays induced by large frames on the link 182 can only be solved on this layer. It is not sufficient on its own, 183 however: Even if the relevant flows can be appropriately identified 184 for real-time treatment, most applications simply are not possible on 185 low-bitrate links with the header overhead implied by the combination 186 of HDLC/PPP, IP, UDP, and RTP, i.e. they absolutely require header 187 compression. 189 3.2. Using Application Header Compression Only 191 For the internet telephone vendors, the approach that comes to mind 192 immediately is to reduce overhead by building header compression into 193 the applications[3]. 195 Generally, header compression operates by installing state at both 196 ends of a link that allows the receiving end to reconstruct 197 information omitted at the sending end. Many good techniques for 198 _________________________ 199 [2] Which could turn out to be a DNS implementation gone wild or 200 a malicious attempt to gain preferential access to an Internet re- 201 source. 202 [3] or actually by using a non-standard, efficiently coded head- 203 er in the first place. 205 header compression (RFC 1144, [2]) operate on the assumption that the 206 link will not reorder the frames generated. This assumption does not 207 hold for end-to-end compression; therefore additional overhead is 208 required for resequencing state changes and compressed packets making 209 use of these state changes. 211 Assume that a very good application level header compression solution 212 for RTP flows could be able to save 11 out of the 12 bytes of an RTP 213 header [3]. Even this perfect solution only reduces the total header 214 overhead by 1/4. It would have to be deployed in all applications, 215 even those that operate on systems that are attached to higher- 216 bitrate links. 218 3.3. Using Hop-By-Hop Header Compression Only 220 For router vendors, the obvious approach is to define header 221 compression that can be negotiated between peer routers. 223 Advanced header compression techniques now being defined in the IETF 224 [2] certainly can relieve the link from significant parts of the 225 IP/UDP overhead (i.e., of 28 of the 44 bytes mentioned above). 227 One of the design principles of the header compression contemplated 228 for IPv6 is that it stops at layers the semantics of which cannot be 229 inferred from information in lower layer (outer) headers. Therefore, 230 IPv6 header compression cannot compress the data within UDP packets. 232 Any additional header compression technique runs into a difficult 233 problem: If it assumes specific application semantics (i.e., those of 234 RTP and a payload data format) based on heuristics, it runs the risk 235 of being triggered falsely and (e.g. in case of packet loss) 236 reconstructing packets that are catastrophically incorrect for the 237 application actually being used. If it does not presume application 238 semantics, it will only be able to achieve limited compression, as it 239 needs to carry sufficient information in each packet that, even in 240 the presence of packet loss on the link, only packets are ever 241 reconstructed that are correct bit-by-bit. Together with link layer 242 overheads, it is likely that more than half of the 19.75 bytes used 243 for a G.723.1 ACELP frame would be needed for header overhead. 245 4. A Real-Time Encapsulation Format for Low-Bitrate Links 247 The main design goal for a real-time encapsulation is to minimize the 248 delay incurred by real-time packets that become available for sending 249 while a long data packet is being sent. To achieve this, the 250 encapsulation must be able to either abort or suspend the transfer of 251 the long data packet. An additional goal is to minimize the overhead 252 required for the transmission of packets from periodic flows. This 253 strongly argues for being able to suspend a packet, i.e. segment it 254 into parts between which the real-time packets can be transferred. 256 Cell-oriented multiplexing techniques such as ATM that introduce 257 regular points where cells from a different packet can be 258 interpolated are too inefficient for low-bitrate links; also, they 259 are not supported by chips used to support the link layer in low- 260 bitrate routers and host interfaces. 262 Instead, the real-time encapsulation should as far as possible make 263 use of the capabilities of the chips that have been deployed. On 264 synchronous lines, these chips support HDLC framing; on asynchronous 265 lines, an asynchronous variant of HDLC that usually is implemented in 266 software is being used. Both variants of HDLC provide a delimiting 267 mechanism to indicate the end of a frame over the link. The obvious 268 solution to the segmentation problem is to combine this mechanism 269 with an indication of whether the delimiter terminates or suspends 270 the current packet. 272 This indication could be in an octet appended to each frame 273 information field; however, seven out of eight bits of the octet 274 would be wasted. Instead, the bit could be carried at the start of 275 the next frame in conjunction with multiplexing information (PPP 276 protocol identifier etc.) that will be required here anyway. Since 277 the real-time flows will in general be periodic, this multiplexing 278 information could convey (part of) the compressed form of the header 279 for the packet. If packets from the real-time flow generally are of 280 constant length (or have a defined maximum length that is often 281 used), the continuation of the suspended packet could be immediately 282 attached to it, without expending a further frame delimiter, i.e., 283 the interpolation of the real-time packet would then have zero 284 overhead. Since packets from low-delay real-time flows generally 285 will not require the ability to be further suspended, the 286 continuation bit could be reserved for the non-real-time packet 287 stream. 289 A real-time encapsulation with these (and other) functions is 290 described in ITU-T H.223. It may be desirable to strive for 291 compatibility with this specification, which will be used in future 292 videophone-enabled (H.324 capable) modems. However, since the 293 multiplexing capabilities of H.223 are limited to 15 schedules 294 (definitions of sequences of packet types that can be identified in a 295 multiplex header), it may be desirable to define a superset or a more 296 general encapsulation. It may also be desirable to rely on a PPP- 297 style negotiation protocol instead of using (and necessarily 298 extending) ITU-T H.245 for setting the parameters of the multiplex. 299 The interactions with the encapsulations for data compression and 300 link layer encryption need to be defined (including operation in the 301 presence of padding). Finally, H.223 requires synchronous HDLC chips 302 that can be configured to send frames without an attached CRC, which 303 is not possible with all chips deployed in commercially available 304 routers; additional flexibility is needed here. 306 Annex A provides further considerations about real-time 307 encapsulations. 309 5. A Header Compression Architecture for Real-Time Flows 311 A good baseline for a discussion about header compression is in the 312 IPv6 header compression draft [2]. The techniques used there can 313 reduce the 28 bytes of IPv4/UDP header to about 6 bytes (depending on 314 the number of concurrent streams); with the remaining 4 bytes of 315 HDLC/PPP overhead and 12 bytes for RTP the total header overhead can 316 be about halved but still exceeds the size of a G.723.1 ACELP frame. 317 Note that, in contrast to IPv6 header compression, the present 318 document assumes the existence of a full-duplex PPP link and thus can 319 rely on negotiation where IPv6 header compression requires repeated 320 transmission of the same information. (The use of the architecture 321 of the present document with link layer multicasting has not yet been 322 examined.) 324 Additional design effort is required for RTP header compression. 325 Applying the concepts of IPv6 header compression, of the (at least) 326 12 bytes in an RTP header, 7 bytes (timestamp, sequence, and marker 327 bit) would qualify as RANDOM; DELTA encoding cannot generally be used 328 without further information since the lower layer header does not 329 unambiguously identify the semantics and there is no TCP checksum 330 that can be relied on to detect incorrect decompression. Only a more 331 semantics-oriented approach can provide better compression (just as 332 RFC 1144 can provide very good compression of TCP headers by making 333 use of semantic knowledge of TCP and its checksumming method). 335 For RTP packets, differential encoding of the sequence number and 336 timestamps is an efficient approach for certain cases of payload data 337 formats. E.g., speech flows generally have sequence numbers and 338 timestamp fields that increase by 1 and by the frame size in 339 timestamp units, resp.; for encodings such as G.723.1, a seven-bit 340 (leaving space for the marker bit) field that conveys both would 341 provide security against +- 2 seconds of delay jitter for G.723.1 342 (the compressor would need to drop or more expensively code all 343 packets outside that jitter window). For a certain subset of these 344 cases, the encoding of these fields is essentially optional as errors 345 caused by incorrect decompression after single packet loss on the 346 link are of minor significance in the playout process; the compressor 347 would have to reorder or drop misordered packets (the RTP marker bit 348 could be inserted into one of the two unused bits for a G.723.1 ACELP 349 payload data format). 351 Annex C provides further considerations about RTP header compression. 353 6. Announcement Protocols Used by Applications 355 It should be obvious from the discussion of header compression that 356 the compressor can operate best if it can make use of information 357 that clearly identifies real-time streams and provides information 358 about the payload data format in use. For the more aggressive 359 compression methods that in certain cases can induce information 360 loss, the systems on the low-bitrate link should have consent from 361 the application to actually go this far. 363 If these systems are routers, this consent must be installed as 364 router state; if these systems are hosts, it must be known to their 365 networking kernels. Sources of real-time information flows are 366 already describing characteristics of these flows to their kernels 367 and to the routers in the form of TSpecs in RSVP PATH messages [4]. 368 Since these messages make use of the router alert option, they are 369 seen by all routers on the path; path state about the packet stream 370 is normally installed at each of these routers that implement RSVP. 371 Additional RSVP objects could be defined that are included in PATH 372 messages by those applications that desire good performance over low- 373 bitrate links; these objects would be coded to be ignored by routers 374 that are not interested in them (class number 11bbbbbb). 376 Note that the path state is available in the routers even when no 377 reservation is made; this allows informed compression of best-effort 378 traffic. It is not quite clear to the author how path state could be 379 teared down quickly when a source ceases to transmit. 381 To be able do deploy informed header compression before RSVP, an 382 additional form of application announcements could be defined that do 383 not require RSVP to be available at the transmitting host; it would 384 be advisable to use the router alert option on these messages, too. 385 Alternatively, UDP encapsulation of RSVP could be used (note that a 386 way needs to be available to inform the local kernel if the system is 387 directly on a low-bitrate link). 389 Annex D provides further considerations about announcement protocols. 391 7. Elements of Hop-By-Hop Negotiation Protocols 393 The IPv6 header compression draft attempts to account for simplex and 394 multicast links by providing information about the compressed streams 395 only in the forward direction. E.g., a full IP/UDP header must be 396 sent after F_MAX_TIME (currently 3 seconds), which is a negligible 397 total overhead (e.g. one full header every 150 G.723.1 packets), but 398 must be considered carefully in scheduling the real-time 399 transmissions. Both simplex and multicast links are not prevailing 400 in the low-bitrate environment (although multicast functionality may 401 become more important with wireless systems); in this document, we 402 therefore assume full-duplex capability. 404 As compression techniques will improve, a negotiation between the two 405 peers on the link would provide the best flexibility in 406 implementation complexity and potential for extensibility. The peer 407 routers/hosts can decide which real-time packet streams are to be 408 compressed, which header fields are not to be sent at all, which 409 multiplexing information should be used on the link, and how the 410 remaining header fields should be encoded. PPP, a well-tried suite 411 of negotiation protocols, is already used on most of the low-bitrate 412 links and seems to provide the obvious approach. Cooperation from 413 PPP is also needed to negotiate the use of real-time encapsulations 414 between systems that are not configured to automatically do so. 416 8. A Plan for Further Work 418 This section proposes a rough work plan to develop and deploy this 419 architecture. This plan obviously needs to be discussed between the 420 parties involved. 422 The overall responsibility for this work could be in the domain of 423 the newly created IETF issll (Integrated Services over Specific Link 424 Layers) working group. The pppext working group would be the logical 425 place to discuss the real-time encapsulation and pertinent 426 negotiation protocols. Work on RTP compression, including 427 compression methods specific to particular payload data formats 428 should be done within the avt working group; this should include 429 media-specific input for the negotiation protocols (a format for 430 describing information about media flows has been defined in the 431 mmusic working group). The rsvp working group should agree to the 432 way PATH messages are used and provide a code point for the new RSVP 433 object. 435 Initial deployment of the real-time encapsulation could be in network 436 access servers and access routers, with IP stacks on hosts following. 437 Outreach activities are probably required to receive timely input 438 from application vendors. 440 In addition to the work described in this document, additional work 441 is required to define the service mappings for controlled-load and 442 guaranteed services on serial links; the latter also requires 443 techniques to find out about the delay of the link. The following 444 schedule is suggested: 446 Item Draft WG last 447 date call date 448 1: Realtime Header-compression and packet framing protocol 8/96 2/97 449 2: Controlled Load Service over ISSLOW 8/96 TBD 450 3: Link Delay Measurement Protocol TBD 451 4: Guaranteed Service over ISSLOW TBD 453 Obviously, item 1 requires particularly close coordination with 454 pppext (for the framing format) and avt (for RTP header compression), 455 as well as with the group working on IPv6 header compression, ipngwg. 457 9. Security Considerations 459 Header compression protocols that make use of assumptions about 460 application protocols need to be carefully analyzed whether it is 461 possible to subvert other applications by maliciously or 462 inadvertently enabling their use. 464 It is generally not possible to do significant hop-by-hop header 465 compression on encrypted streams. With certain security policies, it 466 may be possible to run an encrypted tunnel to a network access server 467 that does header compression on the decapsulated packets and sends 468 them over an encrypted link encapsulation; see also the short mention 469 of interactions between real-time encapsulation and encryption in 470 section 4 above. 472 10. Author's Address 474 Carsten Bormann 475 Universitaet Bremen FB3 MZH 5180 476 Postfach 330440 477 D-28334 Bremen 478 GERMANY 479 cabo@informatik.uni-bremen.de 480 phone +49.421.218-7024 482 Acknowledgements 484 Much of the discussion in this document is based on discussions with 485 Scott Petrack of IBM Israel and Cary Fitzgerald of Cisco Systems. 487 11. References 489 [1] Mark Handley, Jon Crowcroft, Carsten Bormann, ``The Internet 490 Multimedia Conferencing Architecture,'' Internet-Draft draft- 491 ietf-mmusic-confarch-00.txt, Work in Progress, February 1996. 493 [2] M. Degermark, B. Nordgren, S. Pink, ``Header Compression for 494 IPv6,'' Internet-Draft draft-degermark-ipv6-hc-00.txt, Work in 495 Progress, February 1996. 497 [3] Scott Petrack, Ed Ellesson, ``Framework for C/RTP: Compressed 498 RTP Using Adaptive Differential Header Compression'', 499 contribution to the mailing list rem-conf@es.net, February 1996. 501 [4] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, 502 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 503 Specification, Internet-Draft draft-ietf-rsvp-spec-10.txt, Work 504 in Progress, February 1996. 506 [5] K. Sklower, B. Lloyd, G. McGregor, D. Carr, The PPP Multilink 507 Protocol (MP), RFC 1717, November 1994. 509 A. Strawman for a real-time encapsulation 511 This annex provides one possible design for a real-time encapsulation 512 (RTE). The approach chosen here is to be close to H.223 in spirit, 513 but not necessarily be fully compliant to it. Several reasons can be 514 given for this: 516 1) It is not clear that many serial chips used in current router 517 products can turn off the per-frame CRC as is required by H.223. 518 Being compatible may thus simply be impossible. 520 2) Full compliance to H.223 requires H.245, which in turn requires 521 X.691 (ASN.1 packed encoding rules or PER). Very few products 522 are available for generating PER ASN.1 encoding. H.245 is a 523 complex standard that is changing rapidly already only a few 524 months after being standardized. 526 3) H.223 is limited to 15 simultaneous table indices (see below), 527 which may be to small for even 56 kbit/s links. Extending this 528 limit would lose compliance in the general case (an extension 529 mechanism that allows compliance in the basic case is possible, 530 though). 532 4) H.223 is intended to be used over synchronous links. Much 533 initial use of RTE will be over links that are used with 534 asynchronous protocols. There is little incentive to be 535 compatible with H.223 in this case. 537 5) H.223 is standardized in the H.324 context, i.e. for use 538 directly over synchronous modem links. Today's modems generally 539 require the use of V.42 to enable HDLC-style synchronous 540 operation while connecting to asynchronous PC interfaces. It is 541 not clear to the author that consumer modems will offer a way to 542 interface to their synchronous data pumps in a way that H.223 543 can be part of a mass-market product. 545 Obviously, for each of these reasons there are quite plausible 546 counter-arguments; the author of this draft is open to suggestions. 548 A.1. Terminology 550 This document uses the following terms as in RFC 1662: 552 datagram 553 The unit of transmission in the network layer (such as IP). A 554 datagram may be encapsulated in one or more packets passed to 555 the data link layer. 557 frameThe unit of transmission at the data link layer. A frame may 558 include a header and/or a trailer, along with some number of 559 units of data. 561 packetThe basic unit of encapsulation, which is passed across the 562 interface between the network layer and the data link layer. A 563 packet is usually mapped to a frame; the exceptions are when 564 data link layer fragmentation is being performed, or when 565 multiple packets are incorporated into a single frame. 567 In addition, we use the following terms (better suggestions are 568 welcome): 570 segment 571 A part of a packet that is encapsulated as part of a frame. 573 blockA part of a frame that is used to carry a segment. 575 final block 576 A block carrying the last or only segment of a packet. 578 continued block 579 A block carrying any but the final segment of a packet. 581 A.2. Principles 583 RTE should be as close as possible to generic PPP encapsulation. 584 Frames are delimited by HDLC flags. For asynchronous operation, we 585 retain the octet-stuffing method defined in RFC1662; for synchronous 586 operation we retain bit-stuffing. 588 As an additional requirement, a PPP LCP frame (that could be sent in 589 RFC 1662 form when one peer returns to the PPP Starting state) must 590 not be confused with a valid RTE frame. Therefore, RTE is designed 591 such that no RTE frame can start with a 0xff byte (or the equivalent 592 octet-stuffed sequence). (Note that there is no need to 593 simultaneously cope with address/control field compressed packets, as 594 RTE is intended as an alternative to that PPP feature.) 596 Since on many synchronous HDLC chips the CRC generation/checking 597 cannot be switched off, a frame end imposes an overhead of at least 598 24 bits (32 if single-flag delimiting is not possible). As many 599 blocks will be very small, this is significant overhead; therefore, 600 RTE provides for more than one block to be carried in a frame. 602 To achieve maximum compression, we distinguish three types of blocks: 604 1) ``Small'' constant-size blocks from real-time flows, 606 2) ``Small'' variable-size blocks, e.g. from real-time flows, and 608 3) ``Large'' variable-size blocks, e.g. from non-real-time flows. 610 To achieve small delays, type 3 blocks can be preempted by type 1 and 611 type 2 blocks, i.e. transmission of a type 3 block can be suspended 612 to make way for a type 1 or 2 block with real-time requirements. 613 Since the need for this is generally not known at the time the type 3 614 block is started, a way is needed to unambiguously signify the end of 615 the block during its transmission; the end of the frame is used as 616 this indication. The information whether this end-of-frame condition 617 signifies the end of the final block of the packet or just the end of 618 a continued block, can be represented in one bit; this bit is packed 619 into additional header information at the start of the next frame[4]. 620 A CRC is added to packets transported in one or more type 3 blocks so 621 that incorrect reception of the continuation status can be detected. 623 The header information at the start of a frame contains an index into 624 a frame composition table. The table entry identifies the PPP 625 protocol identifiers of the blocks that are to be sent in this frame. 626 It also contains length information for the type 1 blocks. The frame 627 header is protected by a short CRC: 629 1) For links that can switch off the CRC generation (including most 630 asynchronous links), it is useful to have some protection of the 631 table index. 633 2) Even if the frame level CRC generation cannot be switched off, 634 it minimizes delay to release the contents of blocks to the 635 network layer before the end of the frame has been reached; the 636 frame header must be verified early for this to be safe. 638 The coding of the continuation bit, table index, and header CRC is 639 chosen to reserve a 0xff initial header byte to signify that the HDLC 640 frame contains RFC1662 encapsulated data instead of RTE data. 642 A.3. Example 644 This section presents a simple example scenario and some frames taken 645 from that scenario. 647 An RTE link is being used by an Internet videophone attached to an 648 asynchronous serial line. Two real-time flows have been identified 649 via RSVP: A G.723.1 audio stream of 20 byte audio units and a H.263 650 video stream of variable size video units, both encapsulated in 651 RTP/UDP/IP. 653 For this application, the data link layer peers agree to set the 654 frame composition table for this direction as follows: 656 Index Sequence 657 ------------------------------------------------------------------- 659 _________________________ 660 [4] Note that it also would be possible to define an alternative 661 closing delimiter for HDLC frames that are suspended. This would 662 be very hard to implement with most chips for synchronous HDLC, 663 but in many cases quite easy for asynchronous HDLC. Since diverg- 664 ing encapsulations for synchronous and asynchronous HDLC would be 665 a bad thing, this is not pursued further. 667 n0 type 3 block, protocol ID 0x21. 668 ------------------------------------------------------------------- 669 n1 type 1 block, compression table index 1, length 20 bytes; 670 type 3 block, protocol ID 0x21. 671 ------------------------------------------------------------------- 672 n2 type 2 block, frame delimited, compression table index 2. 673 ------------------------------------------------------------------- 674 n3 type 1 block, compression table index 1, length 20 bytes; 675 type 2 block, frame delimited, compression table index 2. 676 ------------------------------------------------------------------- 678 Note that the compression table is defined by the combined RTP and 679 UDP/IP/PPP header compression, this in turn includes a protocol ID 680 and other information about the flow being compressed. 682 All IP packets from flows other than the two specifically reserved 683 are sent with index n0. As the frame CRC is elided, the additional 684 type 3 per-packet CRC generates no additional overhead compared to a 685 normal, address and control field compressed PPP frame. 687 Each time an audio frame needs to be sent, a frame is sent with 688 header index n1. A type 3 block containing information from any 689 other IP packet can (but need not) be attached to this frame; 690 including a continuation block of a type 3 packet that was 691 interrupted to make way for the audio frame. Assuming that no CRC is 692 needed for the audio frame itself, the overhead for transmitting the 693 audio frame is at most one flag byte and one header byte; if no frame 694 needed to be interrupted, the encapsulation overhead is zero. 696 A similar procedure is used for transmitting the video packets. 698 Note that this example assumes that both type 2 and type 3 blocks are 699 terminated by a frame delimiter; for certain cases on synchronous 700 links where the CRC cannot be switched off, it may be advantageous to 701 precede type 2 blocks by a length indication. In this case, a number 702 of combinations of type 1 and type 2 blocks followed by a single type 703 3 block could be expressed by appropriate table entries without 704 additional overhead. 706 A.4. Encapsulation issues 708 1) What is the degree of H.223 compatibility required? 710 2) Are type 2 blocks really useful? 712 3) What is the stacking level of preemption that is actually 713 required? H.223 only provides for one level (the H.223 714 equivalent of a type 3 block terminates or continues the last 715 block of this type). 717 4) Are there implementations that would have trouble handing up a 718 type 1 block immediately that is followed in the same frame by a 719 long type 3 block? Are there enough implementations that would 720 not have trouble doing that that the concatenation feature is 721 worthwhile? 723 5) Would it be useful to pursue a to-be-suspended indication at the 724 end of a frame modeled on self-describing padding, i.e. using 725 special end-of-frame bytes with escapes (maybe just for 726 synchronous PPP, in combination with an alternative delimiter 727 style mechanism with asynchronous PPP)? 729 A.5. A simple approach: SRTE 731 The previous subsections outlined a way to define an encapsulation 732 similar to H.223. This section attempts to define a simpler 733 encapsulation with less functionality. 735 A.5.1. Suspending frames 737 The suspension flag is contained in the last byte of each frame 738 information field. If the byte has the value SUSPEND (TBD), the 739 frame is suspended; the byte is not part of the frame. If the byte 740 has the value TERMINATE (TBD), the frame is terminated; the byte is 741 not part of the frame. If the byte has any other value, the frame is 742 terminated; the byte is part of the fragment. (Assuming an equal 743 distribution of final bytes, the average overhead of this scheme for 744 non-suspended frames is 1/128 byte; the overhead for suspended frames 745 is 1 byte.) 747 A.5.2. Resuming frames 749 A special protocol identifier and header is used for identifying 750 blocks that resume packets. Two problems need to be solved: 752 1) Of possibly multiple suspended packets, the correct packet needs 753 to be resumed. 755 2) Loss of frames should be detected reliably. 757 The first problem can be solved by giving a ``stream number'' to each 758 packet. Only packets with different stream numbers can overtake each 759 other. A small number of streams (three or four) should be 760 sufficient. As the stream number composed of all one bits is never 761 used to reliably exclude a 0xFF first header byte, three bits are 762 reserved to carry the stream number in the SRTE header. 764 The second problem can be made less likely by sequentially numbering 765 the blocks in each stream. A high degree of safety requires a long 766 serial number or a checksum over the packet. In this subsection, we 767 will assume that a 3-bit sequence number is sufficient. 769 Together, serial and stream number will fit in slightly less than one 770 byte. 772 A.5.3. Reducing insertion overhead 774 The resumption header has one optional additional byte that indicates 775 the length of a block that is inserted in front of the packet to be 776 resumed, as well as two bits to indicate a stream number between 0 777 and 3. This reduces the overhead of insertion to the size of an SRTE 778 header. The inserted packet may be delivered immediately to the 779 network layer if the stream was negotiated to not require frame CRC 780 protection. 782 A.5.4. Reducing RTE header overhead 784 An option can be negotiated that instructs the receiver to prepend a 785 certain byte string to each packet of a particular stream. This can 786 e.g. be used to encode the PPP protocol identifier. 788 A.5.5. Resulting frame format 790 0 1 2 3 4 5 6 7 791 +---+---+---+---+---+---+---+---+ 792 | R | I | sequence | stream | 793 +---+---+---+---+---+---+---+---+ 794 : length L (if I) | stream: 795 +.......................+.......+ 796 : : 797 : Inserted packet : 798 : (length L) : 799 : : 800 +---+---+---+---+---+---+---+---+ 801 | data | 802 : : 803 +...............................+ 804 : SUSPEND/TERMINATE : 805 +---+---+---+---+---+---+---+---+ 806 | Frame | 807 | CRC | 808 +---+---+---+---+---+---+---+---+ 810 A.5.6. Information to be negotiated 812 For each of the seven streams, the following information may be 813 negotiated: 815 1) Implicitly prepended header bytes. 817 2) Immediate delivery before frame end. 819 For the whole link, SRTE needs to be negotiated before SRTE frames 820 can be sent. The use of frames starting with 0xFF indicates that the 821 peer has switched back to LCP. 823 A.6. Other approaches: The PPP multilink approach 825 One way to achieve fragmentation with the PPP suite of standards as 826 defined today is the PPP multilink protocol [5]. The multilink 827 protocol provides for sequence numbering and begin/end bits, allowing 828 big packets to be split into fragments. While the serial sequence 829 numbering does not allow suspension of a fragment being sent, it is 830 possible to send intervening packets that are not encapsulated in 831 multilink headers. 833 This is not the ideal solution for a number of reasons. First, 834 because of the single monotonically increasing serial number, there 835 is only one level of suspension: ``Big'' packets that are sent via 836 multilink can be suspended by ``small'' packets sent outside of 837 multilink; the latter are not suspendable. 839 Second, the begin/end bits are in the multilink header. To make a 840 big packet suspendable, it must be sent with the ``end'' bit off, and 841 (unless the packet was suspended a small number of bytes before its 842 end) an empty fragment has to be sent afterwards to ``close'' the 843 packet. The minimum overhead for sending a big packet thus is twice 844 the multilink header size (six bytes, including a compressed 845 multilink protocol field) plus one PPP framing (three bytes). Each 846 suspension costs another six bytes (not counting the overhead of the 847 framing for the intervening packet). 849 On the other hand, the multilink approach can be built using existing 850 standards; multilink capability is now widely deployed and only the 851 sending side needs to be aware that they are using this for giving 852 priority to real-time packets. 854 B. Interactions between real-time encapsulation and higher layers 856 It is not possible to just plug in real-time encapsulation into any 857 working PPP system. Real-time encapsulation and the ability to 858 preempt frames causes the link to no longer be strictly sequence- 859 preserving. Appropriate precautions are required for those higher- 860 layer protocols that require sequence-preserving semantics. 862 B.1. Link layer compression protocols that assume sequence-preserving 863 semantics 865 Most header and data compression protocols assume sequence-preserving 866 transmission of their frames by the PPP encapsulation. This includes 867 RFC1144 TCP/IP header compression. 869 One solution is to simply send all frames that are subject to a 870 specific kind of compression within one priority group. For RFC1144, 871 this implies using the same priority for all TCP traffic. 873 Another solution is to set up one instance of the compression 874 mechanism per priority group. This, obviously, requires cooperation 875 from the receiving end (it also has to set up multiple instances and 876 has to map priority groups to those instances). It also generally 877 requires related information to remain in one priority group; e.g., 878 for RFC1144, it will not be possible to prioritize ACKs over data. 880 A third way of handling the problem is similar to the first way, but 881 keeps track of the number of frames in transit. It is then possible 882 to increase the priority as soon as no frames from a lower priority 883 are in transit any longer. The priority can be decreased at any 884 time. 886 B.2. Multilink 888 RFC 1717 multilink requires sequence-preserving semantics. Similar 889 considerations apply as with compression protocols. An additional 890 way to handle the issue is available as RFC 1717 allows packets to be 891 sent outside the multilink; the multilink itself could be kept at one 892 priority level. 894 B.3. Network layer protocols that assume sequence-preserving semantics 896 For network layer protocols that assume sequence-preserving 897 semantics, such as the PPP bridging protocols, similar considerations 898 apply as with compression protocols. Note that the term ``related 899 information'' needs to be defined carefully. Generally, the PPP 900 protocol id will suffice to group packets this way, but multiple 901 protocol ids may need to be in one group (generally, this is true for 902 the network control protocols and the corresponding data transfer 903 protocol ids). 905 C. Strawman for a combined RTP and UDP/IP/PPP header compression 907 A header compression mechanism for ISSLOW should make use of 908 mechanisms available in RTE wherever significant performance 909 increases can be gained. 911 Generally, one would expect all IP packets to be compressed using 912 IPv6 header compression [2]. Several levels of additional 913 compression are conceivable for RTP data. 915 At the UDP/IP level, there is rarely a requirement to transmit the 916 IPv4 identification field (saving two bytes). For many applications, 917 it will also not be necessary to transmit the UDP checksum; this 918 optimization obviously needs to be selected by the application or by 919 manual configuration. 921 For regular constant-size audio data (e.g., G.723.1), it may be 922 acceptable to entirely compress away all headers for most packets; 923 only the RTP payload data for these packets would then be transmitted 924 in a type 1 block. Data from any packets that start a new talkspurt, 925 as well as any packets that occur after a packet loss, would be 926 preceded by a special block that provides a new value for timestamp 927 and sequence number. The decompressor can reconstruct the RTP 928 information by, for each block, incrementing the sequence number by 929 one and incrementing the timestamp by a negotiated frame period. 930 This requires the compressor to resequence the packets in case of 931 misordering. 933 If detection of losses on the link is desired or if the compressor 934 should not resequence the data, a single-byte modulo of the sequence 935 number can be retained[5]. 937 For video data (e.g., H.263), the RTP marker bit is used to indicate 938 end of frame; the next frame carries a different timestamp value. 939 Since packets for video generally are variable-size, there is little 940 problem in preceding them with a variable-length header that provides 941 a short modulo of the sequence number, an end-of-frame bit, and a 942 new-timestamp bit that, if on, is followed by a new timestamp value. 944 Payload types, synchronization source, contributing sources etc., as 945 well as IP/UDP level information can be negotiated in the compression 946 table and/or sent as special blocks whenever their values change (and 947 at a regular repetition rate [2]). 949 For larger multipoint conferences, it may be worthwhile to include a 950 number of IP source addresses and RTP source identifiers in the 951 compression table and include an index into this table in the 952 compressed RTP block. An equivalent effect can be achieved, at the 953 _________________________ 954 [5] Note that this would be similar in effect to the sequence 955 number option available for audio (``AL2'') data in H.223, except 956 that it would be end-to-end. 958 cost of a larger frame-composition table, by using multiple 959 compression table indices. 961 [As an internet-draft on IP/UDP/RTP compression is forthcoming, no 962 additional work has been done on this section.] 964 D. Strawman for an RSVP application announcement format 966 The main purpose of the RSVP application announcement object is to 967 give consenting peer data link layers license to apply compression 968 methods that would be catastrophic for data other than RTP. In 969 addition, any options that influence end-to-end performance aspects 970 (e.g., using reordering at compressors to save a sequence number 971 byte) should be controlled by the RSVP application announcement. 973 For certain scenarios, in particular during initial deployment, it 974 may be useful to be able to configure peer data link layer 975 implementations to apply certain heuristics to derive information 976 that otherwise would be provided in RSVP application announcements. 977 This generally should only be done near the user that might suffer if 978 these heuristics are chosen incorrectly, e.g. on the data link that 979 connects a user's PC to the Internet, giving the user the chance to 980 reconfigure the stack in case of trouble. 982 One possible way to represent information about the session to be 983 compressed beyond that available in RSVP filter specs is provided by 984 the SDP syntax.