idnits 2.17.1 draft-ietf-issll-framing-ext-00.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-19) 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 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. ** There are 63 instances of lines with control characters in the document. ** 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 127: '...amming interface (API) MUST provide an...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 604 has weird spacing: '...e order from...' -- 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 (November 26, 1996) is 10006 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: '3' is defined on line 887, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 890, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-issll-isslow-00 ** Downref: Normative reference to an Informational draft: draft-ietf-issll-isslow (ref. '5') == Outdated reference: A later version (-06) exists of draft-ietf-issll-isslow-mcml-00 -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 1700 (ref. '8') (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Andrades 2 INTERNET DRAFT isochrone, Inc. 3 Document: draft-ietf-issll-framing-ext-00.txt F. Burg 4 Expires: May 25, 1997 AT&T 5 November 26, 1996 7 QOSPPP Framing Extensions to PPP 8 (draft-ietf-issll-framing-ext-00.txt) 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are 13 working documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as ``work in 21 progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Distribution of this document is unlimited. 31 Abstract 33 The Point-to-Point Protocol (PPP) [2] provides a standard method for 34 transporting multi-protocol datagrams over point-to-point links. 35 PPP datagrams are often encapsulated in HDLC frames [1] when used 36 over standard analog modems. 38 This document describes the extensions to PPP encapsulation and 39 HDLC framing to support Quality of Service (QoS) over low bandwidth 40 links. 42 This document is a submission to the IETF ISSLL working group. 43 Comments are solicited and should be addressed to the working 44 group's mailing list at issll@mercury.lcs.mit.edu and/or the author. 46 This document is an update of the previous version which was named 47 "draft-andrades-framing-ext-00.txt" and was revised as a result of 48 discussions with Carsten Bormann, as well as the discussions at the 49 September 30th meeting of the ISSLL working group. 51 Table of Contents 53 1. Introduction...............................................3 54 2. Current Implementation ....................................3 55 2.1 QOSPPP Extensions to HDLC framing........................3 56 2.2 QOSPPP Extensions to PPP encapsulation...................7 57 2.3 QOSPPP Extensions to Link Establishment Protocol.........7 58 2.4 UDP header compression...................................8 59 2.5 Planned QOSPPP Features..................................8 60 3. Comparison with other proposals...........................10 61 4. Conclusions...............................................20 62 5. Security Considerations...................................20 63 6. Acknowledgments...........................................20 64 7. References................................................21 65 8. Author's Address..........................................21 67 1. Introduction 69 QOSPPP provides an architectural framework for providing multimedia 70 and other advanced services, requiring QoS over the Internet. Our 71 current work is aimed at the consumer market which usually uses 72 comparatively low bandwidth analog modems for Internet access. The 73 links from the consumer's residences to their Internet Service 74 Providers usually run the PPP protocol [2] encapsulated in 75 asynchronous HDLC frames [1], and so our goal was to add QoS to 76 this framing scheme. The current document describes our attempt to 77 extend the PPP encapsulation in asynchronous HDLC framing to 78 support QoS over these links. One goal was to maintain as much 79 compatibility as possible with current PPP implementations and to 80 fall back to the standard PPP/HDLC framing scheme if we detect that 81 the extensions are not available on the peer. The framework also 82 included a signalling engine which is used to negotiate parameters 83 for the QoS connections, and a packet scheduler which contains 84 the actual scheduling algorithms. The signalling protocol could be 85 Q.2931 or RSVP or a variant of one of these. The term QOSPPP is 86 used to refer to the entire framework and not just the framing. 87 The complete QOSPPP architecture will be described in more detail 88 in a future document. 90 Several Internet Services Providers still offer SLIP connections; 91 however, we felt that this would very soon be obsolete and did not 92 attempt to address it. At this stage we have not attempted to work 93 out the framing extensions for synchronous HDLC, since it is not 94 used in the market we are addressing; however, we feel that the 95 current work can easily be adapted to that area. 97 Section 2 describes the current implementation and work in progress. 98 Section 3 compares this framing scheme with those [5,6] proposed by 99 Carsten Bormann. Section 4 considers merging the features of QOSPPP 100 with [6]. 102 2. Current Implementation 104 2.1 QOSPPP Extensions to HDLC framing 106 The aim of QOSPPP is to allow a customer to run a mix of 107 applications with varying communications needs. Currently most PPP 108 implementations offer a single class of service, best-effort, which 109 is most suited for conventional data applications (e.g. Telnet, ftp, 110 WWW, email). However, newer Internet applications such as packet 111 telephony, video conferencing, etc. require a new class of service 112 with bandwidth guarantees and upper bounds of the delay and jitter 113 seen by their packets. 115 QOSPPP supports four classes of service, ABR, UBR, CBR and VBR. We 116 use these terms in the same sense as defined by the ATM Forum [7]. 117 However, the basic concepts are the same for any other definition 118 of class of service. 120 ABR or Available Bit Rate supports traditional data applications, 121 which do not need bandwidth guarantees, nor any strict bounds on 122 their delay and jitter. They typically have variable sized packets. 123 However, ABR applications ARE QoS aware and will specify their 124 maximum datagram size, expected bandwidth usage, and maximum 125 tolerable delays. The class of service is specified in the flowspec 126 along with other parameters like bandwidth, delay and jitter. 127 The application programming interface (API) MUST provide an 128 interface by which the flowspec can be communicated by the 129 application to the transport stack, but this is out of the scope of 130 this document. While the network does not guarantee the latter 131 two, it does use them to estimate buffer sizes and expected load. 132 UBR or Unspecified Bit Rate is for legacy applications that are not 133 QoS aware. ABR and UBR are equivalent to the framing layer and so 134 are both referred to as ABR for the remainder of this document. 136 CBR or Constant Bit Rate is for applications that transmit data at 137 regular intervals. The datagrams are usually small and of fixed 138 length (though the latter is not a requirement). An example is a 139 packet phone which does not do silence detection. They do have 140 strict upper bounds on the delay and jitter they can tolerate as 141 well as strict bandwidth requirements. VBR or Variable Bit Rate is 142 similar to CBR, except that the rate of packet transmission is not 143 fixed. The transmission rate may vary upto a maximum rate, and it 144 also defines a long term average rate. CBR and VBR are equivalent 145 to the framing layer and so are both referred to as QoS streams 146 for the remainder of this document. 148 The framing layer then has to support two classes of datagrams, 149 normal data applications and QoS. Most of this support is done by a 150 packet scheduler and signalling engine at a layer higher than the 151 framing layer, and so will not be discussed in this document. 152 However, one aspect of QoS that is strongly influenced by the 153 framing layer is the delay bounds of QoS streams. This is because 154 the delay allowance of QoS streams tends to be in the range of tens 155 of milliseconds. However, several popular data applications (e.g. 156 WWW traffic) tend to use large size packets since they are more 157 efficient. On a 28,800 link, a 1500 byte packet (which is the MTU 158 used by most PPP implementations, and many data applications use 159 the MTU) takes approximately half a second to transmit, making the 160 link unavailable for that time. (In practice, the bandwidth 161 available with a 28,800 modem is often less than 28,800, depending 162 on the line conditions.) This clearly indicates that in order to 163 support QoS streams on low bandwidth links, some change in the 164 standard PPP framing is required. One possible way to handle it 165 would be to use a much smaller MTU. However, in order to support 166 delay bounds of around 20 ms for QoS streams, it would be necessary 167 to restrict the MTU of ABR traffic to around 36 bytes, which is 168 clearly unacceptable. 170 Another approach (which is what QOSPPP does) is to allow an ABR 171 datagram that is currently being transmitted to be preempted by a 172 QoS stream with stricter delay bounds. When the QoS packet is 173 complete, the preempted ABR datagram will resume transmission. The 174 difference between preemption and conventional fragmentation is 175 that each resuming segment of the ABR datagram does NOT carry a 176 header telling the receiving end how to put the pieces back 177 together again. The preemption is indicated by stuffing a 178 preemption flag byte which is defined as 0x7c. The end of 179 preemption is indicated by transmitting a standard HDLC Flag byte. 180 When preemption ends, the interrupted frame is automatically 181 resumed at the point where it was suspended, with no extra header 182 bytes. The current implementation supports a single level of 183 preemption, however we are planning a new version with support for 184 multiple levels of preemption, see section 2.5. 186 In this document we use the terms priority and preemption class 187 interchangeably although that may not be the common usage. 189 The preemption is explained by the following diagram. Assume that 190 there are two active streams, a TCP stream (maybe a Web browser) 191 which is ABR, and a voice stream (the latter for a packet phone 192 application) which is CBR (or VBR if silence detection is 193 implemented). Initially, in the absence of any voice data, the 194 framer begins transmission of a packet of the TCP stream. After 195 some time, a voice packet is queued for transmission and the 196 framer suspends transmission of the TCP stream to begin sending 197 the voice packet. When transmission of the voice packet is 198 complete, the framer resumes transmission of the suspended TCP 199 packet. Note that one voice packet can not interrupt another 200 voice packet. The payload size of the voice packet (16 bytes in 201 the example), depend on the encoding algorithm used. Also note 202 that each FCS in the following diagram protects only the frame 203 it is a part of, (the one that is terminated by the HDLC Flag byte 204 immediately after the FCS), and not any intermediate (preempting) 205 frames, Each stream can negotiate the use of an FCS of a different 206 strength (size). The new Suspend Flag byte needs to be added to the 207 ACCM for transparency. Note that in the diagram, and elsewhere in 208 this document, the term PID always refers to the PPP protocol ID. 210 Preempted packet - (starts earlier in time) 211 --------------------------- - - - ----------------------------- 212 |HDLC |IP PID | TCP data \ \ TCP data |FCS |HDLC | 213 |Flag |0x21 | \ \ (contd.)|(2 bytes) |Flag | 214 |0x7e | | \ \ | |0x7e | 215 ------------------------------ - - - -------------------------- 216 Suspend Resume 217 / \ 218 / \ 219 / \ 220 / \ 221 / \ 222 / Preempting packet \ 223 / (Starts later in time - \ 224 / completes earlier) \ 225 ---------------------------------------- 226 |Suspend |CBR |Voice data|FCS |HDLC | 227 |Flag |PID | 16 bytes |(0 or 2|Flag | 228 |0x7c | | | bytes)|0x7e | 229 ---------------------------------------- 231 As can be seen from the preceding diagram, the preempting packet's 232 frame format is the same as the standard PPP frame except for the 233 use of a new Suspend Flag (0x7c) instead of the HDLC Flag (0x7e). 235 One other difference is that the length of the FCS field can be 236 different for different PIDs. PPP currently defines three different 237 FCS', 16-bit, 32-bit and NULL FCS. We use the 16-bit FCS for all 238 data streams (it is the default anyway). The NULL FCS can be 239 negotiated for CBR streams that have a small MTU by the signalling 240 engine. However, this choice, if desired, must be made by the 241 application. The interface by which the application may negotiate 242 the choice of an FCS is out of the scope of this document. In 243 any examples in this document, the length of the FCS shown is just 244 for illustration. 246 In the special case, when we have only a single active QoS stream, 247 we omit sending the CBR PID in preempting frames, since it is 248 implicit from the Suspend Flag, and reduces the Framing overhead 249 by a byte. 251 2.2 QOSPPP Extensions to PPP encapsulation 253 All CBR and VBR streams are each assigned a unique PPP protocol ID 254 (PID) by the signalling engine. These PID values are taken from 255 the unused values as specified in [8]. We plan to get a range of 256 these unused PIDs allocated for this purpose. Unlike the PIDs 257 currently assigned to protocols by the IETF, the PIDs used by 258 QOSPPP are not necessarily the same in both directions, because 259 of the way the signalling engine works. We try to pick the PIDs 260 from the 1-byte PID space (and since we do not expect too many 261 streams to be simultaneously active over these low bandwidth 262 links, it isn't difficult to find enough 1-byte PIDs). 264 2.3 QOSPPP Extensions to Link Establishment Protocol 266 PPP uses the Link Control Protocol (LCP) [2] to establish 267 parameters for the link. Up-to-date values of the LCP Code field 268 are specified in the most recent "Assigned Numbers" RFC [8]. 270 QOSPPP adds the following configuration option: 272 -------------------------------------------------------- 273 |Option | Length | version | Preemptive | Link Speed | 274 |0x55 | = 8 | (4 bytes) | scheduling | Monitoring | 275 | | | | (1 byte) | (1 byte) | 276 -------------------------------------------------------- 278 Option: This is a new LCP configuration option code value. 280 Version: This field is currently set to 1. Future versions 281 may set this field to other values to indicate other 282 preemption schemes. 284 Preemptive scheduling: This is set to 0 to indicate that QoS 285 streams are not currently supported (even though the peer 286 apparently is QOSPPP-enabled). The current QOSPPP framing uses a 287 value of 1 in this field. In the future, we plan to use this field 288 to indicate the number of levels of preemption supported 289 (Currently it is one level). 291 Link Speed Monitoring: This is currently set to 0 to indicate 292 that Link Speed Monitoring is not required. The purpose of 293 Link Speed Monitoring is to enable an implementation to track 294 changes in the link bandwidth and adjust it's packet scheduling 295 accordingly. No protocol has yet been defined for Link Speed 296 Monitoring. 298 The node at one end sends a configuration message indicating that 299 it supports preemption, and the maximum number of preemption levels 300 it supports. If the other node responds with a reject (i.e. it is 301 a non QoS-aware implementation and does not recognize the new LCP 302 option code), then the sender will disable the preemption 303 capability and send a new configuration message without the 304 preemption option (and disable the preemption feature locally for 305 the current session). If the other side responds with a NAK 306 requesting a smaller number of levels of preemption, we will 307 adjust our behavior accordingly and resend the configuration 308 message reflecting the requested changes. 310 2.4 UDP header compression 312 QOSPPP uses UDP header compression. This consists of not 313 transmitting the UDP and IP headers of any packet that is 314 associated with a specific PID. The receiver automatically prepends 315 the UDP & IP headers to every incoming packet.The information needed 316 for the headers is transmitted when the PID is negotiated by the 317 signalling engine (the checksum can be generated by the receiver 318 on the reconstructed received packet - or we can use the 319 optimization of setting the checksum to 0). Carsten proposes prefix 320 elision [6] which is basically associating each class or PID with a 321 prefix of bytes that begin every packet belong to that class or PID 322 and then not transmitting those bytes. The receiver automatically 323 prepends the prefix to every packet it receives. UDP header 324 compression gives better reduction in overhead than prefix elision 325 for UDP streams. It does not handle non-UDP streams, but we assume 326 Van Jacobson does a fairly good job at that. Are there other 327 non-UDP, non-TCP streams that we have to consider? If so, we can do 328 prefix elision for these streams. (This will have to be negotiated 329 by the signalling protocol on a per-stream basis). 331 2.5 Planned QOSPPP Features 333 We will try to choose the PID values so that their Hamming distance 334 is at least two, allowing single bit errors in the PID field to be 335 detected. 337 In the QOSPPP Framing engine the FCS field can be turned off for 338 individual CBR and VBR streams. We could also adopt Carsten's idea 339 [6] of using an 8-bit CRC for CBR and VBR streams. Thus the 340 effective Framing overhead can be reduced by a byte for CBR and 341 VBR streams. We propose to use the 8-bit FCS described in the V.76 342 specification [9], unless the IETF already has a standard for 343 an 8-bit FCS. 345 Another planned extension to QOSPPP is multiple levels of 346 preemption. In this we will put different streams into 347 different preemption classes and allow a packet of a stream of a 348 higher preemption class to preempt a currently transmitting packet 349 of a stream of a lower preemption class. Currently, we do not 350 plan to support dynamic priorities (where two streams' relative 351 priorities can change dynamically). The QOSPPP frame format can 352 support multiple preemption levels without any change. 354 Multiple preemption levels are explained by the following diagram 355 that shows two levels of preemption. Assume that there are three 356 active streams, a TCP stream (maybe a Web browser), a video 357 stream and a voice stream (the latter two for video conferencing). 358 Assume that the video stream belongs to a higher preemption level 359 than the TCP stream and the voice stream belongs to a higher 360 preemption level than the video stream. Initially, in the absence 361 of any voice or video data, the framer begins transmission of a 362 packet of the TCP stream. After some time, a video packet is queued 363 for transmission and the framer suspends transmission of the TCP 364 stream to begin sending the video packet. Before transmission of 365 the video packet is complete, a voice packet is queued for 366 transmission. The framer suspends transmission of the video stream 367 to begin sending the voice packet. When transmission of the voice 368 packet is complete, the framer resumes transmission of the 369 suspended video packet. When transmission of the video packet is 370 complete, the framer resumes transmission of the suspended TCP 371 packet. Note that a video packet can not interrupt a voice packet 372 or another video packet, and one voice packet can not interrupt 373 another voice packet. 375 Preempted packet - (starts earlier in time) 376 --------------------------- - - - ----------------------------- 377 |HDLC |IP PID | TCP data \ \ TCP data |FCS |HDLC | 378 |Flag |0x21 | \ \ (contd.)|(2 bytes) |Flag | 379 |0x7e | | \ \ | |0x7e | 380 ------------------------------ - - - -------------------------- 381 Suspend Resume 382 / \ 383 / \ 384 / \ 385 / \ 386 / \ 387 / First level of Preemption \ 388 / (Starts later in time - \ 389 / completes earlier) \ 390 --------------- - - - - ---------------- 391 |Suspend |CBR |Video data|FCS |HDLC | 392 |Flag |PID |'n' bytes |(1 or 2|Flag | 393 |0x7c | | | bytes)|0x7e | 394 --------------- - - - - ---------------- 395 Suspend Resume 396 / \ 397 / \ 398 / \ 399 / \ 400 / \ 401 / Second level of Preemption \ 402 / (Starts still later in time - \ 403 / completes first) \ 404 ---------------------------------------- 405 |Suspend |CBR |Voice data|FCS |HDLC | 406 |Flag |PID |'m' bytes |(1 or 2|Flag | 407 |0x7c | | | bytes)|0x7e | 408 ---------------------------------------- 410 Note that the suspended packets have to be resumed in the reverse 411 (stack-like or LIFO) order; i.e. if streamA preempts streamB 412 preempts streamC, then when streamC completes, streamB must 413 resume (and complete) before streamA is resumed. Currently we do 414 not expect to support resumption of suspended packets in a 415 different order (which, by the way, would necessarily imply 416 implementing dynamic priorities). 418 3. Comparison with other proposals 420 In all the descriptions below we are assuming that the 421 address-control field compression and protocol field compression 422 options have been negotiated by the link control protocol, and that 423 all PIDs used for the real-time streams are 1 byte. 425 Case 0. The QOSPPP fragmentation format 427 {--------------------------------------}Preempted packet 428 {HDLC Flag 0x7e } 429 {--------------------------------------} 430 {PID (1 byte) } 431 {--------------------------------------} 432 {Data packet } 433 {-------|------------------------------|--------|Preempting packet 434 |SUSPEND FLAG 0x7c | 435 |---------------------------------------| 436 |PID (1 byte - opt) | 437 |---------------------------------------| 438 |Real-time Data packet | 439 |---------------------------------------| 440 |FCS (0, 1, or 2 bytes - negotiable) | 441 |---------------------------------------| 442 |HDLC Flag 0x7e | 443 {-------|------------------------------|--------| 444 {Data packet (contd) }Preempted packet resumes 445 {--------------------------------------} 446 {FCS (2 bytes) } 447 {--------------------------------------} 448 {HDLC Flag 0x7e } 449 {--------------------------------------} 451 This frame has between 5 and 2 bytes of overhead per preemption; 452 the minimum of two bytes is in the case when there is only a single 453 active stream of a high preemption class, and it has been 454 negotiated not to require the use of a CRC; the maximum of five 455 bytes is when there are multiple active streams of high preemption 456 classes (either in the same class, or in different preemption 457 classes), and they require the use of a 2 byte CRC. We could also 458 consider using a 1 byte CRC (as suggested by Carsten Bormann), for 459 streams whose packets are rather short. Note that there is no 460 overhead on the interrupted packet. Therefore every low priority 461 packet carries 5 bytes of framing overhead (regardless of whether it 462 is preempted or not), and every higher priority packet carries 2 to 5 463 bytes of overhead. 465 There is no limit on the number of preemption levels, except the 466 number of bits in a PID (though not all combinations are valid). 468 In the case of multiple levels of preemption, it assumes that 469 suspended frames will be resumed in the reverse order, from that 470 in which they were suspended. 472 In the absence of preemption, the frame format is exactly the same 473 as regular PPP. 475 We will consider the following proposals from Carsten Bormann and 476 try to consider all the optimizations too. 478 Case 1. Using PPP Multi-Link as-is (short sequence number fragment 479 format) 481 {--------------------------------------}Preempted packet 482 {HDLC Flag 0x7e } 483 {--------------------------------------} 484 {MLPPP PID 0x3d (1 byte) } 485 {--------------------------------------} 486 { B | E | 0 | 0 | sequence number } 487 {--------------------------------------} 488 {PID (1 byte) } 489 {--------------------------------------} 490 {Fragment Data } 491 {--------------------------------------} 492 {FCS (2 bytes) } 493 {--------------------------------------} 494 {HDLC Flag 0x7e } 495 {-------|------------------------------|--------|Preempting packet 496 |PID (1 byte) | 497 |---------------------------------------| 498 |Real-time Data packet | 499 |---------------------------------------| 500 |FCS (2 bytes) | 501 |---------------------------------------| 502 |HDLC Flag 0x7e | 503 {-------|------------------------------|--------| 504 {MLPPP PID 0x3d (1 byte) }Preempted packet resumes 505 {--------------------------------------} 506 { B | E | 0 | 0 | sequence number } 507 {--------------------------------------} 508 {Fragment Data (contd) } 509 {--------------------------------------} 510 {FCS (2 bytes) } 511 {--------------------------------------} 512 {HDLC Flag 0x7e } 513 {--------------------------------------} 515 In this scheme, every lower priority packet needs to be sent in at 516 least two MLPPP frames. (Since we do not know whether it is going 517 to be interrupted or not, we must begin transmitting with the "E" 518 bit set to "0". Therefore, even if it is not interrupted, we need 519 to send a final (empty) fragment with the "E" bit set to "1" to 520 terminate the packet). Now, the MLPPP frame has 6 bytes of framing 521 overhead, therefore every lower priority packet has 6*2= 12 bytes 522 of framing overhead. However, the MLPPP packet actually carries a 523 PPP packet within it adding an additional 1 byte overhead (for the 524 PPP PID) making the total framing overhead 13 bytes. We can save 525 one byte by not transmitting two consecutive Flag bytes making the 526 total framing overhead 12 bytes as opposed to 5 bytes for a normal 527 PPP frame. For every preemption, the lower priority packet needs to 528 be terminated with an MLPPP trailer (3 bytes) and restarted with an 529 MLPPP header (3 bytes) adding an additional 6 bytes overhead. 530 Additionally, the preempting packet needs it's PPP header of 5 531 bytes, giving a total framing overhead of 11 bytes per preemption. 532 Dropping consecutive Flag bytes will save two bytes giving a total 533 framing overhead of 9 bytes per preemption as opposed to 5 bytes 534 for a normal PPP frame. In case the interrupted packet is resumed 535 near it's end (e.g. it has fewer than say 7 bytes left to 536 transmit), we can assume that it will not be interrupted again and 537 can send the last fragment with the "E" bit set to "1", thus 538 eliminating the 5 bytes of the empty MLPPP header at the end. 540 It supports a single level of preemption. 542 It can be used even if the other end does not support QoS. This 543 however, assumes that the other end supports MLPPP; We are not sure 544 how many implementations, and how many service providers support 545 MLPPP for analog lines. 547 Case 2. Extending PPP Multi-Link to multiple class (short sequence 548 number fragment format) 550 {--------------------------------------}Preempted packet 551 {HDLC Flag 0x7e } 552 {--------------------------------------} 553 {MLPPP PID 0x3d (1 byte) } 554 {--------------------------------------} 555 { B | E | Class | sequence number } 556 {--------------------------------------} 557 {PID (1 byte) } 558 {--------------------------------------} 559 {Fragment Data } 560 {--------------------------------------} 561 {FCS (2 bytes) } 562 {--------------------------------------} 563 {HDLC Flag 0x7e } 564 {-------|------------------------------|--------|Preempting packet 565 |MLPPP PID 0x3d (1 byte) | 566 |---------------------------------------| 567 | B | E | Class | sequence number | 568 |---------------------------------------| 569 |PID (1 byte) | 570 |---------------------------------------| 571 |Real-time Data packet | 572 |---------------------------------------| 573 |FCS (2 bytes) | 574 |---------------------------------------| 575 |HDLC Flag 0x7e | 576 {-------|------------------------------|--------| 577 {MLPPP PID 0x3d (1 byte) }Preempted packet resumes 578 {--------------------------------------} 579 { B | E | Class | sequence number } 580 {--------------------------------------} 581 {Fragment Data (contd) } 582 {--------------------------------------} 583 {FCS (2 bytes) } 584 {--------------------------------------} 585 {HDLC Flag 0x7e } 586 {--------------------------------------} 588 The difference between this scheme and case 1 is that it supports 589 4 levels of preemption. However, now preempting packets carry an 590 MLPPP header (plus a PPP PID), instead of a normal PPP header 591 (except for one of the preemption levels which uses normal PPP 592 frames). Thus the preempting packets carry (6(MLPPP header) + 593 1(PPP PID) = ) 7 bytes of framing overhead per packet. So the total 594 framing overhead per preemption is (6 (preempted) + 7 (preempting) 595 = ) 13 bytes. Again, dropping consecutive Flag bytes will save two 596 bytes giving a total framing overhead of 11 bytes per preemption 597 as opposed to 5 bytes for a normal PPP frame. 599 It is backward compatible to case 1; i.e. if the remote end does 600 not support QoS, we can fall back to case 1, restricting ourselves 601 to a single level of preemption. 603 In the case of multiple levels of preemption, suspended frames can 604 be resumed in any order, not necessarily the reverse order from 605 that in which they were suspended. 607 Case 3. The Compact Fragment Format (Normal header) 609 {--------------------------------------}Preempted packet 610 {HDLC Flag 0x7e } 611 {--------------------------------------} 612 {R | Sequence | Class | 1 }(Normal header) 613 {--------------------------------------} 614 {Low priority class' fragment Data } 615 {--------------------------------------} 616 { SUSPEND FLAG } 617 {--------------------------------------} 618 { FCS (2 bytes) } 619 {---|----------------------------------|---|Preempting packet 620 |HDLC Flag 0x7e | 621 |--------------------------------------| 622 |R | Sequence | Class | 1 |(Normal header) 623 |--------------------------------------| 624 |High priority class' fragment Data | 625 |--------------------------------------| 626 |FCS (2 bytes) | 627 |--------------------------------------| 628 |HDLC Flag 0x7e | 629 {---|----------------------------------|---| 630 {R | Sequence | Class | 1 }Preempted packet resumes 631 {--------------------------------------} 632 {Low priority fragment Data (contd.) } 633 {--------------------------------------} 634 { FCS (2 bytes) } 635 {--------------------------------------} 636 {HDLC Flag 0x7e } 637 {--------------------------------------} 639 Note: In the diagram above, the PID bytes and the TERMINATE flag 640 bytes have been dropped by optimizations. 642 It supports 7 levels of preemption. 644 In the case of multiple levels of preemption, suspended frames can 645 be resumed in any order, not necessarily the reverse order from 646 that in which they were suspended. 648 The preempting packet's header has 5 bytes of overhead which is the 649 same as the normal PPP header. However the lower priority packet 650 has terminated by an FCS and SUSPEND byte (3 bytes), and when it 651 resumes, it will carry a 1 byte header, adding 4 bytes of overhead 652 per preemption. Also the Higher priority packet will need 5 bytes 653 of framing overhead, making the total framing overhead (5 + 4 = ) 9 654 bytes per preemption. (This is assuming that it is not necessary to 655 send consecutive Flag bytes.) So this scheme has a total framing 656 overhead of 9 bytes per preemption as opposed to 5 bytes for a 657 normal PPP frame. 659 Case 4. The Compact Fragment Format (Insertion Header) 661 {--------------------------------------}Preempted packet 662 {HDLC Flag 0x7e }(Normal header) 663 {--------------------------------------} 664 {R | Sequence | Class | 1 } 665 {--------------------------------------} 666 {Low priority class' fragment Data } 667 {--------------------------------------} 668 { SUSPEND FLAG } 669 {--------------------------------------} 670 { FCS (2 bytes) } 671 {---|----------------------------------|---|Preempting packet 672 |HDLC Flag 0x7e | 673 |--------------------------------------| 674 |Length L | C | 0 |(Inversion header) 675 |--------------------------------------| 676 |Inserted Packet (of length L) | 677 |--------------------------------------| 678 |FCS (1 byte) | 679 {---|----------------------------------|---| 680 {R | Sequence | Class | 1 }Preempted packet resumes 681 {--------------------------------------} 682 {Low priority fragment Data (contd.) } 683 {--------------------------------------} 684 { FCS (2 bytes) } 685 {--------------------------------------} 686 {HDLC Flag 0x7e } 687 {--------------------------------------} 689 It supports 2 levels of preemption. 691 The preempting packet's header has 3 bytes of overhead which is 692 less than the normal PPP header. However the lower priority packet 693 has terminated by an FCS and SUSPEND byte (3 bytes), and when it 694 resumes, it will carry a 1 byte header, adding 4 bytes of overhead 695 per preemption. Also the Higher priority packet will need 3 bytes 696 of framing overhead, making the total framing overhead (3 + 4 = ) 7 697 bytes per preemption. (This is assuming that it is not necessary to 698 send consecutive Flag bytes.) So this scheme has a total framing 699 overhead of 7 bytes per preemption as opposed to 5 bytes for a 700 normal PPP frame. 702 It does have the restriction that the higher priority packet be 703 not more than 64 bytes in length. 705 Comparison of Overhead 707 Cases 1 & 2 have more overhead than the rest. Case 1 is useful 708 only if it is necessary to support (a single level of) preemption 709 even for links where the peer does not support QoS. Even this is 710 debatable for two reasons: 712 (1) How many implementations actually support MLPPP for analog 713 lines, and, 715 (2) Preemption by itself is generally not sufficient to support 716 QoS for analog lines, one also needs to do some form of header 717 compression, especially considering the increased size of the 718 MLPPP headers. Would the remote end which does not have support 719 for QoS support the header compression scheme? 721 Case 2 does not seem useful considering that it requires the remote 722 end to support a non-standard extension to MLPPP. If the remote end 723 has to be modified to support this extension, one should question 724 why it can not be modified to support some other, more efficient, 725 extension. It does have the advantage of being able to gracefully 726 fallback to case 1, but as mentioned above, the value of this 727 advantage seems to be rather dubious. (At the September 30th ISSLL 728 meeting in Billerica, it was agreed to make case 2 the baseline 729 case and work from there towards a more optimized scheme.) 731 Compare cases 0, 3 & 4 in more detail. 733 One of the optimizations in case 4 that caused a 1 byte reduction 734 in overhead (the smaller FCS) can also be applied to cases 0 and 3. 735 The second optimization (dropping the intermediate Flag byte) is 736 achieved mainly by putting a length field in the header and 737 shrinking the class number to 1 bit. The former restricts the 738 length of high priority packets to 64 bytes which may be O.K., the 739 latter restricts the number of high priority streams to 2, which 740 makes it O.K. as an optimization of case 3 rather than as a 741 separate case (which anyway, is what Carsten presents it as). 743 Let us examine cases 0 & 3. Consider the following scenarios for 744 cases 0 & 3 (with case 4 as an optimization of case 3). 746 1. normal case, case 0 has 5 bytes overhead, case 3 has 9 bytes 747 2. 8-bit FCS, overhead reduces by 1 byte for both cases. 748 3. No FCS, overhead reduces by 2 bytes for both cases. 749 4. A single high priority stream, reduces case 0 overhead by 1 750 byte by dropping the PID. If the length of the packet is less than 751 64 bytes, case 3 reduces to case 4, saving 2 bytes. 752 5. Upto 2 high priority streams whose packet lengths are less than 753 64 bytes, and which use an 8-bit FCS can have their overhead reduced 754 to 7 bytes for case 3 by using the case 4 optimizations. This 755 compares with 4 bytes for case 0 under the same conditions, except 756 that you can do it for a greater number of streams. 757 6. Case 0 overhead can be reduced by 1 byte by dropping the 758 intermediate Flag byte, however this can be done only for streams 759 that have fixed size packets, and it carries the danger of two 760 packets (the preempted and the preempting,) being corrupted if 761 any byte of the preempting packet is dropped. 763 As can be seen, there does not appear to be a clear advantage 764 of one scheme over the other. 766 Note that the frame formats of cases 1 & 2 actually indicate 767 fragmentation rather than preemption, since each frame carries 768 a header telling the receiver how to put it back together. The 769 idea behind preemption is precisely to avoid the overhead of this 770 kind of header. However, although the frame format makes it look 771 like fragmentation, calling it preemption is justifiable 772 from the point of view of the actual operation of the protocol; 773 i.e., with conventional fragmentation, the stack will decide 774 on how to fragment a packet either when it is given a packet from 775 the higher layer, or, when it decides to begin transmission. In 776 preemption, the decision of how, when, etc. to "fragment" is made 777 at the time a higher priority "preempting" packet becomes eligible 778 for transmission. This distinction can only be made at the sending 779 side, for the receiver it does look like fragmentation. 781 Comparison of error detection capability 783 Case 3 packets have a sequence number which will allow it to detect 784 a lost fragment. Of course, even in case 0, lost fragments can be 785 caught by the FCS, but the sequence number provides an additional 786 check. 788 Case 0 has the disadvantage that if a deeply nested preempting 789 frame (i.e., one that has caused several other frames to be 790 recursively preempted), is corrupted, you run the risk of being 791 forced to discard the stack of preempted frames. This will happen 792 if transmission or overrun errors cause any FLAG bytes to be lost 793 or corrupted, in this case the receiver, on precessing a FLAG 794 byte, may not be able to correctly match it with the corresponding 795 SUSPEND byte. However, we suspect that this topic is not as 796 straightforward as it seems and needs further analysis. 798 Comparison of number of levels of preemption 800 Consider cases 0 and 3 alone as case 4 is an optimization of case 3. 802 Case 0 supports an arbitrary number of levels of preemption, 803 limited only by the PID space. Case 3 supports 7 levels of 804 preemption. There does not seem to be much to choose between them 805 here as 7 levels of preemption are probably enough. 807 Comparison of support for dynamic priorities 809 Case 3 appears to have slightly better support for dynamic 810 priorities. However, let us see if this advantage is meaningful. 812 There is one way in which the use of dynamic priorities can affect 813 the framing format. Consider the case where there are three stream 814 A, B and C, in the increasing order of priorities. Assume that the 815 priorities are dynamic so the priority ordering may change over 816 time. Now consider a scenario where stream B has preempted stream 817 A and stream C has preempted stream B. Suppose stream A gets a 818 priority boost making it temporarily of higher priority that stream 819 B (but lower than stream C). Therefore when stream C completes 820 transmission of it's packet, there is an issue of whether we should 821 resume transmission of stream A or stream B. Carsten's proposals 822 (cases 2 & 3) give the implementation the choice in this matter, 823 QOSPPP does not. 825 This does not mean that dynamic priorities are impossible with 826 QOSPPP. Dynamic priorities can still be used in controlling the 827 decision of preemption of one stream by another, they simply can 828 not be used for making the resumption decision. Also, the scenario 829 above could be considered farfetched by some. For that matter, the 830 whole idea of dynamic priorities might be considered irrelevant 831 for the applications we are considering; the alternative is to 832 allow a slightly larger jitter, which might be perfectly 833 acceptable. 835 Case 0, being limited to a strict stack-like sequence of 836 suspends-resumes might be slightly simpler to implement. 838 4. Conclusions 840 Based on the discussion above, we suggest that any framing format 841 adopted should attempt to borrow the best features of both the 842 QOSPPP framing and Carsten's proposals. In particular, we suggest 843 keeping the following features: 845 UDP header compression. This gives gives a significant reduction 846 in overhead for UDP streams. 848 In the case of a single higher priority stream, keep the option of 849 dropping the PID byte. This however, has to be negotiated by LCP. 851 The signalling protocol will negotiate the size of the FCS for each 852 stream. 854 Use one of Carsten's values of 0xDE or 0xC3 for the Preemption flag. 855 Maybe we should run tests over a PPP link (before the byte stuffing 856 stage) rather than over an Ethernet as he did. 858 We feel that the requirement that packets be resumed in the 859 reverse order from that in which they were suspended (even for 860 Carsten's proposals), would aid the receiver in error detection. 862 The use or non-use of dynamic priorities is an independent decision 863 which will not affect the frame format. Also, it may be possible 864 to restrict the implementation of dynamic priorities to the sending 865 side alone. 867 5. Security Considerations 869 This document does not raise any new security issues. 871 6. Acknowledgments 873 Much of the work in implementing the QOSPPP architecture and 874 testing the concepts presented in this document was done by 875 Murali Aravamudan and Kumar Vishwanathan of isochrone, Inc. 876 Andreas Papanicolau and Khasha Mohammadi of AT&T also provided 877 many helpful insights in the design of the architecture. 879 7. References 881 [1] Simpson, W., Editor, "PPP in HDLC Framing", RFC 1662, 882 STD 51, Daydreamer, July 1994. 884 [2] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 885 RFC 1661, STD 51, Daydreamer, July 1994. 887 [3] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, 888 Daydreamer, January 1994. 890 [4] McGregor, G., "The PPP Internet Control Protocol", RFC 1332, 891 Merit, May 1992. 893 [5] Bormann, Carsten, "Providing integrated services over 894 low-bitrate links", work in progress, Internet Draft 895 (draft-ietf-issll-isslow-00.txt), Universitaet Bremen, 896 June 1996. 898 [6] Bormann, Carsten, "The Multi-Class Extensions to Multi-Link 899 PPP", work in progress, Internet Draft, 900 (draft-ietf-issll-isslow-mcml-00.txt), Universitaet Bremen, 901 September 1996. 903 [7] "ATM User-Network Interface (UNI) Specification Version 3.1", 904 The ATM Forum, 1995. 906 [8] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, 907 RFC 1700, USC/Information Sciences Institute, October 1994. 909 [9] Burg, F., editor, "Recommendation V.76 - Generic Multiplexer 910 using V.42 LAPM-based procedures", International 911 Telecommunication Union, April 1996. 913 8. Author's Address 915 Questions about this memo can be directed to: 917 Richard Andrades 918 isochrone, Inc. Phone: (908) 544 5508 919 One Main Street Fax: (908) 544 2059 920 Suite 511 Email: richard@isochrone.com 921 Eatontown, NJ 07724 923 Fred M. Burg 924 AT&T 925 307 Middletown-Lincroft Road Phone: (908) 576 4322 926 Room 3L209 Fax: (908) 576 4689 927 Lincroft, NJ 07738 Email: fred.burg@att.com