idnits 2.17.1 draft-ietf-issll-isslow-mcml-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack 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 372: '...eceived, an implementation MUST either...' RFC 2119 keyword, line 392: '...n implementation MUST NOT request a co...' RFC 2119 keyword, line 401: '... an implementation MUST either add the...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 202 has weird spacing: '...ts, or that ...' == Line 204 has weird spacing: '...for prioritiz...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1997) is 9902 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 445, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-issll-isslow-01 ** 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' == Outdated reference: A later version (-05) exists of draft-ietf-issll-isslow-rtf-00 Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Carsten Bormann 3 Expires: September 1997 Universitaet Bremen 4 March 1997 6 The Multi-Class Extension to Multi-Link PPP 7 draft-ietf-issll-isslow-mcml-01.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 A companion document describes an architecture for providing 32 integrated services over low-bitrate links, such as modem lines, ISDN 33 B-channels, and sub-T1 links [1]. The main components of the 34 architecture are: a real-time encapsulation format for asynchronous 35 and synchronous low-bitrate links, a header compression architecture 36 optimized for real-time flows, elements of negotiation protocols used 37 between routers (or between hosts and routers), and announcement 38 protocols used by applications to allow this negotiation to take 39 place. 41 This document proposes the fragment-oriented solution for the real- 42 time encapsulation format part of the architecture. The general 43 approach is to start from the PPP Multilink fragmentation protocol 44 [2] and provide a small number of extensions to add functionality and 45 reduce the overhead. 47 This document is a product of the IETF ISSLL working group. 48 Comments are solicited and should be addressed to the two working 49 groups' mailing lists at issll@mercury.lcs.mit.edu and ietf- 50 ppp@merit.edu and/or the author. 52 1. Introduction 54 As an extension to the ``best-effort'' services the Internet is well- 55 known for, additional types of services (``integrated services'') 56 that support the transport of real-time multimedia information are 57 being developed for and deployed in the Internet. 59 A companion document describes an architecture for providing 60 integrated services over low-bitrate links, such as modem lines, ISDN 61 B-channels, and sub-T1 links [1]. The main components of the 62 architecture are: a real-time encapsulation format for asynchronous 63 and synchronous low-bitrate links, a header compression architecture 64 optimized for real-time flows, elements of negotiation protocols used 65 between routers (or between hosts and routers), and announcement 66 protocols used by applications to allow this negotiation to take 67 place. 69 The present document defines the fragment-oriented solution for the 70 real-time encapsulation format part of the architecture, i.e. for the 71 queues-of-fragments type sender [1]. As described in more detail in 72 the architecture document, a real-time encapsulation format is 73 required as, e.g., a 1500 byte packet on a 28.8 kbit/s modem link 74 makes this link unavailable for the transmission of real-time 75 information for about 400 ms. This adds a worst-case delay that 76 causes real-time applications to operate with round-trip delays on 77 the order of at least a second -- unacceptable for real-time 78 conversation. The PPP extensions defined in this document allow a 79 sender to fragment the packets of various priorities into multiple 80 classes of fragments, allowing high-priority packets to be sent 81 between fragments of lower priorities. 83 A companion document based on these extensions [5] defines a 84 suspend/resume-oriented solution for those cases where the best 85 possible delay is required and the senders are of type 1 [1]. 87 2. Requirements 89 The main design goal for the components of an architecture that 90 addresses real-time multimedia flows over low-bitrate links is that 91 of minimizing the end-to-end delay. More specifically, the worst 92 case delay (after removing possible outliers, which are equivalent to 93 packet losses from an application point of view) is what determines 94 the playout points selected by the applications and thus the delay 95 actually perceived by the user. 97 In addition, every attempt should obviously be undertaken to maximize 98 the bandwidth actually available to media data; overheads must be 99 minimized. 101 The solution should not place unnecessary burdens on the non-real- 102 time flows. In particular, the usual MTU should be available to 103 these flows. 105 The most general approach would provide the ability to suspend any 106 packet (real-time or not) for a more urgent real-time packet, up to 107 an infinite number of levels of nesting. On the other hand, it is 108 likely that there would rarely be a requirement for a real-time 109 packet to suspend another real-time packet that is not at least about 110 twice as long. Typically, the largest packet size to be expected on 111 a PPP link is the default MTU of 1500 bytes. The smallest high- 112 priority packets are likely to have on the order of 21 bytes 113 (compressed RTP/G.723.1 packets). In the 1:72 range of packet sizes 114 to be expected, this translates to a maximum requirement of about 115 eight levels of suspension (including one level where long real-time 116 packets suspend long non-real-time packets). On 28.8kbit/s modems, 117 there seems to be a practical requirement for at least two levels of 118 suspension (i.e., audio suspends any longer packet including video, 119 video suspends other very long packets). 121 On an architectural level, there are several additional requirements 122 for the fragmentation scheme: 124 a) The scheme must be predictable enough that admission control can 125 make decisions based on its characteristics. As is argued in 126 [1], this will often only be the case when additional hints 127 about the characteristics of the flow itself are available 128 (application hints). 130 b) The scheme must be robust against errors, at least with the same 131 level of error detection as PPP. 133 c) The scheme must in general cooperate nicely with PPP. In 134 particular, it should be as compatible to existing PPP standards 135 as possible. On a link that (based on PPP negotiation) makes 136 use of the scheme, it should always be possible to fall back to 137 standard LCP without ambiguity. 139 d) The scheme must work well with existing chips and router 140 systems. (See [1] for a more extensive discussion of 141 implementation models.) For synchronous links this means using 142 HDLC framing; with much existing hardware, it is also hard to 143 switch off the HDLC per-frame CRC. For asynchronous links, 144 there is much more freedom in design; on the other hand, a 145 design that treats them much different from synchronous links 146 would lose a number of desirable properties of PPP. 148 e) The scheme must be future proof. In particular, the emergence 149 of V.80 based modems may significantly change the way PPP is 150 used with modems. 152 The current draft does not address additional requirements that may 153 be relevant in conjunction with Frame Relay; however, there seems to 154 be little problem in applying the principles of this draft to ``PPP 155 in Frame Relay'' [3]. 157 3. Using existing mechanisms 159 Transmitting only part of a packet to allow higher-priority traffic 160 to intervene and resuming its transmission later on is a kind of 161 fragmentation. The purpose of this section is to examine existing 162 mechanisms that are available for packet fragmentation and, by 163 relating them to the requirements listed above, to outline their 164 areas and limits of applicability. 166 Fragmentation is existing functionality of the IP layer. As 167 fragmentation and reassembly also are useful in a logical link 168 composed of multiple physical links, PPP Multilink (a standards track 169 protocol) already defines a fragmentation mechanism [2]. 170 Unfortunately, neither approach, as is, fulfills all the requirements 171 listed above. 173 3.1. Using IP fragmentation 175 An IPv4 header already contains fields that allow a large IP datagram 176 to be fragmented into small parts. A queues-of-fragments type sender 177 [1] might simply indicate a small MTU to its IP stack and thus cause 178 all larger datagrams to be fragmented down to a size that allows the 179 access delay goals to be met[1]. (Also, a PPP implementation can 180 negotiate down the MTU of its peer, causing the peer to fragment to a 181 small size, which might be considered a crude form of negotiating an 182 access delay goal with the peer system -- if that system supports 183 priority queueing at the fragment level.) 185 Unfortunately, a full, 20 byte IP header is needed for each fragment 186 (larger when IP options are used). This limits the minimum size of 187 fragment that can be used without too much overhead. (Also, the size 188 of non-final fragments must be a multiple of 8 bytes, further 189 limiting the choice.) With path MTU discovery, IP level 190 fragmentation causes TCP implementations to use small MSSs -- this 191 further increases the per-packet overhead to 40 bytes per fragment. 193 In any case, fragmentation at the IP level persists on the path 194 further down to the datagram receiver, increasing the transmission 195 overheads and router load throughout the network. With its high 196 overhead and the adverse effect on the Internet, IP level 197 fragmentation can only be a stop-gap mechanism when no other 198 fragmentation protocol is available in the peer implementation. 200 _________________________ 201 [1] This assumes that the IP stack is able to priority-tag frag- 202 ments, or that the PPP implementation is able to correlate the 203 fragments to the initial one that carries the information relevant 204 for prioritizing, or that only initial fragments can be high- 205 priority. 207 3.2. Using PPP Multilink as-is 209 The PPP Multilink Protocol (MP) provides for sequence numbering and 210 begin/end bits, allowing packets to be split into fragments. 212 Figure 1: Multilink Short Sequence Number Fragment Format [2] 214 +---------------+---------------+ 215 PPP Header: | Address 0xff | Control 0x03 | 216 +---------------+---------------+ 217 | PID(H) 0x00 | PID(L) 0x3d | 218 +-+-+-+-+-------+---------------+ 219 MP Header: |B|E|0|0| sequence number | 220 +-+-+-+-+-------+---------------+ 221 | fragment data | 222 | . | 223 | . | 224 | . | 225 +---------------+---------------+ 226 PPP FCS: | FCS | 227 +---------------+---------------+ 229 (Note that the address, control, and most significant PID bytes are 230 often negotiated to be compressed away.) 232 MP's monotonically increasing sequence numbering (contiguous numbers 233 are needed for all fragments of a packet) does not allow to suspend 234 sending a sequence of fragments of one packet for sending another 235 packet. It is, however, possible to send intervening packets that 236 are not encapsulated in multilink headers; thus, MP supports two 237 levels of priority. 239 The multilink-as-is approach can be built using existing standards; 240 multilink capability is now widely deployed and only the sending side 241 needs to be aware that they are using this for giving priority to 242 real-time packets. 244 3.3. Limitations of multilink as-is 246 Multilink-as-is is not the complete solution for a number of reasons. 247 First, because of the single monotonically increasing serial number, 248 there is only one level of suspension: ``Big'' packets that are sent 249 via multilink can be suspended by ``small'' packets sent outside of 250 multilink; the latter are not fragmentable. 252 A problem not solved by this specification is that the multi-link 253 header is relatively large; as delay bounds become small (for queues- 254 of-fragments type implementations) the overhead may become 255 significant. 257 The general approach of this document is to start from PPP Multilink 258 and provide a number of extensions to add functionality and reduce 259 the overhead of using PPP Multilink for real-time transmission. 261 4. Extending PPP Multilink to multiple classes 263 The obvious approach to providing more than one level of suspension 264 with PPP Multilink is to run Multilink multiple times over one link. 265 Multilink as it is defined provides no way for more than one instance 266 to be active. Fortunately, a number of bits are unused in the 267 Multilink header: two bits in the short sequence number format (as 268 can be seen in Figure 1), six in the long sequence number format. 270 This document defines (some of the) previously unused bits as a class 271 number: 273 Figure 2: Short Sequence Number Fragment Format With Classes 274 +---------------+---------------+ 275 PPP Header: | Address 0xff | Control 0x03 | 276 +---------------+---------------+ 277 | PID(H) 0x00 | PID(L) 0x3d | 278 +-+-+-+-+-------+---------------+ 279 MP Header: |B|E|cls| sequence number | 280 +-+-+-+-+-------+---------------+ 281 | fragment data | 282 | . | 283 | . | 284 | . | 285 +---------------+---------------+ 286 PPP FCS: | FCS | 287 +---------------+---------------+ 289 Each class runs a separate copy of the mechanism defined in [2], i.e. 290 uses a separate sequence number space and reassembly buffer. 292 Similarly, for the long sequence number format: 294 Figure 3: Long Sequence Number Fragment Format With Classes 296 +---------------+---------------+ 297 PPP Header: | Address 0xff | Control 0x03 | 298 +---------------+---------------+ 299 | PID(H) 0x00 | PID(L) 0x3d | 300 +-+-+-+-+-+-+-+-+---------------+ 301 MP Header: |B|E| class |0|0|sequence number| 302 +-+-+-+-+-+-+-+-+---------------+ 303 | sequence number (L) | 304 +---------------+---------------+ 305 | fragment data | 306 | . | 307 | . | 308 | . | 309 +---------------+---------------+ 310 PPP FCS: | FCS | 311 +---------------+---------------+ 313 Together with the ability to send packets without a multilink header, 314 this provides four levels of suspension with 12-bit headers (probably 315 sufficient for many practical applications) and sixteen levels with 316 24-bit headers (only four of the six free bits are used in this case 317 -- based on the rationale given above, sixteen levels should 318 generally be more than sufficient). 320 5. Prefix elision: Compressing common header bytes 322 For some applications, all packets of a certain class will have a 323 common protocol identifier (or even more than one common prefix 324 byte). In this case, the following optimization is possible: the 325 class number can be associated with a prefix of bytes that are 326 removed from each packet before transmission and that are implicitly 327 prepended to the reassembled packet after reception. 329 Note that if only some of the packets to be transmitted at a certain 330 level of priority have the common prefix, it may still be possible to 331 utilize this method by allocating two class numbers and only 332 associating one of them with the prefix. (This is the reason why 333 four of the unused bits in the long sequence number format have been 334 allocated to the class number instead of the three that generally 335 should suffice.) 337 Prefix elision is not a replacement for header compression or data 338 compression: it allows to compress away prefixes that often are not 339 reachable by these other methods. 341 6. Negotiable options 343 The following options are already defined by MP: 345 o Multilink Maximum Received Reconstructed Unit 347 o Multilink Short Sequence Number Header Format 349 o Endpoint Discriminator 351 This document defines two new options: 353 o Multilink Header Format 355 o Prefix Elision 357 6.1. Multilink header format option 359 A summary of the Multilink Header Format Option format is shown 360 below. The fields are transmitted from left to right. 362 Figure 4: 363 0 1 2 364 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Type = TBD | Length = 3 | Code | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 This option advises the peer that the implementation wishes to 370 receive fragments with a format given by the code number. By 371 default, long sequence number multilink headers without classes are 372 used. When this option is received, an implementation MUST either 373 transmit all subsequent multilink packets on all links of the bundle 374 with the multilink header format given or configure-NAK or configure- 375 Reject the option. 377 The values defined for the use of this option are: 379 - Neither this option nor the Short Sequence Number Header Format 380 Option (type 18) [2] is present: long sequence number fragment 381 format 383 - This option present with code = 2: long sequence number fragment 384 format with classes 386 - Short Sequence Number Header Format Option (type 18) present: 387 short sequence number fragment format 389 - This option present with code = 6: short sequence number 390 fragment format with classes 392 An implementation MUST NOT request a combination of both the Short 393 Sequence Number Header Format Option and this option. 395 6.2. Prefix elision option 397 This option advises the peer that the implementation wishes to send 398 only packets with a certain prefix in each of the given classes; the 399 prefix is not sent as part of the information in the fragment(s) of 400 this class. By default, this common prefix is empty for all classes. 401 When this option is received, an implementation MUST either add the 402 prefix given for the class to all subsequently received multilink 403 packets of each of the given classes on all links of the bundle or 404 configure-NAK or configure-Reject the option. 406 If none of the formats with classes has been negotiated, class 0 is 407 used to indicate a common prefix for all packets sent within 408 multilink fragments. 410 Figure 5: 411 0 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Type = TBD | Option Length | Class | Prefix Length | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Prefix... 417 +-+-+-+-+-+-+-+-+ 419 NOTA BENE: the sense of this option is an indication from the sender 420 to the receiver, UNLIKE most PPP options that indicate capabilities 421 of the receiver to the sender. 423 7. Acknowledgements 425 David Oran suggested using PPP Multilink for real-time framing and 426 reminded the author of his earlier attempts of making Multilink more 427 useful for this purpose. The participants in a lunch BOF at the 428 Montreal IETF gave useful input on the design tradeoffs in various 429 environments. The members of the ISSLL subgroup on low bitrate links 430 (ISSLOW) have helped reducing the large set of options that initial 431 versions of this draft had. 433 8. References 435 [1] C. Bormann, Providing integrated services over low-bitrate 436 links, work in progress (draft-ietf-issll-isslow-01.txt), 437 February 1997. 439 [2] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, ``The 440 PPP Multilink Protocol (MP)'', RFC 1990, August 1996 (obsoletes 441 RFC1717). 443 [3] W. Simpson, ``PPP in Frame Relay'', RFC 1973, June 1996. 445 [4] R. Andrades, F. Burg, ``QOSPPP Framing Extensions to PPP'', 446 September 20, 1996, Work in Progress (draft-andrades-framing- 447 ext-00.txt). 449 [5] C. Bormann, ``PPP in a real-time oriented HDLC-like framing, 450 internet Draft draft-ietf-issll-isslow-rtf-00.txt, Work in 451 Progress, March 1997. 453 9. Addresses 455 9.1. Working Group 457 The ISSLL working group can be contacted via the co-chairs, Eric 458 Crawley and John Wroclawski , 459 or via its WG mailing list . 461 9.2. Author's address 463 Carsten Bormann 464 Universitaet Bremen FB3 TZI 465 Postfach 330440 466 D-28334 Bremen, GERMANY 467 cabo@tzi.uni-bremen.de 468 phone +49.421.218-7024 469 fax +49.421.218-7000