idnits 2.17.1 draft-ietf-issll-isslow-mcml-04.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. 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 (August 1998) is 9384 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) == Missing Reference: '6' is mentioned on line 354, but not defined == Unused Reference: '4' is defined on line 413, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-issll-isslow-04 ** 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-03 Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Carsten Bormann 3 Expires: February 1999 Universitaet Bremen TZI 4 August 1998 6 The Multi-Class Extension to Multi-Link PPP 7 draft-ietf-issll-isslow-mcml-04.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), ftp.ietf.org (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 1. Introduction 49 As an extension to the ``best-effort'' services the Internet is well- 50 known for, additional types of services (``integrated services'') 51 that support the transport of real-time multimedia information are 52 being developed for, and deployed in the Internet. 54 The present document defines the fragment-oriented solution for the 55 real-time encapsulation format part of the architecture, i.e. for the 56 queues-of-fragments type sender [1]. As described in more detail in 57 the architecture document, a real-time encapsulation format is 58 required as, e.g., a 1500 byte packet on a 28.8 kbit/s modem link 59 makes this link unavailable for the transmission of real-time 60 information for about 400 ms. This adds a worst-case delay that 61 causes real-time applications to operate with round-trip delays on 62 the order of at least a second -- unacceptable for real-time 63 conversation. The PPP extensions defined in this document allow a 64 sender to fragment the packets of various priorities into multiple 65 classes of fragments, allowing high-priority packets to be sent 66 between fragments of lower priorities. 68 A companion document based on these extensions [5] defines a 69 suspend/resume-oriented solution for those cases where the best 70 possible delay is required and the senders are of type 1 [1]. 72 1.1. Specification Language 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC 2119. 78 2. Requirements 80 The main design goal for the components of an architecture that 81 addresses real-time multimedia flows over low-bitrate links is that 82 of minimizing the end-to-end delay. More specifically, the worst 83 case delay (after removing possible outliers, which are equivalent to 84 packet losses from an application point of view) is what determines 85 the playout points selected by the applications and thus the delay 86 actually perceived by the user. 88 In addition, every attempt should obviously be undertaken to maximize 89 the bandwidth actually available to media data; overheads must be 90 minimized. 92 The solution should not place unnecessary burdens on the non-real- 93 time flows. In particular, the usual MTU should be available to 94 these flows. 96 The most general approach would provide the ability to suspend any 97 packet (real-time or not) for a more urgent real-time packet, up to 98 an infinite number of levels of nesting. On the other hand, it is 99 likely that there would rarely be a requirement for a real-time 100 packet to suspend another real-time packet that is not at least about 101 twice as long. Typically, the largest packet size to be expected on 102 a PPP link is the default MTU of 1500 bytes. The smallest high- 103 priority packets are likely to have on the order of 22 bytes 104 (compressed RTP/G.723.1 packets). In the 1:72 range of packet sizes 105 to be expected, this translates to a maximum requirement of about 106 eight levels of suspension (including one level where long real-time 107 packets suspend long non-real-time packets). On 28.8kbit/s modems, 108 there seems to be a practical requirement for at least two levels of 109 suspension (i.e., audio suspends any longer packet including video, 110 video suspends other very long packets). 112 On an architectural level, there are several additional requirements 113 for the fragmentation scheme: 115 a) The scheme must be predictable enough that admission control can 116 make decisions based on its characteristics. As is argued in 117 [1], this will often only be the case when additional hints 118 about the characteristics of the flow itself are available 119 (application hints). 121 b) The scheme must be robust against errors, at least with the same 122 level of error detection as PPP. 124 c) The scheme must in general cooperate nicely with PPP. In 125 particular, it should be as compatible to existing PPP standards 126 as possible. On a link that (based on PPP negotiation) makes 127 use of the scheme, it should always be possible to fall back to 128 standard LCP without ambiguity. 130 d) The scheme must work well with existing chips and router 131 systems. (See [1] for a more extensive discussion of 132 implementation models.) For synchronous links this means using 133 HDLC framing; with much existing hardware, it is also hard to 134 switch off the HDLC per-frame CRC. For asynchronous links, 135 there is much more freedom in design; on the other hand, a 136 design that treats them much different from synchronous links 137 would lose a number of desirable properties of PPP. 139 e) The scheme must be future proof. In particular, the emergence 140 of V.80 based modems may significantly change the way PPP is 141 used with modems. 143 This document does not address additional requirements that may be 144 relevant in conjunction with Frame Relay; however, there seems to be 145 little problem in applying the principles of this document to ``PPP 146 in Frame Relay'' [3]. 148 3. Using PPP Multilink as-is 150 Transmitting only part of a packet to allow higher-priority traffic 151 to intervene and resuming its transmission later on is a kind of 152 fragmentation. The existing PPP Multilink Protocol (MP, [2]) 153 provides for sequence numbering and begin/end bits, allowing packets 154 to be split into fragments (Figure 1). 156 Figure 1: Multilink Short Sequence Number Fragment Format [2] 158 +---------------+---------------+ 159 PPP Header: | Address 0xff | Control 0x03 | 160 +---------------+---------------+ 161 | PID(H) 0x00 | PID(L) 0x3d | 162 +-+-+-+-+-------+---------------+ 163 MP Header: |B|E|0|0| sequence number | 164 +-+-+-+-+-------+---------------+ 165 | fragment data | 166 | . | 167 | . | 168 | . | 169 +---------------+---------------+ 170 PPP FCS: | FCS | 171 +---------------+---------------+ 173 (Note that the address, control, and most significant PID bytes are 174 often negotiated to be compressed away.) 176 MP's monotonically increasing sequence numbering (contiguous numbers 177 are needed for all fragments of a packet) does not allow suspension 178 of the sending of a sequence of fragments of one packet in order to 179 send another packet. It is, however, possible to send intervening 180 packets that are not encapsulated in multilink headers; thus, MP 181 supports two levels of priority. 183 The multilink-as-is approach can be built using existing standards; 184 multilink capability is now widely deployed and only the sending side 185 needs to be aware that they are using this for giving priority to 186 real-time packets. 188 3.1. Limitations of multilink as-is 190 Multilink-as-is is not the complete solution for a number of reasons. 191 First, because of the single monotonically increasing serial number, 192 there is only one level of suspension: ``Big'' packets that are sent 193 via multilink can be suspended by ``small'' packets sent outside of 194 multilink; the latter are not fragmentable (and therefore, the 195 content of one packet cannot be sent in parallel on multiple links; 196 if the packets are sent in rounds on multiple links, the order they 197 are processed at the receiver may differ from the order they were 198 sent). 200 A problem not solved by this specification is that the multi-link 201 header is relatively large; as delay bounds become small (for queues- 202 of-fragments type implementations) the overhead may become 203 significant. 205 4. Extending PPP Multilink to multiple classes 207 The obvious approach to providing more than one level of suspension 208 with PPP Multilink is to run Multilink multiple times over one link. 209 Multilink as it is defined provides no way for more than one instance 210 to be active. Fortunately, a number of bits are unused in the 211 Multilink header: two bits in the short sequence number format (as 212 can be seen in Figure 1), six in the long sequence number format. 214 This document defines (some of the) previously unused bits as a class 215 number: 217 Figure 2: Short Sequence Number Fragment Format With Classes 218 +---------------+---------------+ 219 PPP Header: | Address 0xff | Control 0x03 | 220 +---------------+---------------+ 221 | PID(H) 0x00 | PID(L) 0x3d | 222 +-+-+-+-+-------+---------------+ 223 MP Header: |B|E|cls| sequence number | 224 +-+-+-+-+-------+---------------+ 225 | fragment data | 226 | . | 227 | . | 228 | . | 229 +---------------+---------------+ 230 PPP FCS: | FCS | 231 +---------------+---------------+ 233 Each class runs a separate copy of the mechanism defined in [2], i.e. 234 uses a separate sequence number space and reassembly buffer. 236 Similarly, for the long sequence number format: 238 Figure 3: Long Sequence Number Fragment Format With Classes 240 +---------------+---------------+ 241 PPP Header: | Address 0xff | Control 0x03 | 242 +---------------+---------------+ 243 | PID(H) 0x00 | PID(L) 0x3d | 244 +-+-+-+-+-+-+-+-+---------------+ 245 MP Header: |B|E| class |0|0|sequence number| 246 +-+-+-+-+-+-+-+-+---------------+ 247 | sequence number (L) | 248 +---------------+---------------+ 249 | fragment data | 250 | . | 251 | . | 252 | . | 253 +---------------+---------------+ 254 PPP FCS: | FCS | 255 +---------------+---------------+ 257 Together with the ability to send packets without a multilink header, 258 this provides four levels of suspension with 12-bit headers (probably 259 sufficient for many practical applications) and sixteen levels with 260 24-bit headers (only four of the six free bits are used in this case 261 -- based on the rationale given above, sixteen levels should 262 generally be more than sufficient). 264 5. Prefix elision: Compressing common header bytes 266 For some applications, all packets of a certain class will have a 267 common protocol identifier (or even more than one common prefix 268 byte). In this case, the following optimization is possible: the 269 class number can be associated with a prefix of bytes that are 270 removed from each packet before transmission and that are implicitly 271 prepended to the reassembled packet after reception. 273 Note that if only some of the packets to be transmitted at a certain 274 level of priority have the common prefix, it may still be possible to 275 utilize this method by allocating two class numbers and only 276 associating one of them with the prefix. (This is the reason why 277 four of the unused bits in the long sequence number format have been 278 allocated to the class number instead of the three that generally 279 should suffice.) 281 Prefix elision is not a replacement for header compression or data 282 compression: it allows implementations to compress away prefixes that 283 often are not reachable by header or data compression methods. 285 6. Negotiable options 287 The following PPP LCP options are already defined by MP: 289 o Multilink Maximum Received Reconstructed Unit 291 o Multilink Short Sequence Number Header Format 293 o Endpoint Discriminator 295 This document defines two new LCP options: 297 o Multilink Header Format 299 o Prefix Elision 301 6.1. Multilink header format option 303 A summary of the Multilink Header Format Option format is shown 304 below. The fields are transmitted from left to right. 306 Figure 4: 307 0 1 2 3 308 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 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Type = 27 | Length = 4 | Code | # Susp Clses | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 This LCP option advises the peer that the implementation wishes to 314 receive fragments with a format given by the code number, with the 315 maximum number of suspendable classes (see below) given. 317 When this option is negotiated, the accepting implementation MUST 318 either transmit all subsequent multilink packets on all links of the 319 bundle with the multilink header format given or Configure-Nak or 320 Configure-Reject the option. (Note that an implementation MAY 321 continue to send packets outside of multilink in any case.) If this 322 option is offered on a link which is intended to join an existing 323 bundle, a system MUST offer the same multilink header format option 324 value previously negotiated for the bundle, or none if none was 325 negotiated previously. 327 The values defined in this document for the use of this option are: 329 - Code = 2: long sequence number fragment format with classes 331 - Code = 6: short sequence number fragment format with classes 333 The Multilink Header Format option MUST NOT occur more than once in a 334 Configure-Request or Configure-Ack, and, if it is present, the Short 335 Sequence Number Header Format option ([2]) MUST NOT also be present. 336 If no instance of this option or the Short Sequence Number Header 337 Format option is present, but an MRRU option [2] is present, then by 338 default, long sequence number multilink headers with class 0 only are 339 used; this is equivalent to code equals 2 and number of suspendable 340 classes equals 1. An instance of the Short Sequence Number Header 341 Format Option is equivalent to an instance of this option with code 342 equals 6 and number of suspendable classes equal to 1. 344 The number of suspendable classes bounds the allowable class numbers: 345 only class numbers numerically lower than this value can be used for 346 suspendable classes. Implementations MAY want to negotiate a number 347 smaller than made possible by the packet format to limit their 348 reassembly buffer space requirements. Implementations SHOULD at 349 least support the value 4 for the short sequence number fragment 350 format, and the value 8 for the long sequence number fragment format, 351 unless configured differently. Bit combinations that would indicate 352 class numbers outside the negotiated range MAY be used for other 353 semantics if negotiated by other means outside the scope of this 354 document (e.g., [6]). 356 6.2. Prefix elision option 358 This LCP option advises the peer that the implementation expects to 359 receive only packets with a certain prefix in each of the given 360 classes; this prefix is not to be sent as part of the information in 361 the fragment(s) of this class. By default, this common prefix is 362 empty for all classes. When this option is negotiated, the accepting 363 implementation MUST either transmit all subsequent multilink packets 364 of each of the given classes with the given prefix elided or 365 Configure-Nak or Configure-Reject the option. If none of the formats 366 with classes has been negotiated, class number 0 may be used to 367 indicate a common prefix for all packets sent within multilink 368 fragments. 370 Apart from the type and length octets common to all LCP options, the 371 option contains a sequence of zero or more sequences of a single- 372 octet class number, a single-octet length of the prefix for that 373 class, and the octets in that prefix: 375 Figure 5: 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Type = 26 | Option Length | Class | Prefix Length | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Prefix... | Class | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Prefix Length | Prefix... 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 The Prefix Elision option MUST NOT occur more than once in a 387 Configure-Request or Configure-Nak. If this option is offered on a 388 link which is intended to join an existing multilink bundle, a system 389 MUST offer the same prefix elision option value previously negotiated 390 for the bundle, or none if none was negotiated previously. 392 IMPLEMENTATION NOTE: as with most PPP options that indicate 393 capabilities of the receiver to the sender, the sense of this option 394 is an indication from the receiver to the sender of the packets 395 concerned. Often, only the senders will have sufficient control over 396 their usage of classes to be able to supply useful values for this 397 option. A receiver willing to accept prefix-elided packets SHOULD 398 request this option with empty content; the sender then can use 399 Configure-Nak to propose the class-to-prefix mapping desired. 401 7. References 403 [1] C. Bormann, ``Providing integrated services over low-bitrate 404 links'', Work in Progress (draft-ietf-issll-isslow-04.txt), 405 August 1998. 407 [2] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, ``The 408 PPP Multilink Protocol (MP)'', RFC 1990, August 1996 (obsoletes 409 RFC1717). 411 [3] W. Simpson, ``PPP in Frame Relay'', RFC 1973, June 1996. 413 [4] R. Andrades, F. Burg, ``QOSPPP Framing Extensions to PPP'', Work 414 in Progress (draft-andrades-framing-ext-00.txt), September 1996. 416 [5] C. Bormann, ``PPP in a real-time oriented HDLC-like framing'', 417 Work in Progress (draft-ietf-issll-isslow-rtf-03.txt), August 418 1998. 420 8. Author's address 422 Carsten Bormann 423 Universitaet Bremen FB3 TZI 424 Postfach 330440 425 D-28334 Bremen, GERMANY 426 cabo@tzi.org 427 phone +49.421.218-7024 428 fax +49.421.218-7000 430 Acknowledgements 432 David Oran suggested using PPP Multilink for real-time framing and 433 reminded the author of his earlier attempts of making Multilink more 434 useful for this purpose. The participants in a lunch BOF at the 1996 435 Montreal IETF gave useful input on the design tradeoffs in various 436 environments. The members of the ISSLL subgroup on low bitrate links 437 (ISSLOW) have helped reducing the large set of options that initial 438 versions of this specification had.