idnits 2.17.1 draft-ietf-issll-isslow-mcml-06.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 == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (June 1999) is 9082 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 419, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-issll-isslow (ref. '1') ** Obsolete normative reference: RFC 1717 (ref. '2') (Obsoleted by RFC 1990) -- No information found for draft-andrades-framing-ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Carsten Bormann 2 Expires: December 1999 Universitaet Bremen TZI 3 June 1999 5 The Multi-Class Extension to Multi-Link PPP 6 draft-ietf-issll-isslow-mcml-06.txt 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 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 [8]. 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 (PPP Link Control Protocol [6, 7]) without 129 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 limit 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, in each of the given classes, 360 the implementation expects to receive only packets with a certain 361 prefix; 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 removed from the 366 start of the packet or Configure-Nak or Configure-Reject the option. 367 If none of the formats with classes has been negotiated, class number 368 0 may be used to indicate a common prefix for all packets sent within 369 multilink 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. Security Considerations 404 Operation of this protocol is believed to be no more and no less 405 secure than operation of the PPP multilink protocol [2]. 407 8. References 409 [1] C. Bormann, ``Providing integrated services over low-bitrate 410 links'', Work in Progress (draft-ietf-issll-isslow-06.txt), 411 April 1999. 413 [2] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, ``The 414 PPP Multilink Protocol (MP)'', RFC 1990, August 1996 (obsoletes 415 RFC 1717). 417 [3] W. Simpson, ``PPP in Frame Relay'', RFC 1973, June 1996. 419 [4] R. Andrades, F. Burg, ``QOSPPP Framing Extensions to PPP'', Work 420 in Progress (draft-andrades-framing-ext-00.txt), September 1996. 422 [5] C. Bormann, ``PPP in a real-time oriented HDLC-like framing'', 423 Work in Progress (draft-ietf-issll-isslow-rtf-05.txt), April 424 1999. 426 [6] W. Simpson, Editor, ``The Point-to-Point Protocol (PPP)'', RFC 427 1661, July 1994. 429 [7] W. Simpson, Editor, ``PPP in HDLC-like Framing'', RFC 1662, July 430 1994. 432 [8] S. Bradner, ``Key words for use in RFCs to Indicate Requirement 433 Levels'', RFC 2119, March 1997. 435 9. Author's address 437 Carsten Bormann 438 Universitaet Bremen FB3 TZI 439 Postfach 330440 440 D-28334 Bremen, GERMANY 441 cabo@tzi.org 442 phone +49.421.218-7024 443 fax +49.421.218-7000 445 Acknowledgements 447 David Oran suggested using PPP Multilink for real-time framing and 448 reminded the author of his earlier attempts of making Multilink more 449 useful for this purpose. The participants in a lunch BOF at the 1996 450 Montreal IETF gave useful input on the design tradeoffs in various 451 environments. The members of the ISSLL subgroup on low bitrate links 452 (ISSLOW) have helped reducing the large set of options that initial 453 versions of this specification had.