idnits 2.17.1 draft-ietf-issll-isslow-mcml-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-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. ** 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 a Security Considerations section. ** 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 ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 597: '... implementation MUST either transmit ...' RFC 2119 keyword, line 634: '... an implementation MUST either add the...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 251 has weird spacing: '...ts, or that ...' == Line 253 has weird spacing: '...for prioritiz...' == Line 395 has weird spacing: '...y, the distr...' == Line 398 has weird spacing: '... not be as u...' -- 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 (September 1996) is 10083 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) -- Looks like a reference, but probably isn't: 'Pid' on line 750 == Outdated reference: A later version (-06) exists of draft-ietf-issll-isslow-00 ** Downref: Normative reference to an Informational draft: draft-ietf-issll-isslow (ref. '1') ** Obsolete normative reference: RFC 1717 (ref. '2') (Obsoleted by RFC 1990) -- No information found for draft-andrades-framing-ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' Summary: 14 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Carsten Bormann 2 Expires: March 1997 Universitaet Bremen 3 September 1996 5 The Multi-Class Extension to Multi-Link PPP 6 draft-ietf-issll-isslow-mcml-00.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 A companion document describes an architecture for providing 31 integrated services over low-bitrate links, such as modem lines, ISDN 32 B-channels, and sub-T1 links [1]. The main components of the 33 architecture are: a real-time encapsulation format for asynchronous 34 and synchronous low-bitrate links, a header compression architecture 35 optimized for real-time flows, elements of negotiation protocols used 36 between routers (or between hosts and routers), and announcement 37 protocols used by applications to allow this negotiation to take 38 place. 40 This document proposes the solution for the real-time encapsulation 41 format part of the architecture. The general approach is to start 42 from the PPP Multilink fragmentation protocol [2] and provide a small 43 number of extensions to add functionality and reduce the overhead. 45 This document is a product of the IETF ISSLL working group. It is 46 also a submission to the IETF PPPEXT working group. 47 Comments are solicited and should be addressed to the two working 48 groups' mailing lists at issll@mercury.lcs.mit.edu and ietf- 49 ppp@merit.edu and/or the author. 51 1. Introduction 53 As an extension to the ``best-effort'' services the Internet is well- 54 known for, additional types of services (``integrated services'') 55 that support the transport of real-time multimedia information are 56 being developed for and deployed in the Internet. 58 A companion document describes an architecture for providing 59 integrated services over low-bitrate links, such as modem lines, ISDN 60 B-channels, and sub-T1 links [1]. The main components of the 61 architecture are: a real-time encapsulation format for asynchronous 62 and synchronous low-bitrate links, a header compression architecture 63 optimized for real-time flows, elements of negotiation protocols used 64 between routers (or between hosts and routers), and announcement 65 protocols used by applications to allow this negotiation to take 66 place. 68 The present document defines the real-time encapsulation format part 69 of the architecture. As described in more detail in the architecture 70 document, such a format is required as, e.g., a 1500 byte packet on a 71 28.8 kbit/s modem link makes this link unavailable for the 72 transmission of real-time information for about 400 ms. This adds a 73 worst-case delay that causes real-time applications to operate with 74 round-trip delays on the order of at least a second -- unacceptable 75 for real-time conversation. 77 2. Requirements 79 The main design goal for the components of an architecture that 80 addresses real-time multimedia flows over low-bitrate links is that 81 of minimizing the end-to-end delay. More specifically, the worst 82 case delay (after removing possible outliers, which are equivalent to 83 packet losses from an application point of view) is what determines 84 the playout points selected by the applications and thus the delay 85 actually perceived by the user. 87 In addition, every attempt should obviously be undertaken to maximize 88 the bandwidth actually available to media data; overheads must be 89 minimized. 91 The solution should not place unnecessary burdens on the non-real- 92 time flows. In particular, the usual MTU should be available to 93 these flows. 95 The most general approach would provide the ability to suspend any 96 packet (real-time or not) for a more urgent real-time packet, up to 97 an infinite number of levels of nesting. On the other hand, it is 98 likely that there would rarely be a requirement for a real-time 99 packet to suspend another real-time packet that is not at least about 100 twice as long. Typically, the largest packet size to be expected on 101 a PPP link is the default MTU of 1500 bytes. The smallest high- 102 priority packets are likely to have on the order of 21 bytes 103 (compressed RTP/G.723.1 packets). In the 1:72 range of packet sizes 104 to be expected, this translates to a maximum requirement of about 105 eight levels of suspension (including one level where long real-time 106 packets suspend long non-real-time packets). On 28.8kbit/s modems, 107 there seems to be a practical requirement for at least two levels of 108 suspension (i.e., audio suspends any longer packet including video, 109 video suspends other very long packets). 111 An on architectural level, there are several additional requirements 112 for the fragmentation scheme: 114 a) The scheme must be predictable enough that admission control can 115 make decisions based on its characteristics. As is argued in 116 [1], this will often only be the case when additional hints 117 about the characteristics of the flow itself are available 118 (application hints). 120 b) The scheme must be robust against errors, at least with the same 121 level of error detection as PPP. 123 c) The scheme must in general cooperate nicely with PPP. In 124 particular, it should be as compatible to existing PPP standards 125 as possible. On a link that (based on PPP negotiation) makes 126 use of the scheme, it should always be possible to fall back to 127 standard LCP without ambiguity. 129 d) The scheme must work well with existing chips and router 130 systems. For synchronous links this means using HDLC framing; 131 with much existing hardware, it is also hard to switch off the 132 HDLC per-frame CRC. For asynchronous links, there is much more 133 freedom in design; on the other hand, a design that treats them 134 much different from asynchronous links would lose a number of 135 desirable properties of PPP. 137 e) The scheme must be future proof. In particular, the emergence 138 of V.80 based modems may significantly change the way PPP is 139 used with modems. 141 The current draft does not address additional requirements that may 142 be relevant in conjunction with Frame Relay; however, there seems to 143 be little problem in applying the principles of this draft to ``PPP 144 in Frame Relay'' [3]. 146 3. Implementation models 148 This section introduces a number of terms for types of 149 implementations that are likely to emerge. It is important to have 150 these different implementation models in mind as there is no single 151 approach that fits all models best. 153 3.1. Sender types 155 There are two fundamental approaches to real-time transmission on 156 low-bitrate links: 158 Sender type 1 159 The PPP real-time framing implementation is able to control the 160 transmission of each byte being transmitted with some known, 161 bounded delay (e.g., due to FIFOs). For example, this is 162 generally true of PC host implementations, which directly access 163 serial interface chips byte by byte or by filling a very small 164 FIFO. For type 1 senders, a suspend/resume type approach will 165 be typically used: When a long frame is to be sent, the attempt 166 is to send it undivided; only if higher priority packets come up 167 during the transmission will the lower-priority long frame be 168 suspended and later resumed. This approach allows the minimum 169 variation in access delay for high-priority packets; also, 170 fragmentation overhead is only incurred when actually needed. 172 Sender type 2 173 With type 2 senders, the interface between the PPP real-time 174 framing implementation and the transmission hardware is not in 175 terms of streams of bytes, but in terms of frames, e.g., in the 176 form of multiple (prioritized) send queues directly supported by 177 hardware. This is often true of router systems for synchronous 178 links, in particular those that have to support a large number 179 of low-bitrate links. As type 2 senders have no way to suspend 180 a frame once it has been handed down for transmission, they 181 typically will use a queues-of-fragments approach, where long 182 packets are always split into units that are small enough to 183 maintain the access delay goals for higher-priority traffic. 184 There is a trade-off between the variation in access delay 185 resulting from a large fragment size and the overhead that is 186 incurred for every long packet by choosing a small fragment 187 size. 189 3.2. Receiver types 191 Although the actual work of formulating transmission streams for 192 real-time applications is performed at the sender, the ability of the 193 receiver to immediately make use of the information received depends 194 on its characteristics: 196 Receiver type 1 197 Type 1 receivers have full control over the stream of bytes 198 received within PPP frames, i.e., bytes received are available 199 immediately to the PPP real-time framing implementation (with 200 some known, bounded delay e.g. due to FIFOs etc.). 202 Receiver type 2 203 With type 2 receivers, the PPP real-time framing implementation 204 only gets hold of a frame when it has been received completely, 205 i.e., the final flag has been processed (typically by some HDLC 206 chip that directly fills a memory buffer). 208 4. Using existing mechanisms 210 Suspending the transmission of packets and resuming their 211 transmission later on is a kind of fragmentation. Fragmentation is 212 existing functionality of the IP layer. As fragmentation and 213 reassembly also are useful in a logical link composed of multiple 214 physical links, PPP Multilink (a standards track protocol) already 215 defines a fragmentation mechanism [2]. Unfortunately, neither 216 approach, as is, fulfills all the requirements listed above. 218 4.1. Using IP fragmentation 220 An IPv4 header already contains fields that allow a large IP datagram 221 to be fragmented into small parts. A queues-of-fragments type sender 222 might simply indicate a small MTU to its IP stack and thus cause all 223 larger datagrams to be fragmented down to a size that allows the 224 access delay goals to be met[1]. (Also, a PPP implementation can 225 negotiate down the MTU of its peer, causing the peer to fragment to a 226 small size, which might be considered a crude form of negotiating an 227 access delay goal with the peer system -- if that system supports 228 priority queueing at the fragment level.) 230 Unfortunately, a full, 20 byte IP header is needed for each fragment 231 (larger when IP options are used). This limits the minimum size of 232 fragment that can be used without too much overhead. (Also, the size 233 of non-final fragments must be a multiple of 8, further limiting the 234 choice.) With path MTU discovery, IP level fragmentation causes TCP 235 implementations to use small MSSs -- this further increases the per- 236 packet overhead to 40 bytes per fragment. 238 In any case, fragmentation at the IP level persists on the path 239 further down to the datagram receiver, increasing the transmission 240 overheads and router load throughout the network. With its high 241 overhead and the adverse effect on the Internet, IP level 242 fragmentation can only be a stop-gap mechanism when no other 243 fragmentation protocol is available in the peer implementation. 245 4.2. Using PPP Multilink as-is 247 The PPP Multilink Protocol (MP) provides for sequence numbering and 248 begin/end bits, allowing packets to be split into fragments. 249 _________________________ 250 [1] This assumes that the IP stack is able to priority-tag frag- 251 ments, or that the PPP implementation is able to correlate the 252 fragments to the initial one that carries the information relevant 253 for prioritizing, or that only initial fragments can be high- 254 priority. 256 Figure 1: Multilink Short Sequence Number Fragment Format [2] 258 +---------------+---------------+ 259 PPP Header: | Address 0xff | Control 0x03 | 260 +---------------+---------------+ 261 | PID(H) 0x00 | PID(L) 0x3d | 262 +-+-+-+-+-------+---------------+ 263 MP Header: |B|E|0|0| sequence number | 264 +-+-+-+-+-------+---------------+ 265 | fragment data | 266 | . | 267 | . | 268 | . | 269 +---------------+---------------+ 270 PPP FCS: | FCS | 271 +---------------+---------------+ 273 (Note that the address, control, and most significant PID bytes are 274 often negotiated to be compressed away.) 276 MP's monotonically increasing sequence numbering (contiguous numbers 277 are needed for all fragments of a packet) does not allow to suspend 278 sending a sequence of fragments of one packet for sending another 279 packet. It is, however, possible to send intervening packets that 280 are not encapsulated in multilink headers; thus, MP supports two 281 levels of priority. 283 The multilink-as-is approach can be built using existing standards; 284 multilink capability is now widely deployed and only the sending side 285 needs to be aware that they are using this for giving priority to 286 real-time packets. 288 4.3. Limitations of multilink as-is 290 Multilink-as-is is not the ideal solution for a number of reasons. 291 First, because of the single monotonically increasing serial number, 292 there is only one level of suspension: ``Big'' packets that are sent 293 via multilink can be suspended by ``small'' packets sent outside of 294 multilink; the latter are not suspendable. 296 Second, the ``end'' bit is in the multilink header, which is the 297 wrong place for suspend/resume type senders. To make a big packet 298 suspendable, it must be sent with the ``end'' bit off, and (unless 299 the packet was suspended a small number of bytes before its end) an 300 empty fragment has to be sent afterwards to ``close'' the packet. 301 The minimum overhead for sending a suspendable packet thus is twice 302 the multilink header size (six bytes, including a compressed 303 multilink protocol field) plus one PPP framing (three bytes). Each 304 suspension costs another six bytes (not counting the overhead of the 305 framing for the intervening packet). 307 Third, the multi-link header is relatively large; as delay bounds 308 become small (for queues-of-fragments type implementations) or the 309 frequency of small high-priority packets increases (for 310 suspend/resume type implementations), the overhead may become 311 significant. 313 The general approach of this document is to start from PPP Multilink 314 and provide a number of extensions to add functionality and reduce 315 the overhead of using PPP Multilink for real-time transmission. 317 5. Extending PPP Multilink to multiple classes 319 The obvious approach to providing more than one level of suspension 320 with PPP Multilink is to run Multilink multiple times over one link. 321 Multilink as it is defined provides no way for more than one instance 322 to be active. Fortunately, a number of bits are unused in the 323 Multilink header: two bits in the short sequence number format (as 324 can be seen in Figure 1), six in the long sequence number format. 326 This document defines (some of the) previously unused bits as a class 327 number: 329 Figure 2: Short Sequence Number Fragment Format With Classes 330 +---------------+---------------+ 331 PPP Header: | Address 0xff | Control 0x03 | 332 +---------------+---------------+ 333 | PID(H) 0x00 | PID(L) 0x3d | 334 +-+-+-+-+-------+---------------+ 335 MP Header: |B|E|cls| sequence number | 336 +-+-+-+-+-------+---------------+ 337 | fragment data | 338 | . | 339 | . | 340 | . | 341 +---------------+---------------+ 342 PPP FCS: | FCS | 343 +---------------+---------------+ 345 Each class runs a separate copy of the mechanism defined in [2], i.e. 346 uses a separate sequence number space and reassembly buffer. 348 Similarly, for the long sequence number format: 350 Figure 3: Long Sequence Number Fragment Format With Classes 352 +---------------+---------------+ 353 PPP Header: | Address 0xff | Control 0x03 | 354 +---------------+---------------+ 355 | PID(H) 0x00 | PID(L) 0x3d | 356 +-+-+-+-+-+-+-+-+---------------+ 357 MP Header: |B|E| class |0|0|sequence number| 358 +-+-+-+-+-+-+-+-+---------------+ 359 | sequence number (L) | 360 +---------------+---------------+ 361 | fragment data | 362 | . | 363 | . | 364 | . | 365 +---------------+---------------+ 366 PPP FCS: | FCS | 367 +---------------+---------------+ 369 Together with the ability to send packets without a multilink header, 370 this provides four levels of suspension with 12-bit headers (probably 371 sufficient for many practical applications) and sixteen levels with 372 24-bit headers (only four of the six free bits are used in this case 373 -- based on the rationale given above, sixteen levels should 374 generally be more than sufficient). 376 6. Sending the final bit at the end of the packet 378 As explained above, having the ``end'' bit within the packet header 379 causes additional overhead with suspend/resume type senders. This 380 section defines an alternative way to convey the end bit that allows 381 deferring the decision whether the fragment is final or needs to be 382 suspended to the point in time when the fragment is ended. 384 In this scheme, the value of the end bit is contained in the last 385 byte of each frame information field. If the byte has the value 386 SUSPEND (0xC3), the end bit is zero (i.e., the fragment is not the 387 last one of the packet); the byte is NOT part of the data of the 388 packet. If the byte has the value END (0xDE), the end bit is one 389 (i.e., this is the last fragment of the packet); the byte is NOT part 390 of the data of the packet. If the byte has any other value, the end 391 bit is one (i.e., this is the last fragment of the packet); the byte 392 IS part of the data of the fragment. (Assuming an equal distribution 393 of final bytes[2], the average overhead of this scheme for non- 394 _________________________ 395 [2] Actually, the distribution is not at all equal: In a trace 396 of slightly more than a million packets on a busy Ethernet, the 397 values 0xDE and 0xC3 both occurred only 244 times as the last byte 398 of a packet. Obviously, the distribution will not be as unequal 399 when data compression and/or encryption are in use. 401 suspended frames is 1/128 byte; the overhead for suspended frames is 402 exactly 1 byte.) 404 As the end bit is then no longer required in the header, the free bit 405 can be used as an additional bit for the class number in the short 406 sequence number fragment format: 408 Figure 4: Short Sequence Number Fragment Format With Classes and 409 Trailing End Bit 410 +---------------+---------------+ 411 PPP Header: | Address 0xff | Control 0x03 | 412 +---------------+---------------+ 413 | PID(H) 0x00 | PID(L) 0x3d | 414 +-+-+-+-+-------+---------------+ 415 MP Header: |B|class| sequence number | 416 +-+-+-+-+-------+---------------+ 417 | fragment data | 418 | . | 419 | . | 420 | . | 421 | ................+ 422 | . SSP/TRM (opt) : 423 +---------------+---------------+ 424 PPP FCS: | FCS | 425 +---------------+---------------+ 427 For the long sequence number fragment format, the freed bit is sent 428 as zero. 430 7. Prefix elision: Compressing common header bytes 432 For some applications, all packets of a certain class will have a 433 common protocol identifier (or even more than one common prefix 434 byte). In this case, the following optimization is possible: the 435 class number can be associated with a prefix of bytes that are 436 removed from each packet before transmission and that are implicitly 437 prepended to the reassembled packet after reception. 439 Note that if only some of the packets to be transmitted at a certain 440 level of priority have the common prefix, it may still be possible to 441 utilize this method by allocating two class numbers and only 442 associating one of them with the prefix. (This is the reason four of 443 the unused bits in the long sequence number format have been 444 allocated to the class number instead of the three that generally 445 should suffice.) 447 Prefix elision is not a replacement for header compression or data 448 compression: it allows to compress away prefixes that often are not 449 reachable by these other methods. 451 8. The compact fragment format 453 This section describes an optional multilink fragment format that is 454 more optimized towards single-link operation and frequent suspension 455 (type 1)/a small fragment size (type 2). This format has been 456 designed to retain the overall HDLC based format of frames, so that 457 existing synchronous HDLC chips and async to sync converters can be 458 used on the link. If the design can be optimized for async only 459 operation, more design alternatives are available [4]; with the 460 advent of V.80 style modems, asynchronous communications may decrease 461 in importance, though. 463 When operating over a single link, the Multilink sequence number is 464 used only for loss detection. Even a 12-bit sequence number clearly 465 is larger than required for this application on most kinds of links. 466 We therefore define a third, compact multilink header format option. 468 As, with a compact header, we can expect all packets to be sent over 469 the multilink, we can provide an additional compression mechanism for 470 this format: the MP protocol identifier is not sent with the compact 471 fragment header. This obviously requires prior negotiation (similar 472 to the way address and control field compression are negotiated), as 473 well as avoiding the bit combination 0xFF, as the start of a new LCP 474 negotiation could otherwise not be reliably detected. 476 9. Normal header: 478 Figure 5: Compact Fragment Format (Normal Header). 479 0 1 2 3 4 5 6 7 480 +---+---+---+---+---+---+---+---+ 481 | R | sequence | class | 1 | 482 +---+---+---+---+---+---+---+---+ 483 | data | 484 : : 485 +...............................+ 486 : SUSPEND/TERMINATE : 487 +---+---+---+---+---+---+---+---+ 488 | Frame | 489 | CRC | 490 +---+---+---+---+---+---+---+---+ 492 Having the last bit always be 1 helps with HDLC chips that operate 493 specially on least significant bits in HDLC addresses. 495 The R bit is the inverted equivalent of the B bit in the other 496 fragment formats, i.e. R = 1 means that this fragment resumes a 497 packet previous fragments of which have been sent already. 499 The following trick avoids the case of a header byte of 0xFF: For 500 class 7, the R bit can never be one. This means that class 7 frames 501 cannot be suspended/resumed. (This is also the reason the sense of 502 the B bit is inverted to an R bit in the compact fragment format.) 504 [[[The sequence number is not particularly useful with class 7 and 505 could be used to distinguish eight more classes -- this would add 506 complexity but also increase the usefulness of prefix elision. The 507 author currently does not see a strong requirement for this.]]] 509 10. Insertion header: 511 In many cases, when a frame is suspended, a very short frame is 512 interspersed and the suspended frame is then immediately continued. 513 In certain cases, it may be beneficial to further reduce the overhead 514 associated with this by removing the intermediate flag(s) and 515 replacing the 16-bit (or larger) CRC by a smaller CRC. 517 If the compact fragment format with insertion headers is negotiated, 518 a frame in the compact fragment format can start with the content of 519 one or more short packets, called ``insertions''. Each of these 520 packets is protected by an 8-bit CRC, computed over the insertion 521 header byte and the data part sent in the insertion. At the end of 522 the insertion, no flag is sent, but another (insertion or normal) 523 header follows immediately. The frame finally ends in a normal 524 header, data for this header, and a frame CRC that covers the entire 525 of all inserted and normal packets. Alternatively, the frame can 526 simply be ended after an inserted packet by sending the frame CRC and 527 terminating flag(s). 529 Figure 6: Compact Fragment Format (Insertion Header). 530 0 1 2 3 4 5 6 7 531 +---+---+---+---+---+---+---+---+ 532 | length L | C | 0 | 533 +---+---+---+---+---+---+---+---+ 534 : : 535 : Inserted packet : 536 : (length L) : 537 : : 538 +---+---+---+---+---+---+---+---+ 539 | 8-bit CRC | 540 +---+---+---+---+---+---+---+---+ 541 | next header | 542 : (insertion or normal) : 543 : (possibly repeated) : 544 +---+---+---+---+---+---+---+---+ 545 | Frame CRC (covering all | 546 | all data between the flags) | 547 +---+---+---+---+---+---+---+---+ 549 The class number of a packet in the insertion is computed from the C- 550 bit as ``class = C + 8'', i.e., we reserve classes 8 and 9 for 551 inserted packets. As an example, one could use class number 8 for 552 compressed RTP (saving one or two additional bytes with prefix 553 elision) and 9 for any other packet type. (Note that, as with class 554 7, classes 8 and 9 cannot be suspended, as there is no way to 555 indicate suspension or resumption.) 557 Since not all serial hardware can immediately deliver initial parts 558 of frames that have not yet completely arrived (see ``type 2 559 receivers'' in section 3 above), the use of the insertion header may 560 be counter-productive in achieving latency goals; it therefore can be 561 negotiated separately from the use of the normal compact header.. 562 Also, because the initial byte of the HDLC frame has a zero LSB, this 563 format may not be applicable if chips are used that do strange things 564 with the last bit of address field bytes. 566 Implementation note: A sender should not send too many insertions 567 before a normal header fragment in one frame, as the overall 568 reliability of the actual data part of the frame (as indicated by the 569 frame CRC) suffers. 571 11. Negotiable options 573 The following options are already defined by MP: 575 o Multilink Maximum Received Reconstructed Unit 577 o Multilink Short Sequence Number Header Format 579 o Endpoint Discriminator 581 11.1. Multilink header format option 583 A summary of the Multilink Header Format Option format is shown 584 below. The fields are transmitted from left to right. 586 Figure 7: 587 0 1 2 588 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Type = TBD | Length = 3 | Code | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 This option advises the peer that the implementation wishes to 594 receive fragments with a format given by the code number. By 595 default, long sequence number multilink headers without classes and 596 the end bit in the header are used. When this option is received, an 597 implementation MUST either transmit all subsequent multilink packets 598 on all links of the bundle with the multilink header format given or 599 configure-NAK or configure-Reject the option. 601 The value defined for code are: 603 - 0 or option not present: long sequence number fragment format 605 - 2: long sequence number fragment format with classes 607 - 3: long sequence number fragment format with classes and 608 trailing end bit 610 - 4 or Short Sequence Number Header Format Option (type 18) 611 present: short sequence number fragment format 613 - 6: short sequence number fragment format with classes 615 - 7: short sequence number fragment format with classes and 616 trailing end bit 618 - 11: compact fragment format (always with classes and trailing 619 end bit) with normal header only 621 - 15: compact fragment format (always with classes and trailing 622 end bit) with normal and insertion headers 624 [[[Note for further discussion: The number of alternatives is too 625 large. The variations possible should be restricted to have a good 626 chance that two peer implementations have one option in common.]]] 628 11.2. Prefix elision option 630 This option advises the peer that the implementation wishes to send 631 only packets with a certain prefix in each of the given classes; the 632 prefix is not sent as part of the information in the fragment(s) of 633 this class. By default, this common prefix is empty for all classes. 634 When this option is received, an implementation MUST either add the 635 prefix given for the class to all subsequently received multilink 636 packets of each of the given classes on all links of the bundle or 637 configure-NAK or configure-Reject the option. 639 If one of the formats with classes has not been negotiated, class 0 640 is used to indicate a common prefix for all packets sent within 641 multilink fragments. 643 Figure 8: 644 0 1 2 3 645 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Type = TBD | Option Length | Class | Prefix Length | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Prefix... 650 +-+-+-+-+-+-+-+-+ 651 Note that the sense of this option is an indication from the sender 652 to the receiver, unlike most PPP options that indicate capabilities 653 of the receiver to the sender. 655 12. Acknowledgements 657 David Oran suggested using PPP Multilink for real-time framing and 658 reminded the author of his earlier attempts of making Multilink more 659 useful for this purpose. The participants in a lunch BOF at the 660 Montreal IETF gave useful input on the design tradeoffs in various 661 environments. 663 13. References 665 [1] C. Bormann, Providing integrated services over low-bitrate 666 links, work in progress (draft-ietf-issll-isslow-00.txt), June 667 1996. 669 [2] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, ``The 670 PPP Multilink Protocol (MP)'', RFC 1990, August 1996 (obsoletes 671 RFC1717). 673 [3] W. Simpson, ``PPP in Frame Relay'', RFC 1973, June 1996. 675 [4] R. Andrades, F. Burg, ``QOSPPP Framing Extensions to PPP'', 676 September 20, 1996, Work in Progress (draft-andrades-framing- 677 ext-00.txt). 679 14. Addresses 681 14.1. Working Group 683 The ISSLL working group can be contacted via the co-chairs, Eric 684 Crawley and John Wroclawski , 685 or via its WG mailing list . 687 14.2. Author's address 689 Carsten Bormann 690 Universitaet Bremen FB3 TZI 691 Postfach 330440 692 D-28334 Bremen, GERMANY 693 cabo@informatik.uni-bremen.de 694 phone +49.421.218-7024 696 A. Benchmarks 698 For the following considerations, we will define the ``normal'' PPP 699 header overhead to be four bytes: one byte of protocol identifier 700 (assuming address and control field compression as well as the use of 701 protocols that have protocol identifiers that can be compressed to 702 one byte), two bytes of CRC and one byte of flag. These assumptions 703 are not entirely accurate, as the protocol identifier and the CRC are 704 subject to bit- or octet-stuffing, slightly increasing the overhead. 705 In addition, many of the synchronous serial chips used today cannot 706 easily output frames that are delimited by only a single flag byte. 708 Just sending two packets sequentially using standard encapsulation 709 thus costs 8 bytes: 711 Pid1 . . . 2*CRC Flag Pid2 . . . 2*CRC Flag 713 Basic 12-bit multilink adds 3 bytes of header overhead to each 714 packet, as well as six bytes (the same three bytes plus four bytes 715 normal PPP overhead, minus the protocol identifier) to each 716 additional fragment. 718 MPPid 2*MPH Pid . . . 2*CRC Flag 719 Pid . . . 2*CRC Flag 720 MPPid 2*MPH . . . 2*CRC Flag 722 Being able to insert a real-time frame into a long packet 723 encapsulated in basic multilink therefore requires 9 more bytes of 724 overhead than just sending the two packets sequentially using 725 standard encapsulation. The six-byte overhead will generally recur 726 for longer packets, as the final bit is in the packet header and thus 727 at least one additional fragment (zero length, just to carry the 728 final bit) is required. 730 12-bit multilink with classes does not change the overhead at the top 731 level of priorities, unless the header prefix option is used and is 732 useful (i.e., only a small number of PPP protocol identifiers is in 733 use). In that case, 1 byte of overhead is saved per low-priority 734 packet. 736 The compact header reduces the additional per-packet overhead to 1 737 byte (or 0 bytes if the header prefix option is effective). The 738 total additional overhead for the insertion of a real-time frame thus 739 is only 6 to 4 bytes, if the special insertion header cannot be used. 741 NH [Pid] . . . 2*CRC Flag 742 NH [Pid] . . . 2*CRC Flag 743 NH . . . 2*CRC Flag 745 If the insertion header can be used, the additional overhead is 746 reduced by two more bytes, i.e., 4 to 2 bytes (of which one is the 747 block check byte). 749 NH [Pid] . . . 2*CRC Flag 750 IH [Pid] . . . 1*CRC NH . . . 2*CRC Flag 752 H.223 achieves even better numbers by using a per-packet CRC only (2 753 bytes saved) and, in the best case that the inserted packet is of a 754 repetitive length that has been defined in the multiplex table, a 755 common header for both elements of the second frame (1 more byte 756 saved). The first saving does not seem to be practical with many 757 current synchronous chips (although it could be made an option, in 758 particular for asynchronous applications -- some way would have to be 759 found to protect the compact header then, though); the second saving 760 is dubious in a more dynamic, multiple-packet-stream environment. 762 B. Usage Scenarios 764 Scenario: Two low-bitrate links are in the path between two internet 765 telephones that use G.723.1 compression for 20 byte audio packets (as 766 per G.723.1), with C-RTP headers of 2 bytes. These are repeated 767 every 30 ms. 769 To simplify the calculations, background traffic consists of a 770 continuous, infinite length packet. For packet size distributions 771 found in actual use, the resulting numbers would be more favorable to 772 compact headers. 774 For the compact header, the PPP overhead is four bytes; for insertion 775 headers, it is two bytes; in both cases, any packet that was 776 interrupted needs to be resumed with an additional overhead of four 777 bytes. For the 12-bit header without classes, the PPP overhead for 778 the audio frames also is four bytes; the overhead per fragment of 779 other data is six bytes. 781 As an rather lenient performance requirement, we allow a round-trip 782 delay budget of 300 ms (note that investigations show that this delay 783 already significantly reduces the mean opinion score). Of the 150 ms 784 available per path, 70 ms are reserved for delays in the rest of the 785 path, so 40 ms is the delay budget per link; we neglect transmission 786 delays. (If better values than 70 ms in the network become 787 realistic, it is likely that one would want to reduce the overall 788 delay instead of allocating more of it to the low-speed links). 790 B.1. GSM Scenario (9600 bit/s) 792 We assume a transparent, full-duplex 9600 bit/s link as could be 793 found on a full rate traffic channel in the GSM mobile phone system. 794 For these considerations, we ignore the additional delays that are 795 encountered in the air interface and its interleaving mechanisms. 797 At 1200 bytes per second, a maximum of 36 bytes can be transmitted 798 per 30 ms; note that for 22 bytes of payload at 1200 byte/s, about 20 799 ms of the 40 ms delay budget are already taken for the actual sending 800 of the packet. A regular fragmentation schedule would therefore have 801 to operate in 20 ms units, at about 24 bytes per fragment (of which 802 six are taken for fragmentation overhead -- an efficiency of about 75 803 %). At 1200 bytes per second, the load during a talkspurt is 26/1200 804 seconds every 30 ms, i.e., 22 ms every 30 ms; the capacity remaining 805 for data is about 170 byte/s. 807 It is obvious that an efficient fragmentation mechanism is required 808 to allow significant data to flow during talkspurts. With insertion 809 headers, the overhead per packet can be limited to 6 bytes, leaving 810 room for 8 bytes of actual data per 30 ms, or 270 byte/s. 812 Note that, as the access delay is very small with a suspend/resume 813 mode, part of the delay budget could be used by the application for 814 assembling two G.723.1 frames into one packet (at 40 + 2 C-RTP 815 bytes); there is then room for 24 bytes of non-audio data per 60 ms, 816 or 400 byte/s. 818 B.2. V.34 Modem scenario (24000 to 28800 bit/s) 820 We assume a link speed of 3000 byte/s as not all V.34 modem 821 communication reaches the full speed of 3600 byte/s (28800 bit/s). 822 At this speed, the transmission of 22 bytes of audio payload takes 823 about 8 ms, so about 32 ms of the 40 ms link delay budget is 824 available for access delay. With a regular fragmentation schedule 825 based on 12-bit headers, this allows a fragment size of 90 bytes plus 826 6 bytes of fragment overhead, i.e. about 7 % loss due to 827 fragmentation. As 26 out of the 90 bytes that can be sent in 30 ms 828 are used for the audio packets, an average of 64/96 such 90 byte 829 fragments can be sent per 30 ms, leading to a remaining data 830 throughput of about 2000 byte/s. 832 With compact headers (including the insertion option) and 833 suspend/resume operation, the audio information can be sent using 834 only two bytes of overhead per audio packet, leaving 66 of the 90 835 bytes that can be sent in 30 ms to data packets, of which four bytes 836 is lost to PPP overhead, resulting in a remaining data throughput of 837 about 2070 byte/s. If the application makes use of the reduced 838 jitter of suspend/resume by combining two audio packets into one, 136 839 of 180 bytes that can be sent in 60 ms are available to data packets, 840 of which, again, four bytes is lost to PPP overhead, resulting in a 841 remaining data throughput of about 2200 byte/s. 843 B.3. ISDN scenario (56000 to 64000 bit/s) 845 We assume a link speed of 7000 (US) to 8000 (non-US) byte/s. For a 846 regular fragmentation schedule, similar calculations lead to a 847 fragment size of 260 to 300 bytes, for about 2 % of fragmentation 848 overhead. The approximate numbers resulting for remaining data 849 throughput, based on 64 kbit/s (8000 byte/s) are: 7000 byte/s for a 850 regular schedule of 300 byte fragments, 7070 byte/s for compact 851 headers, and 7200 byte/s for compact headers making use of double 852 size packets.