idnits 2.17.1 draft-ietf-issll-isslow-svcmap-08.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 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 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 13 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. ** There are 47 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 37 instances of lines with control characters in the document. ** The abstract seems to contain references (4], [5], [6], 3,, [1,2,), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 17, 1999) is 9101 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '7' is defined on line 557, 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') == Outdated reference: A later version (-06) exists of draft-ietf-issll-isslow-mcml-05 == Outdated reference: A later version (-05) exists of draft-ietf-issll-isslow-rtf-04 == Outdated reference: A later version (-01) exists of draft-davie-intserv-compress-00 -- Possible downref: Normative reference to a draft: ref. '9' ** Obsolete normative reference: RFC 2509 (ref. '10') (Obsoleted by RFC 3544) ** Downref: Normative reference to an Informational RFC: RFC 2209 (ref. '14') Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Steve Jackowski/Deterministic Networks 2 Expires: November 1999 David Putzolu/Intel Architecture Labs 3 Eric Crawley/Argon Networks 4 Bruce Davie/Cisco Systems 5 May 17, 1999 7 Integrated Services Mappings for Low Speed Networks 8 draft-ietf-issll-isslow-svcmap-08.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC 2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-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 not appropriate 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 set of companion documents describe an architecture for providing 32 integrated services over low-bitrate links, such as modem lines, ISDN 33 B-channels, and sub-T1 links [1, 2, 3, 4]. The main components of the 34 architecture are: a set of real-time encapsulation formats for 35 asynchronous and synchronous low-bitrate links, a header compression 36 architecture optimized for real-time flows, elements of negotiation 37 protocols used between routers (or between hosts and routers), and 38 announcement protocols used by applications to allow this negotiation 39 to take place. 41 This document defines the service mappings of the IETF Integrated 42 Services for low-bitrate links, specifically the controlled load [5] 43 and guaranteed [6] services. The approach takes the form of a set of 44 guidelines and considerations for implementing these services, along 45 with evaluation criteria for elements providing these services. 47 1. Introduction 49 In addition to the "best-effort" services the Internet is well-known 50 for, other types of services ("integrated services") are being 51 developed and deployed in the Internet. These services support special 52 handling of traffic based on bandwidth, latency, and other 53 requirements that cannot usually be met using "best-effort" service. 55 This document defines the mapping of integrated services "controlled 56 load" [5] and "guaranteed" [6] services on to low-bandwidth links. 57 The architecture and mechanisms used to implement these services on 58 such links are defined in a set of companion documents. The mechanisms 59 defined in these documents include both compression of flows (for 60 bandwidth savings) [4,10] and a set of extensions to the PPP protocol 61 which permit fragmentation [2] or suspension [3] of large packets in 62 favor of packets from flows with more stringent service requirements. 64 1.1. Specification Language 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC 2119 [11]. 70 2. Issues for Providing Controlled and Guaranteed Service 72 Unlike other link layers, the links referred to in this document 73 operate only over low speed point to point connections. Examples of 74 the kinds of links addressed here include dial-up lines, ISDN 75 channels, and low-speed (1.5Mbps or less) leased lines. Such links 76 can occur at different positions within the end-to-end path: 78 - host to directly connected host. 79 - host to/from network access device (router or switch). 80 - Edge device (subnet router or switch) to/from router or switch. 81 - In rare circumstances, a link from backbone router to backbone 82 router. 84 These links often represent the first or last wide area hop in a true 85 end to end service. Note that these links may be the most bandwidth 86 constrained along the path between two hosts. 88 The services utilized in mapping integrated services to these links 89 are only provided if both endpoints on the link support the 90 architecture and mechanisms referenced above. Support for these 91 mechanisms is determined during the PPP negotiation. The non-shared 92 nature of these links, along with the fact that point-to-point links 93 are typically dual simplex (i.e., the send and receive channels are 94 separate) allows all admission control decisions to be made locally. 96 As described in [2] and [3], for systems that can exert real time 97 control of their transmission at a finer grain than entire HDLC 98 frames, the suspend/resume approach optimizes the available bandwidth 99 by minimizing header overhead associated with MLPPP pre-fragmentation 100 and can provide better delay. However, this comes at the expense of 101 preparing all outgoing data and scanning all incoming data for 102 suspend/resume control information. The fragmentation approach can be 103 implemented without additional scanning of the data stream (beyond 104 bit-/byte-stuffing, which may be in hardware) and is applicable to 105 systems which provide only frame-oriented transmission control. 106 Choice of suspend/resume versus fragmentation should be made based on 107 the level of transmission control, the element's capability to handle 108 the HDLC-like framing described in [2], and the system overhead 109 associated with byte by byte scanning (required by suspend/resume). 111 To provide controlled load or guaranteed service with the 112 suspend/resume approach, when a packet for an admitted flow (QoS 113 packet) arrives during transmission of a best effort packet and 114 continued transmission of the best effort packet would violate delay 115 constraints of the QoS service flows, the best effort packet is 116 preempted, the QoS packet/fragments are added to the transmission, and 117 the best effort packet transmission is then resumed: usually all in 118 one transmission. The receiving station separates the best effort 119 packet from the embedded QoS packet's fragments. It is also 120 conceivable that one QoS flow's packet might suspend another flow's 121 packet if the delivery deadline of the new packet is earlier than the 122 current packet. 124 For systems which use fragmentation, any packets longer than the 125 maximum tolerable delay for packets from enhanced service flows are 126 fragmented prior to transmission so that a short packet for another 127 flow can be interleaved between fragments of a larger packet and still 128 meet the transmission deadline for the flow requiring enhanced 129 services. 131 Note that the fragmentation discussed in this document refers to 132 multilink PPP (MLPPP) fragmentation and associated MCMLPPP 133 modifications as described in [2], not IP or other layer 3 134 fragmentation. MLPPP fragmentation is local to the PPP link, and does 135 not affect end-to-end (IP) MTU. 137 2.1 Calculating "Acceptable Delay" for Int-serv flows 139 A router which provides Controlled Load or Guaranteed Service over a 140 low speed serial link needs to have some notion of the "acceptable 141 delay" for packets that belong to int-serv flows. If using 142 fragmentation, a router needs to know what size to fragment packets 143 to; if using suspend/resume, it needs to know when it is appropriate 144 to suspend one packet to meet the delay goals of another. 146 Unfortunately, there is no hard and fast way for a single delay bound 147 to be determined for a particular flow; while the end-points of a flow 148 have enough information to determine acceptable end-to-end delay 149 bounds and to make reservation requests of the network to meet those 150 bounds, they do not communicate a "per-hop" delay to routers. 152 In the case of Guaranteed Service [6], one approach is to let the 153 network operator configure parameters on the router that will directly 154 affect its delay performance. We observe that guaranteed service 155 allows routers to deviate from the ideal fluid flow model and to 156 advertise the extent of the deviation using two error terms C and D, 157 the rate-dependent and rate-independent error terms, defined in [6]. A 158 network operator can configure parameters of the low speed link in 159 such a way that D is set to a value of her choice. 161 If link-level fragmentation is used, the router controlling a 162 low-speed link can be configured with a certain fragment size. This 163 will enable a component of the error term D to be calculated based on 164 the time to send one fragment over the link. (Note that D may have 165 other components such as the speed of light delay over the link.) 166 Details of the calculation of D are described below. Similarly, if 167 suspend/resume is used, the router may be configured with a delay 168 parameter, which would enable it to decide when it was appropriate to 169 suspend a packet. 171 For Controlled Load, there are no error terms, and the router must 172 decide how best to meet the requirements of the admitted reservations 173 using only the information in their TSpecs. Since the definition of 174 Controlled Load states that a CL flow with Tspec rate r should receive 175 treatment similar to an unloaded network of capacity r, CL packets 176 should not generally experience end-to-end delays significantly 177 greater than b/r + propagation delays. Clearly a router connected to a 178 low speed link should not introduce a delay greater than b/r due to 179 transmission of other fragments; ideally it should introduce 180 substantially less delay than b/r, since other hops on the end-to-end 181 path may introduce delay as well. However, this may be difficult for 182 flows with very small values of b. 184 It is expected that implementers will make their own tradeoffs as to 185 how low to make the delay for Controlled Load flows. Similarly, it may 186 not be possible or desirable to configure the parameters affecting D 187 to arbitrarily small values, since there is a cost in overhead in 188 fragmenting packets to very small sizes. Conversely, if D is too 189 large, some applications may find that they cannot make a reservation 190 that will meet their delay objectives. 192 For the remainder of this document, we assume that a router has some 193 notion of the acceptable delay that it may introduce before beginning 194 transmission of a packet. This delay is in addition to any delay that 195 a packet might be subjected to as a result of the "ideal" queuing 196 algorithm that the router uses to schedule packets. 198 3. Controlled Load and Guaranteed Service Class Mapping 200 Supporting integrated services over PPP links which implement MCML or 201 RTF can be accomplished in several ways. Guidelines for mapping these 202 services to PPP links and to the classes provided by the 203 suspend/resume and fragmentation mechanisms are presented below. Note 204 that these guidelines assume that some sort of signaling protocol is 205 used to indicate desired quality of service to both the sender and 206 receiver of a flow over a PPP link. 208 3.1 Predefined Class Mappings 210 A relatively simple method of class mapping that MAY be used is one 211 where class values correspond to predefined levels of service. In 212 this arrangement, all admitted flows are grouped into one of several 213 buckets, where each bucket roughly corresponds to the level of service 214 desired for the flows placed in it. An example set of mappings appears 215 below: 217 MCML Short MCML Long RTF Service 219 0b00 0b0000 0b000 Best Effort 220 NA 0b0001 0b001 Reserved 221 0b01 0b0010 0b010 Delay Sensitive, no bound 222 NA 0b0011 0b011 Reserved 223 NA 0b0100 0b100 Reserved 224 0b10 0b0101 0b101 Delay Sensitive, 500ms bound 225 NA 0b0110 0b110 Delay Sensitive, 250ms bound 226 0b11 0b0111 0b111 Network Control 228 Table 1: Example Mappings of Classes to Services 230 Note that MCML has two formats, short sequence numbers, and long 231 sequence numbers, that allow for 2 and 4 bits of class identification. 232 RTF allows for 3 bits of class identification in all formats. 234 Using a default-mapping method of assigning classes to flows in a 235 fixed fashion comes with certain limitations. In particular, all flows 236 which fall within a particular bucket (are assigned to a particular 237 class) will be scheduled against each other at the granularity of 238 packets, rather than at the finer grained level of fragments. This 239 can result in overly conservative admission control when the number of 240 available classes is small such as in MCML short sequence number 241 format. 243 3.2 Predefined Class Mappings and Prefix Elision 245 In the case where fewer reservations are expected than the total 246 number of classes negotiated for a PPP link, it is possible to assign 247 individual flows to fixed class numbers. This assignment is useful in 248 the case where the protocol identifier associated with one or more 249 flows is known at LCP negotiation time and the bandwidth of the 250 connection is relatively small. If these conditions hold true, then 251 for those flows that are known, a specific class can optionally be 252 assigned to them and the prefix elision PPP option can be used for 253 those classes to achieve a small bandwidth savings. 255 3.3 Dynamic Class Mappings 257 In the case where predefined class mappings are not satisfactory, an 258 implementer MAY map class values to individual packets rather than 259 assigning flows to fixed classes. This can be done due to the fact 260 that the classes that MCML and RTF provide can be viewed purely as 261 PPP-specific segmentation/fragmentation mechanisms. That is, while the 262 class number MUST remain constant on an intra-packet basis, it MAY 263 vary on an inter-packet basis for all flows transiting a PPP 264 link. Actual assignment of particular flows to fixed classes is 265 unnecessary, as the class numbers are NOT REQUIRED to have any meaning 266 other than in the context of identifying the membership of 267 fragments/segments as part of a single packet. This point is 268 sufficiently important that an example is provided below. 270 Consider a PPP link using the MCML short sequence number fragment 271 format (that is, four classes are provided). Assume that in addition 272 to carrying best effort traffic, this link is carrying five guaranteed 273 service flows, A, B, C, D, and E. Further assume that the link 274 capacity is 100kbit/s and the latency is 100ms. Finally, assume the BE 275 traffic is sufficient to keep the pipe full at all times and that GS 276 flows A-E are each 10kbit/s and all have delay bounds of 145ms. 278 Time(ms) Action 279 0 BE traffic is queued up 280 0 2kbit fragment from 10kbit packet of BE traffic sent, cls 0 (...) 281 8 2kbit fragment from BE sent, cls 0 (10kbit BE packet done) 282 9 8kbit packet from flow A arrives 283 10 2kbit fragment from A sent, cls 1 (8kbit flow A packet start) 284 11 8kbit packet from flow B arrives 285 12 2kbit fragment from B sent, cls 2 (8kbit flow B packet start) 286 13 8kbit packets from flows C, D, and E arrive 287 14 2kbit fragment from C sent, cls 3 (8kbit flow C packet start) 288 16 2kbit fragment from D sent, cls 0 (8kbit flow D packet start) 289 18 2kbit fragment from A sent, cls 1 290 20 2kbit fragment from B sent, cls 2 291 22 2kbit fragment from A sent, cls 1 292 24 2kbit fragment from A sent, cls 1 (8kbit flow A packet done) 293 26 2kbit fragment from E sent, cls 1 (8kbit flow E packet start) 294 27 8kbit packet from flow A arrives 295 28 2kbit fragment from B sent, cls 2 296 30 2kbit fragment from C sent, cls 3 297 32 2kbit fragment from E sent, cls 1 298 34 2kbit fragment from B sent, cls 2 (8kbit flow B packet done) 299 36 2kbit fragment from E sent, cls 1 300 38 2kbit fragment flow A sent, cls 2 (8kbit flow A packet start) 301 (etc.) 302 This example shows several things. First, multiple flows MAY share the 303 same class, particularly in the case where there are more flows than 304 classes. More importantly, there is no reason that a particular flow 305 must be assigned to a fixed class - the only requirement is that each 306 packet, when fragmented, MUST have the same class value assigned to 307 all fragments. Beyond this requirement the link scheduler may assign 308 individual to changing class numbers as necessary to meet reservation 309 requirements. 311 One suggestion to implementers of integrated services on MCML and RTF 312 links using dynamic mappings is that all BE traffic SHOULD be 313 logically separated from QoS traffic, and mapped to a fragmentable 314 (MCML classes 0-3 in short sequence number fragment format, 0-15 in 315 long sequence number fragment format) or suspendable (RTF classes 0-6) 316 class. Since BE traffic will in most implementations not be scheduled 317 for transmission except when a link is empty (that is, no CL or GS 318 traffic is ready for transmission), implementers MAY choose to make 319 use of class number 0 for BE traffic. 321 3.4 Non-Conformant Traffic 323 Treatment of non-conformant QoS traffic is largely determined by the 324 appropriate service specifications, but the detailed implementation in 325 the context of this draft allows for some flexibility. Policing of 326 flows containing non-conformant traffic SHOULD always be done at the 327 level of granularity of individual packets rather than at a finer 328 grained level. In particular, in those cases where a network element 329 scheduling flows for transmission needs to drop non-conformant 330 traffic, it SHOULD drop entire packets rather than dropping individual 331 fragments of packets belonging to non-conformant traffic. In those 332 cases where a network element forwards non-conformant traffic when 333 link bandwidth is available rather than dropping the traffic, the 334 implementation SHOULD fragment packets of such traffic as if it were 335 best effort traffic. 337 Whether BE and non-conformant traffic are treated differently in 338 regards to transmission (e.g., BE is given priority access over 339 non-conformant traffic to the link) or whether within each type of 340 traffic special treatment is afforded to individual flows (e.g., WFQ, 341 RED, etc.) is service dependent. 343 4. Guidelines for Implementers 345 4.1. PPP Bit and Byte Stuffing Effects on Admission Control 347 An important consideration in performing admission control for PPP 348 links is reductions in effective link rate due to bit 349 stuffing. Typical bit stuffing algorithms can result in as much as 20% 350 additional overhead. Thus, admission control implementations for 351 guaranteed service over links where bit stuffing is used SHOULD take 352 the RSpec rate of all flows and multiply by 1.2, to account for the 353 20% overhead from bit stuffing, when determining whether a new flow 354 can be admitted or not. Admission control implementations 355 for controlled load reservations may use a similar algorithm using the 356 TSpec peak rate or may attempt to measure the actual degree of 357 expansion occurring on a link due to bit stuffing. This 358 characterization can then be used to adjust the calculated remaining 359 link capacity. Such measurements must be used cautiously, in that the 360 degree of bit stuffing that occurs may vary significantly, both in an 361 inter- and intra-flow fashion. 363 Byte stuffing is also used on many PPP links, most frequently on POTS 364 modems when using the v.42 protocol. Byte stuffing poses a difficult 365 problem to admission control, particularly in the case of guaranteed 366 service, due to its highly variable nature. In the worse case, byte 367 stuffing can result in a doubling of frame sizes. As a consequence, a 368 strict implementation of admission control for guaranteed load on byte 369 stuffed PPP links SHOULD double the RSpec of link traffic in making 370 flow admission decisions. As with bit stuffing, implementations of 371 controlled load service admission control algorithms for links with 372 byte stuffing MAY attempt to determine average packet expansion via 373 observation or MAY use the theoretical worst case values. 375 4.2. Compression Considerations 377 The architecture for providing integrated services over low bandwidth 378 links uses several PPP options to negotiate link configuration as 379 described in [4, 8, 10]. When deciding whether to admit a flow, 380 Admission Control MUST compute the impact of the following on MTU 381 size, rate, and fragment size: 383 Header compression: Van Jacobson or Casner-Jacobson [4,8,10]. 384 Prefix Elision. 385 CCP. 386 Fragment header option used. 387 Fragmentation versus suspend/resume approach. 389 If any of the compression options are implemented for the connection, 390 the actual transmission rate, and thus the bandwidth required of the 391 link, will be reduced by the compression method(s) used. 393 Prefix elision can take advantage of mapping flows to MLPPP classes to 394 elide prefixes which cannot be compressed at higher layers. By 395 establishing agreement across the link, the sender may elide a prefix 396 for a certain class of traffic and upon receiving packets in that 397 class, the receiver can restore the prefix. 399 Both compression gain and elision gain MUST be included as described 400 in the admission control section below. Note that the ability to 401 perform compression at higher layers (e.g. TCP or RTP/UDP) may depend 402 on the provision of a hint by the sender, as described in [9]. 404 4.3. Admission Control 406 Admission Control MUST decide whether to admit a flow based on rate 407 and delay. Assume the following: 409 LinkRate is the rate of the link. 410 MTU is the maximum transmission unit from a protocol. 411 MRU is the maximum receive unit for a particular link. 412 CMTU is the maximum size of the MTU after compression is applied. 413 eMTU is the effective size at the link layer of an MTU-sized packet after 414 link layer fragmentation and addition of the fragment headers. 415 FRAG is the fragment size including MLPPP header/trailers. 416 Header is the size of the header/trailers/framing for MLPPP/Fragments. 417 pHeader is the additional header/framing overhead associated with 418 suspend/resume. This should include FSE and worst case stuffing 419 overhead. 420 pDelay is the time take to suspend a packet already "in flight", 421 e.g. due to the delay to empty the output FIFO. 422 b is the bucket depth in bytes 423 R is the requested Rate. 424 Dlink is the fixed overhead delay for the link (Modem, DSU, 425 speed-of-light, etc). 426 eRate is the effective rate after compression and fragmentation. 428 The Dlink term MAY be configured by an administrative tool once the 429 network is installed; it may be determined by real-time measurement 430 means; or it MAY be available from hardware during link setup and/or 431 PPP negotiation. Refer to Appendix A for more considerations on PPP 432 link characteristics and delays. 434 Admission Control MUST compute CMTU, eMTU, and eRate for Controlled 435 Load Service, and it MUST compute CMTU, eMTU, eRate, and D for 436 Guaranteed Service: 438 To determine whether the requested rate is available, Admission 439 Control MUST compute the effective rate of the request (eRate) - 440 worst case - as follows: 442 #_of_Fragments = CMTU div (FRAG-Header) [Integer divide] 443 Last_Frag_Size = CMTU mod (FRAG-Header 445 If Last_Frag_Size != 0 446 eMTU = (#_of_Fragments) * FRAG + Last_Frag_Size + Header 447 Else 448 eMTU = (#_of_Fragments) * FRAG 450 eRate = eMTU/CMTU * R [floating point divide] 452 Admission Control SHOULD compare the eRate of the request against the 453 remaining bandwidth available to determine if the requested rate can 454 be delivered. 456 For Controlled Load Service, a flow can be admitted as long as there 457 is sufficient bandwidth available (after the above computation) to 458 meet the rate requirement, and if there is sufficient buffer space 459 (sum of the token bucket sizes does not exceed the buffer capacity). 460 While some statistical multiplexing could be done in computing 461 admissibility, the nature of the low-bitrate links could make this 462 approach risky as any delay incurred to address a temporary 463 overcommitment could be difficult to amortize. 465 4.4 Error Term Calculations 467 Guaranteed Service requires the calculation of C and D error terms. C 468 is a rate-dependent error term and there are no special considerations 469 affecting its calculation in the low-speed link environment. The D 470 term is calculated from the inherent link delay (Dlink) plus the 471 potential worst case delay due to transmission of another fragment or 472 suspend/resume overhead. Thus, D should be calculated as 474 D = Dlink + FRAG/LinkRate 476 in the case of a fragementing implementation and 478 D = Dlink + pHeader + pDelay 480 for a suspend/resume implementation. 482 4.5 Scheduling Considerations 484 We may think of the link scheduler as having two parts, the first of 485 which schedules packets for transmission before passing them to the 486 second part of the scheduler -- the link level scheduler -- which is 487 responsible for fragmenting packets, mapping them to classes, and 488 scheduling among the classes. 490 In the dynamic class mapping mode of Section 3.3, when deciding which 491 class to assign a packet to, the link level scheduler should take 492 account of the sizes of other packets currently assigned to the same 493 class. In particular, packets with the tightest delay constraints 494 should not be assigned to classes for which relatively large packets 495 are in the process of being transmitted. 497 In either the dynamic or the static class mapping approach, note that 498 the link-level scheduler SHOULD control how much link bandwidth is 499 assigned to each class at any instant. The scheduler should assign 500 bandwidth to a class according to the bandwidth reserved for the sum 501 of all flows which currently have packets assigned to the class. Note 502 that in the example of Section 3.3, when packets from flows A and E 503 were assigned to the same class (class 1), the scheduler assigned more 504 bandwidth to class 1, reflecting the fact that it was carrying traffic 505 from reservations totaling 20kbit/s while the other classes were 506 carrying only 10kbit/s. 508 5. Security Considerations 510 General security considerations for MLPPP and PPP links are addressed 511 in RFC 1990 [12] and RFC 1661 [13], respectively. Security 512 considerations relevant to RSVP, used as the signaling protocol for 513 integrated services, are discussed in RFC 2209 [14]. 515 A specific security consideration relevant to providing quality of 516 service over PPP links appears when relying on either observed or 517 theoretical average packet expansion during admission control due to 518 bit- or byte-stuffing. Implementations based on these 519 packet-expansion values contain a potential vulnerability to denial of 520 service attacks. An adversary could intentionally send traffic that 521 will result in worst case bit- or byte stuffing packet expansion. This 522 in turn could result in quality of service guarantees not being met 523 for other flows due to overly permissive admission control. This 524 potential denial of service attack argues strongly for using a worst 525 case expansion factor in admission control calculations, even for 526 controlled load service. 528 Beyond the considerations documented above, this document introduces 529 no new security issues on top of those discussed in the companion 530 ISSLL documents [1], [2] and [3] and AVT document [4]. Any use of 531 these service mappings assumes that all requests for service are 532 authenticated appropriately. 534 6. References 536 [1] C. Bormann, "Providing integrated services over low-bitrate 537 links", Work in Progress (draft-ietf-issll-isslow-05.txt), April 538 1999. 540 [2] C. Bormann, "The Multi-Class Extension to Multi-Link PPP", 541 Work in Progress (draft-ietf-issll-isslow-mcml-05.txt), 542 April 1999. 544 [3] C. Bormann, "PPP in a real-time oriented HDLC-like framing", 545 Work in Progress (draft-ietf-issll-isslow-rtf-04.txt), 546 April 1999. 548 [4] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for 549 Low-Speed Serial Links", RFC 2508, February 1999. 551 [5] J. Wroclawski, "Specification of the Controlled-Load Network 552 Element Service", RFC 2211, September 1997. 554 [6] C. Partridge, R. Guerin, "Specification of Guaranteed Quality 555 of Service", RFC 2212, September 1997. 557 [7] S. Shenker, J. Wroclawski, "General Characterization Parameters 558 for Integrated Service Network Elements", RFC 2215, 559 September 1997. 561 [8] V. Jacobson, "TCP/IP Compression for Low-Speed Serial Links", 562 RFC 1144. 564 [9] B. Davie et al. "Integrated Services in the Presence of 565 Compressible Flows", Work in Progress 566 (draft-davie-intserv-compress-00.txt), Feb. 1999. 568 [10] M. Engan, S. Casner, C. Bormann, "IP Header Compression over PPP", 569 RFC 2509, February 1999. 571 [11] S. Bradner, "Key words for use in RFCs to Indicate Requirement 572 Levels", RFC 2119, March 1997. 574 [12] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradettim "The PPP 575 Multilink Protocol (MP)", RFC 1990, August 1996. 577 [13] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, July 578 1994. 580 [14] R. Braden, L. Zhang, "Resource ReSerVation Protocol (RSVP) -- 581 Version 1 Message Processing Rules", RFC 2209, September 1997. 583 7. Authors' Addresses: 585 Steve Jackowski 586 Deterministic Networks, Inc. 587 245M Mt Hermon Rd, #140 588 Scotts Valley, CA 95060 589 USA 590 +1 (408) 813 6294 591 stevej@DeterministicNetworks.com 593 David Putzolu 594 Intel Architecture Labs (IAL) 595 JF3-206-H10 596 2111 NE 25th Avenue 597 Hillsboro, OR 97124-5961 598 USA 599 +1 (503) 264 4510 600 David.Putzolu@intel.com 602 Eric S. Crawley 603 Argon Networks, Inc. 604 25 Porter Road 605 Littleton, MA 01460 606 USA 607 esc@argon.com 608 +1 (978) 486-0665 609 Bruce Davie 610 Cisco Systems, Inc. 611 250 Apollo Drive 612 Chelmsford, MA, 01824 613 USA 614 bdavie@cisco.com 615 +1 (978) 244 8921 617 Acknowledgements 619 This document draws heavily on the work of the ISSLL WG of the IETF. 621 Appendix A. Admission Control Considerations for POTS Modems 623 The protocols used in current implementations of POTS modems can 624 exhibit significant changes in link rate and delay over the duration 625 of a connection. Admission control and link scheduling algorithms used 626 with these devices MUST be prepared to compensate for this variability 627 in order to provide a robust implementation of integrated services. 629 Link rate on POTS modems is typically reported at connection 630 time. This value may change over the duration of the connection. The 631 v.34 protocol, used in most POTS modems, is adaptive to link 632 conditions, and is able to recalibrate transmission rate multiple 633 times over the duration of a connection. Typically this will result in 634 a small (~10%) increase in transmission rate over the initial 635 connection within the first minute of a call. It is important to note, 636 however, that other results are possible as well, including decreases 637 in available bandwidth. Admission control algorithms MUST take such 638 changes into consideration as they occur, and implementations MUST be 639 able to gracefully handle the pathological case where link rate 640 actually drops below the currently reserved capacity of a link. 642 Delay experienced by traffic over POTS modems can vary significantly 643 over time. Unlike link rate, the delay often does not converge to a 644 stable value. The v.42 protocol is used in most POTS modems to 645 provide link-layer reliability. This reliability, which is implemented 646 via retransmission, can cause frames to experience significant delays. 647 Retransmissions also implicitly steal link bandwidth from other 648 traffic. These delays and reductions in link bandwidth make it 649 extremely difficult to honor a guaranteed service reservation. On a 650 link that is actually lightly or moderately loaded, a controlled load 651 service can to some extent accept such events as part of the behavior 652 of a lightly loaded link. Unfortunately, as actual link utilization 653 increases, v.42 retransmissions have the potential of stealing larger 654 and larger fractions of available link bandwidth; making even 655 controlled load service difficult to offer at high link utilization 656 when retransmissions occur.