idnits 2.17.1 draft-ietf-issll-isslow-mcml-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) 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 322: '...eceived, an implementation MUST either...' RFC 2119 keyword, line 342: '...n implementation MUST NOT request a co...' RFC 2119 keyword, line 351: '...eceived, an implementation MUST either...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 1997) is 9837 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 400, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-issll-isslow-02 ** 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-01 Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Carsten Bormann 3 Expires: November 1997 Universitaet Bremen 4 May 1997 6 The Multi-Class Extension to Multi-Link PPP 7 draft-ietf-issll-isslow-mcml-02.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 22 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 This document does not address additional requirements that may be 153 relevant in conjunction with Frame Relay; however, there seems to be 154 little problem in applying the principles of this document to ``PPP 155 in Frame Relay'' [3]. 157 3. Using PPP Multilink as-is 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 existing PPP Multilink Protocol (MP, [2]) 162 provides for sequence numbering and begin/end bits, allowing packets 163 to be split into fragments (Figure 1). 165 Figure 1: Multilink Short Sequence Number Fragment Format [2] 167 +---------------+---------------+ 168 PPP Header: | Address 0xff | Control 0x03 | 169 +---------------+---------------+ 170 | PID(H) 0x00 | PID(L) 0x3d | 171 +-+-+-+-+-------+---------------+ 172 MP Header: |B|E|0|0| sequence number | 173 +-+-+-+-+-------+---------------+ 174 | fragment data | 175 | . | 176 | . | 177 | . | 178 +---------------+---------------+ 179 PPP FCS: | FCS | 180 +---------------+---------------+ 182 (Note that the address, control, and most significant PID bytes are 183 often negotiated to be compressed away.) 185 MP's monotonically increasing sequence numbering (contiguous numbers 186 are needed for all fragments of a packet) does not allow to suspend 187 sending a sequence of fragments of one packet for sending another 188 packet. It is, however, possible to send intervening packets that 189 are not encapsulated in multilink headers; thus, MP supports two 190 levels of priority. 192 The multilink-as-is approach can be built using existing standards; 193 multilink capability is now widely deployed and only the sending side 194 needs to be aware that they are using this for giving priority to 195 real-time packets. 197 3.1. Limitations of multilink as-is 199 Multilink-as-is is not the complete solution for a number of reasons. 200 First, because of the single monotonically increasing serial number, 201 there is only one level of suspension: ``Big'' packets that are sent 202 via multilink can be suspended by ``small'' packets sent outside of 203 multilink; the latter are not fragmentable (and therefore also cannot 204 be distributed to multiple links). 206 A problem not solved by this specification is that the multi-link 207 header is relatively large; as delay bounds become small (for queues- 208 of-fragments type implementations) the overhead may become 209 significant. 211 4. Extending PPP Multilink to multiple classes 213 The obvious approach to providing more than one level of suspension 214 with PPP Multilink is to run Multilink multiple times over one link. 215 Multilink as it is defined provides no way for more than one instance 216 to be active. Fortunately, a number of bits are unused in the 217 Multilink header: two bits in the short sequence number format (as 218 can be seen in Figure 1), six in the long sequence number format. 220 This document defines (some of the) previously unused bits as a class 221 number: 223 Figure 2: Short Sequence Number Fragment Format With Classes 224 +---------------+---------------+ 225 PPP Header: | Address 0xff | Control 0x03 | 226 +---------------+---------------+ 227 | PID(H) 0x00 | PID(L) 0x3d | 228 +-+-+-+-+-------+---------------+ 229 MP Header: |B|E|cls| sequence number | 230 +-+-+-+-+-------+---------------+ 231 | fragment data | 232 | . | 233 | . | 234 | . | 235 +---------------+---------------+ 236 PPP FCS: | FCS | 237 +---------------+---------------+ 239 Each class runs a separate copy of the mechanism defined in [2], i.e. 240 uses a separate sequence number space and reassembly buffer. 242 Similarly, for the long sequence number format: 244 Figure 3: Long Sequence Number Fragment Format With Classes 246 +---------------+---------------+ 247 PPP Header: | Address 0xff | Control 0x03 | 248 +---------------+---------------+ 249 | PID(H) 0x00 | PID(L) 0x3d | 250 +-+-+-+-+-+-+-+-+---------------+ 251 MP Header: |B|E| class |0|0|sequence number| 252 +-+-+-+-+-+-+-+-+---------------+ 253 | sequence number (L) | 254 +---------------+---------------+ 255 | fragment data | 256 | . | 257 | . | 258 | . | 259 +---------------+---------------+ 260 PPP FCS: | FCS | 261 +---------------+---------------+ 263 Together with the ability to send packets without a multilink header, 264 this provides four levels of suspension with 12-bit headers (probably 265 sufficient for many practical applications) and sixteen levels with 266 24-bit headers (only four of the six free bits are used in this case 267 -- based on the rationale given above, sixteen levels should 268 generally be more than sufficient). 270 5. Prefix elision: Compressing common header bytes 272 For some applications, all packets of a certain class will have a 273 common protocol identifier (or even more than one common prefix 274 byte). In this case, the following optimization is possible: the 275 class number can be associated with a prefix of bytes that are 276 removed from each packet before transmission and that are implicitly 277 prepended to the reassembled packet after reception. 279 Note that if only some of the packets to be transmitted at a certain 280 level of priority have the common prefix, it may still be possible to 281 utilize this method by allocating two class numbers and only 282 associating one of them with the prefix. (This is the reason why 283 four of the unused bits in the long sequence number format have been 284 allocated to the class number instead of the three that generally 285 should suffice.) 287 Prefix elision is not a replacement for header compression or data 288 compression: it allows to compress away prefixes that often are not 289 reachable by these other methods. 291 6. Negotiable options 293 The following PPP LCP options are already defined by MP: 295 o Multilink Maximum Received Reconstructed Unit 297 o Multilink Short Sequence Number Header Format 299 o Endpoint Discriminator 301 This document defines two new LCP options: 303 o Multilink Header Format 305 o Prefix Elision 307 6.1. Multilink header format option 309 A summary of the Multilink Header Format Option format is shown 310 below. The fields are transmitted from left to right. 312 Figure 4: 313 0 1 2 314 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Type = TBD | Length = 3 | Code | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 This LCP option advises the peer that the implementation wishes to 320 receive fragments with a format given by the code number. By 321 default, long sequence number multilink headers without classes are 322 used. When this option is received, an implementation MUST either 323 transmit all subsequent multilink packets on all links of the bundle 324 with the multilink header format given or configure-NAK or configure- 325 Reject the option. 327 The values defined for the use of this option are: 329 - Neither this option nor the Short Sequence Number Header Format 330 Option (type 18) [2] is present: long sequence number fragment 331 format 333 - This option present with code = 2: long sequence number fragment 334 format with classes 336 - Short Sequence Number Header Format Option (type 18) present: 337 short sequence number fragment format 339 - This option present with code = 6: short sequence number 340 fragment format with classes 342 An implementation MUST NOT request a combination of both the Short 343 Sequence Number Header Format Option and this option. 345 6.2. Prefix elision option 347 This LCP option advises the peer that the implementation wishes to 348 send only packets with a certain prefix in each of the given classes; 349 this prefix is not sent as part of the information in the fragment(s) 350 of this class. By default, this common prefix is empty for all 351 classes. When this option is received, an implementation MUST either 352 add the prefix given for the class to all subsequently received 353 multilink packets of each of the given classes or configure-NAK or 354 configure-Reject the option. 356 If none of the formats with classes has been negotiated, class number 357 0 may be used to indicate a common prefix for all packets sent within 358 multilink fragments. 360 Apart from the type and length octets common to all LCP options, the 361 option contains a sequence of zero or more sequences of a class 362 number, a length of the prefix for that class, and the octets in that 363 prefix: 365 Figure 5: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Type = TBD | Option Length | Class | Prefix Length | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Prefix... 372 +-+-+-+-+-+-+-+-+ 374 NOTA BENE: the sense of this option is an indication from the sender 375 to the receiver, UNLIKE most PPP options that indicate capabilities 376 of the receiver to the sender. 378 7. Acknowledgements 380 David Oran suggested using PPP Multilink for real-time framing and 381 reminded the author of his earlier attempts of making Multilink more 382 useful for this purpose. The participants in a lunch BOF at the 1996 383 Montreal IETF gave useful input on the design tradeoffs in various 384 environments. The members of the ISSLL subgroup on low bitrate links 385 (ISSLOW) have helped reducing the large set of options that initial 386 versions of this draft had. 388 8. References 390 [1] C. Bormann, ``Providing integrated services over low-bitrate 391 links'', Work in Progress (draft-ietf-issll-isslow-02.txt), May 392 1997. 394 [2] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, ``The 395 PPP Multilink Protocol (MP)'', RFC 1990, August 1996 (obsoletes 396 RFC1717). 398 [3] W. Simpson, ``PPP in Frame Relay'', RFC 1973, June 1996. 400 [4] R. Andrades, F. Burg, ``QOSPPP Framing Extensions to PPP'', Work 401 in Progress (draft-andrades-framing-ext-00.txt), September 1996. 403 [5] C. Bormann, ``PPP in a real-time oriented HDLC-like framing'', 404 Work in Progress (draft-ietf-issll-isslow-rtf-01.txt), May 1997. 406 9. Addresses 407 9.1. Working Group 409 The ISSLL working group can be contacted via the co-chairs, Eric 410 Crawley and John Wroclawski , 411 or via its WG mailing list . 413 9.2. Author's address 415 Carsten Bormann 416 Universitaet Bremen FB3 TZI 417 Postfach 330440 418 D-28334 Bremen, GERMANY 419 cabo@tzi.uni-bremen.de 420 phone +49.421.218-7024 421 fax +49.421.218-7000