idnits 2.17.1 draft-ietf-issll-isslow-mcml-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 (April 1999) is 9115 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 355, but not defined == Unused Reference: '4' is defined on line 414, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-issll-isslow-05 ** 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-04 Summary: 9 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: October 1999 Universitaet Bremen TZI 4 April 1999 6 The Multi-Class Extension to Multi-Link PPP 7 draft-ietf-issll-isslow-mcml-05.txt 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Abstract 32 A companion document describes an architecture for providing 33 integrated services over low-bitrate links, such as modem lines, ISDN 34 B-channels, and sub-T1 links [1]. The main components of the 35 architecture are: a real-time encapsulation format for asynchronous 36 and synchronous low-bitrate links, a header compression architecture 37 optimized for real-time flows, elements of negotiation protocols used 38 between routers (or between hosts and routers), and announcement 39 protocols used by applications to allow this negotiation to take 40 place. 42 This document proposes the fragment-oriented solution for the real- 43 time encapsulation format part of the architecture. The general 44 approach is to start from the PPP Multilink fragmentation protocol 45 [2] and provide a small number of extensions to add functionality and 46 reduce the overhead. 48 1. Introduction 50 As an extension to the ``best-effort'' services the Internet is well- 51 known for, additional types of services (``integrated services'') 52 that support the transport of real-time multimedia information are 53 being developed for, and deployed in the Internet. 55 The present document defines the fragment-oriented solution for the 56 real-time encapsulation format part of the architecture, i.e. for the 57 queues-of-fragments type sender [1]. As described in more detail in 58 the architecture document, a real-time encapsulation format is 59 required as, e.g., a 1500 byte packet on a 28.8 kbit/s modem link 60 makes this link unavailable for the transmission of real-time 61 information for about 400 ms. This adds a worst-case delay that 62 causes real-time applications to operate with round-trip delays on 63 the order of at least a second -- unacceptable for real-time 64 conversation. The PPP extensions defined in this document allow a 65 sender to fragment the packets of various priorities into multiple 66 classes of fragments, allowing high-priority packets to be sent 67 between fragments of lower priorities. 69 A companion document based on these extensions [5] defines a 70 suspend/resume-oriented solution for those cases where the best 71 possible delay is required and the senders are of type 1 [1]. 73 1.1. Specification Language 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC 2119. 79 2. Requirements 81 The main design goal for the components of an architecture that 82 addresses real-time multimedia flows over low-bitrate links is that 83 of minimizing the end-to-end delay. More specifically, the worst 84 case delay (after removing possible outliers, which are equivalent to 85 packet losses from an application point of view) is what determines 86 the playout points selected by the applications and thus the delay 87 actually perceived by the user. 89 In addition, every attempt should obviously be undertaken to maximize 90 the bandwidth actually available to media data; overheads must be 91 minimized. 93 The solution should not place unnecessary burdens on the non-real- 94 time flows. In particular, the usual MTU should be available to 95 these flows. 97 The most general approach would provide the ability to suspend any 98 packet (real-time or not) for a more urgent real-time packet, up to 99 an infinite number of levels of nesting. On the other hand, it is 100 likely that there would rarely be a requirement for a real-time 101 packet to suspend another real-time packet that is not at least about 102 twice as long. Typically, the largest packet size to be expected on 103 a PPP link is the default MTU of 1500 bytes. The smallest high- 104 priority packets are likely to have on the order of 22 bytes 105 (compressed RTP/G.723.1 packets). In the 1:72 range of packet sizes 106 to be expected, this translates to a maximum requirement of about 107 eight levels of suspension (including one level where long real-time 108 packets suspend long non-real-time packets). On 28.8kbit/s modems, 109 there seems to be a practical requirement for at least two levels of 110 suspension (i.e., audio suspends any longer packet including video, 111 video suspends other very long packets). 113 On an architectural level, there are several additional requirements 114 for the fragmentation scheme: 116 a) The scheme must be predictable enough that admission control can 117 make decisions based on its characteristics. As is argued in 118 [1], this will often only be the case when additional hints 119 about the characteristics of the flow itself are available 120 (application hints). 122 b) The scheme must be robust against errors, at least with the same 123 level of error detection as PPP. 125 c) The scheme must in general cooperate nicely with PPP. In 126 particular, it should be as compatible to existing PPP standards 127 as possible. On a link that (based on PPP negotiation) makes 128 use of the scheme, it should always be possible to fall back to 129 standard LCP without ambiguity. 131 d) The scheme must work well with existing chips and router 132 systems. (See [1] for a more extensive discussion of 133 implementation models.) For synchronous links this means using 134 HDLC framing; with much existing hardware, it is also hard to 135 switch off the HDLC per-frame CRC. For asynchronous links, 136 there is much more freedom in design; on the other hand, a 137 design that treats them much different from synchronous links 138 would lose a number of desirable properties of PPP. 140 e) The scheme must be future proof. In particular, the emergence 141 of V.80 based modems may significantly change the way PPP is 142 used with modems. 144 This document does not address additional requirements that may be 145 relevant in conjunction with Frame Relay; however, there seems to be 146 little problem in applying the principles of this document to ``PPP 147 in Frame Relay'' [3]. 149 3. Using PPP Multilink as-is 151 Transmitting only part of a packet to allow higher-priority traffic 152 to intervene and resuming its transmission later on is a kind of 153 fragmentation. The existing PPP Multilink Protocol (MP, [2]) 154 provides for sequence numbering and begin/end bits, allowing packets 155 to be split into fragments (Figure 1). 157 Figure 1: Multilink Short Sequence Number Fragment Format [2] 159 +---------------+---------------+ 160 PPP Header: | Address 0xff | Control 0x03 | 161 +---------------+---------------+ 162 | PID(H) 0x00 | PID(L) 0x3d | 163 +-+-+-+-+-------+---------------+ 164 MP Header: |B|E|0|0| sequence number | 165 +-+-+-+-+-------+---------------+ 166 | fragment data | 167 | . | 168 | . | 169 | . | 170 +---------------+---------------+ 171 PPP FCS: | FCS | 172 +---------------+---------------+ 174 (Note that the address, control, and most significant PID bytes are 175 often negotiated to be compressed away.) 177 MP's monotonically increasing sequence numbering (contiguous numbers 178 are needed for all fragments of a packet) does not allow suspension 179 of the sending of a sequence of fragments of one packet in order to 180 send another packet. It is, however, possible to send intervening 181 packets that are not encapsulated in multilink headers; thus, MP 182 supports two levels of priority. 184 The multilink-as-is approach can be built using existing standards; 185 multilink capability is now widely deployed and only the sending side 186 needs to be aware that they are using this for giving priority to 187 real-time packets. 189 3.1. Limitations of multilink as-is 191 Multilink-as-is is not the complete solution for a number of reasons. 192 First, because of the single monotonically increasing serial number, 193 there is only one level of suspension: ``Big'' packets that are sent 194 via multilink can be suspended by ``small'' packets sent outside of 195 multilink; the latter are not fragmentable (and therefore, the 196 content of one packet cannot be sent in parallel on multiple links; 197 if the packets are sent in rounds on multiple links, the order they 198 are processed at the receiver may differ from the order they were 199 sent). 201 A problem not solved by this specification is that the multi-link 202 header is relatively large; as delay bounds become small (for queues- 203 of-fragments type implementations) the overhead may become 204 significant. 206 4. Extending PPP Multilink to multiple classes 208 The obvious approach to providing more than one level of suspension 209 with PPP Multilink is to run Multilink multiple times over one link. 210 Multilink as it is defined provides no way for more than one instance 211 to be active. Fortunately, a number of bits are unused in the 212 Multilink header: two bits in the short sequence number format (as 213 can be seen in Figure 1), six in the long sequence number format. 215 This document defines (some of the) previously unused bits as a class 216 number: 218 Figure 2: Short Sequence Number Fragment Format With Classes 219 +---------------+---------------+ 220 PPP Header: | Address 0xff | Control 0x03 | 221 +---------------+---------------+ 222 | PID(H) 0x00 | PID(L) 0x3d | 223 +-+-+-+-+-------+---------------+ 224 MP Header: |B|E|cls| sequence number | 225 +-+-+-+-+-------+---------------+ 226 | fragment data | 227 | . | 228 | . | 229 | . | 230 +---------------+---------------+ 231 PPP FCS: | FCS | 232 +---------------+---------------+ 234 Each class runs a separate copy of the mechanism defined in [2], i.e. 235 uses a separate sequence number space and reassembly buffer. 237 Similarly, for the long sequence number format: 239 Figure 3: Long Sequence Number Fragment Format With Classes 241 +---------------+---------------+ 242 PPP Header: | Address 0xff | Control 0x03 | 243 +---------------+---------------+ 244 | PID(H) 0x00 | PID(L) 0x3d | 245 +-+-+-+-+-+-+-+-+---------------+ 246 MP Header: |B|E| class |0|0|sequence number| 247 +-+-+-+-+-+-+-+-+---------------+ 248 | sequence number (L) | 249 +---------------+---------------+ 250 | fragment data | 251 | . | 252 | . | 253 | . | 254 +---------------+---------------+ 255 PPP FCS: | FCS | 256 +---------------+---------------+ 258 Together with the ability to send packets without a multilink header, 259 this provides four levels of suspension with 12-bit headers (probably 260 sufficient for many practical applications) and sixteen levels with 261 24-bit headers (only four of the six free bits are used in this case 262 -- based on the rationale given above, sixteen levels should 263 generally be more than sufficient). 265 5. Prefix elision: Compressing common header bytes 267 For some applications, all packets of a certain class will have a 268 common protocol identifier (or even more than one common prefix 269 byte). In this case, the following optimization is possible: the 270 class number can be associated with a prefix of bytes that are 271 removed from each packet before transmission and that are implicitly 272 prepended to the reassembled packet after reception. 274 Note that if only some of the packets to be transmitted at a certain 275 level of priority have the common prefix, it may still be possible to 276 utilize this method by allocating two class numbers and only 277 associating one of them with the prefix. (This is the reason why 278 four of the unused bits in the long sequence number format have been 279 allocated to the class number instead of the three that generally 280 should suffice.) 282 Prefix elision is not a replacement for header compression or data 283 compression: it allows implementations to compress away prefixes that 284 often are not reachable by header or data compression methods. 286 6. Negotiable options 288 The following PPP LCP options are already defined by MP: 290 o Multilink Maximum Received Reconstructed Unit 292 o Multilink Short Sequence Number Header Format 294 o Endpoint Discriminator 296 This document defines two new LCP options: 298 o Multilink Header Format 300 o Prefix Elision 302 6.1. Multilink header format option 304 A summary of the Multilink Header Format Option format is shown 305 below. The fields are transmitted from left to right. 307 Figure 4: 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Type = 27 | Length = 4 | Code | # Susp Clses | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 This LCP option advises the peer that the implementation wishes to 315 receive fragments with a format given by the code number, with the 316 maximum number of suspendable classes (see below) given. 318 When this option is negotiated, the accepting implementation MUST 319 either transmit all subsequent multilink packets on all links of the 320 bundle with the multilink header format given or Configure-Nak or 321 Configure-Reject the option. (Note that an implementation MAY 322 continue to send packets outside of multilink in any case.) If this 323 option is offered on a link which is intended to join an existing 324 bundle, a system MUST offer the same multilink header format option 325 value previously negotiated for the bundle, or none if none was 326 negotiated previously. 328 The values defined in this document for the use of this option are: 330 - Code = 2: long sequence number fragment format with classes 332 - Code = 6: short sequence number fragment format with classes 334 The Multilink Header Format option MUST NOT occur more than once in a 335 Configure-Request or Configure-Ack, and, if it is present, the Short 336 Sequence Number Header Format option ([2]) MUST NOT also be present. 337 If no instance of this option or the Short Sequence Number Header 338 Format option is present, but an MRRU option [2] is present, then by 339 default, long sequence number multilink headers with class 0 only are 340 used; this is equivalent to code equals 2 and number of suspendable 341 classes equals 1. An instance of the Short Sequence Number Header 342 Format Option is equivalent to an instance of this option with code 343 equals 6 and number of suspendable classes equal to 1. 345 The number of suspendable classes bounds the allowable class numbers: 346 only class numbers numerically lower than this value can be used for 347 suspendable classes. Implementations MAY want to negotiate a number 348 smaller than made possible by the packet format to limit their 349 reassembly buffer space requirements. Implementations SHOULD at 350 least support the value 4 for the short sequence number fragment 351 format, and the value 8 for the long sequence number fragment format, 352 unless configured differently. Bit combinations that would indicate 353 class numbers outside the negotiated range MAY be used for other 354 semantics if negotiated by other means outside the scope of this 355 document (e.g., [6]). 357 6.2. Prefix elision option 359 This LCP option advises the peer that the implementation expects to 360 receive only packets with a certain prefix in each of the given 361 classes; this prefix is not to be sent as part of the information in 362 the fragment(s) of this class. By default, this common prefix is 363 empty for all classes. When this option is negotiated, the accepting 364 implementation MUST either transmit all subsequent multilink packets 365 of each of the given classes with the given prefix elided or 366 Configure-Nak or Configure-Reject the option. If none of the formats 367 with classes has been negotiated, class number 0 may be used to 368 indicate a common prefix for all packets sent within multilink 369 fragments. 371 Apart from the type and length octets common to all LCP options, the 372 option contains a sequence of zero or more sequences of a single- 373 octet class number, a single-octet length of the prefix for that 374 class, and the octets in that prefix: 376 Figure 5: 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Type = 26 | Option Length | Class | Prefix Length | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Prefix... | Class | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Prefix Length | Prefix... 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 The Prefix Elision option MUST NOT occur more than once in a 388 Configure-Request or Configure-Nak. If this option is offered on a 389 link which is intended to join an existing multilink bundle, a system 390 MUST offer the same prefix elision option value previously negotiated 391 for the bundle, or none if none was negotiated previously. 393 IMPLEMENTATION NOTE: as with most PPP options that indicate 394 capabilities of the receiver to the sender, the sense of this option 395 is an indication from the receiver to the sender of the packets 396 concerned. Often, only the senders will have sufficient control over 397 their usage of classes to be able to supply useful values for this 398 option. A receiver willing to accept prefix-elided packets SHOULD 399 request this option with empty content; the sender then can use 400 Configure-Nak to propose the class-to-prefix mapping desired. 402 7. References 404 [1] C. Bormann, ``Providing integrated services over low-bitrate 405 links'', Work in Progress (draft-ietf-issll-isslow-05.txt), 406 April 1999. 408 [2] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, ``The 409 PPP Multilink Protocol (MP)'', RFC 1990, August 1996 (obsoletes 410 RFC1717). 412 [3] W. Simpson, ``PPP in Frame Relay'', RFC 1973, June 1996. 414 [4] R. Andrades, F. Burg, ``QOSPPP Framing Extensions to PPP'', Work 415 in Progress (draft-andrades-framing-ext-00.txt), September 1996. 417 [5] C. Bormann, ``PPP in a real-time oriented HDLC-like framing'', 418 Work in Progress (draft-ietf-issll-isslow-rtf-04.txt), April 419 1999. 421 8. Author's address 423 Carsten Bormann 424 Universitaet Bremen FB3 TZI 425 Postfach 330440 426 D-28334 Bremen, GERMANY 427 cabo@tzi.org 428 phone +49.421.218-7024 429 fax +49.421.218-7000 431 Acknowledgements 433 David Oran suggested using PPP Multilink for real-time framing and 434 reminded the author of his earlier attempts of making Multilink more 435 useful for this purpose. The participants in a lunch BOF at the 1996 436 Montreal IETF gave useful input on the design tradeoffs in various 437 environments. The members of the ISSLL subgroup on low bitrate links 438 (ISSLOW) have helped reducing the large set of options that initial 439 versions of this specification had.