idnits 2.17.1 draft-ietf-issll-is802-svc-mapping-02.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. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 9) being 517 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 Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security Considerations' ) ** 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 an Authors' Addresses Section. ** There are 6 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 744 has weird spacing: '...utation of ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1998) is 9358 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 640 looks like a reference -- Missing reference section? '2' on line 642 looks like a reference -- Missing reference section? '6' on line 661 looks like a reference -- Missing reference section? '7' on line 664 looks like a reference -- Missing reference section? '5' on line 691 looks like a reference -- Missing reference section? '8' on line 667 looks like a reference -- Missing reference section? '10' on line 692 looks like a reference -- Missing reference section? '9' on line 672 looks like a reference -- Missing reference section? '11' on line 681 looks like a reference -- Missing reference section? '3' on line 649 looks like a reference -- Missing reference section? '4' on line 652 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft M. Seaman 3 Expires February 1999 3Com 4 draft-ietf-issll-is802-svc-mapping-02.txt A. Smith 5 Extreme Networks 6 E. Crawley 7 Argon Networks 8 J. Wroclawski 9 MIT LCS 10 August 1998 12 Integrated Service Mappings on IEEE 802 Networks 14 Status of this Memo 16 This document is an Internet Draft. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its Areas, 18 and its Working Groups. Note that other groups may also distribute 19 working documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months. Internet Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet 24 Drafts as reference material or to cite them other than as a "working 25 draft" or "work in progress." 27 To view the entire list of current Internet-Drafts, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 This document is a product of the IS802 subgroup of the ISSLL working 34 group of the Internet Engineering Task Force. Comments are solicited 35 and should be addressed to the working group's mailing list at 36 issll@mercury.lcs.mit.edu and/or the authors. Copyright (C) The 37 Internet Society (1998). All Rights Reserved. 39 Abstract 41 This document describes mappings of IETF Integrated Services over 42 LANs built from IEEE 802 network segments which may be interconnected 43 by IEEE 802.1 MAC Bridges (switches) [1][2]. 45 9 47 9 Seaman,Smith,Crawley,Wroclawski. Expires February 1999 48 It describes parameter mappings for supporting Controlled Load [6] 49 and Guaranteed Service [7] using the inherent capabilities of 50 relevant IEEE 802 technologies and, in particular, 802.1D-1998 51 queuing features in switches [2]. 53 These mappings are one component of the Integrated Services over IEEE 54 802 LANs framework described in [5]. 56 1. Introduction 58 The IEEE 802.1 Interworking Task Group has developed a set of 59 enhancements to the basic MAC Service provided in Bridged Local Area 60 Networks (a.k.a. "switched LANs"). As a supplement to the original 61 IEEE MAC Bridges standard, IEEE 802.1D-1990 [1], the updated IEEE 62 802.1D-1998 [2] proposes differential traffic class queuing in 63 switches and extends the capabilities of Ethernet/802.3 media to 64 carry a traffic class indicator, or "user_priority" field, within 65 data frames [8]. 67 The availability of this differential traffic queuing, together with 68 additional mechanisms to provide admission control and signaling, 69 allows IEEE 802 networks to support a close approximation of the 70 IETF-defined Integrated Services capabilities [6][7]. This document 71 describes methods for mapping the service classes and parameters of 72 the IETF model into IEEE 802.1D network parameters. A companion 73 document [10] describes a signaling protocol for use with these 74 mappings. It is recommended that readers be familiar with the 75 overall framework in which these mappings and signaling protocol are 76 expected to be used; this framework is described fully in [5]. 78 Within this document, Section 2 describes the method by which end 79 systems and routers bordering the IEEE Layer-2 cloud learn what 80 traffic class should be used for each data flow's packets. Section 3 81 describes the approach recommended to map IP-level traffic flows to 82 IEEE traffic classes within the Layer 2 network. Section 4 describes 83 the computation of Characterization Parameters by the layer 2 84 network. The remaining sections discuss some particular issues with 85 the use of the RSVP/SBM signaling protocols, and describe the 86 applicability of all of the above to different layer 2 network 87 topologies. 89 9 91 9 Seaman,Smith,Crawley,Wroclawski. Expires February 1999 92 2. Flow Identification and Traffic Class Selection 94 One model for supporting integrated services over specific link 95 layers treats layer-2 devices very much as a special case of routers. 96 In this model, switches and other devices along the data path make 97 packet handling decisions based on the RSVP flow and filter 98 specifications, and use these specifications to classify the 99 corresponding data packets. The specifications could either be used 100 directly, or could be used indirectly by mapping each RSVP session 101 onto a layer-2 construct such as an ATM virtual circuit. 103 This approach is inappropriate for use in the IEEE 802 environment. 104 Filtering to the per-flow level becomes expensive with increasing 105 switch speed; devices with such filtering capabilities are likely to 106 have a very similar implementation complexity to IP routers, and may 107 not make use of simpler mechanisms such as 802.1D user priority. 109 The Integrated Services over IEEE 802 LANs framework [5] and this 110 document use an "aggregated flow" approach based on use of layer 2 111 traffic classes. In this model, each arriving flow is assigned to one 112 of the available layer-2 classes, and traverses the 802 cloud in this 113 class. Traffic flows requiring similar service are grouped together 114 into a single class, while the system's admission control and class 115 selection rules ensure that the service requirements for flows in 116 each of the classes are met. In many situations this is a viable 117 intermediate point between no QoS control and full router- type 118 integrated services. The approach can work effectively even with 119 switches implementing only the simplest differential traffic 120 classification capability specified in the 802.1D model. 122 In the aggregated flow model, traffic arriving at the boundary of a 123 layer 2 cloud is tagged by the boundary device (end host or border 124 router) with an appropriate traffic class, represented as an 802.1D 125 "user_priority" value. Two fundamental questions are "who determines 126 the correspondence between IP-level traffic flows and link-level 127 classes?" and "how is this correspondence conveyed to the boundary 128 devices that must mark the data frames?" 130 One approach to answering these questions would be for the meanings 131 of the classes to be universally defined. This document would then 132 standardise the meanings of a set of classes; e.g. 1 = best effort, 2 133 = 100 ms peak delay target, 3 = 10 ms peak delay target, 4 = 1 ms 134 peak delay target, etc. The meanings of these universally defined 135 classes could then be encoded directly in end stations, and the 136 flow-to-class mappings computed directly in these devices. 138 Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page 139 3] 140 This universal definition approach would be simple to implement, but 141 is too rigid to map the wide range of possible user requirements onto 142 the limited number of available 802.1D classes. The model described 143 in [5] uses a more flexible mapping: clients ask "the network" which 144 user_priority traffic class to use for a given traffic flow, as 145 categorised by its flow-spec and layer-2 endpoints. The network 146 provides a value back to the requester that is appropriate 147 considering the current network topology, load conditions, other 148 admitted flows, etc. The task of configuring switches with this 149 mapping (e.g. through network management, a switch-switch protocol or 150 via some network-wide QoS-mapping directory service) is an order of 151 magnitude less complex than performing the same function in end 152 stations. Also, when new services (or other network reconfigurations) 153 are added to such a network, the network elements will typically be 154 the ones to be upgraded with new queuing algorithms etc. and can be 155 provided with new mappings at this time. 157 In this model, when a new session or "flow" requiring QoS support is 158 created, a client must ask "the network" which user_priority traffic 159 class to use for a given traffic flow, so that it can label the 160 packets of the flow as it places them into the network. A 161 request/response protocol is needed between client and network to 162 return this information. The request can be piggy-backed onto an 163 admission control request and the response can be piggy-backed onto 164 an admission control acknowledgment. This "one pass" assignment has 165 the benefit of completing the admission control transaction in a 166 timely way and reducing the exposure to changing conditions that 167 could occur if clients cached the knowledge for extensive periods. A 168 set of extensions to the RSVP protocol for communicating this 169 information have been defined[10]. 171 The network (i.e. the first network element encountered downstream 172 from the client) must then answer the following questions: 174 1. Which of the available traffic classes would be appropriate for 175 this flow? 176 In general, a newly arriving flow might be assigned to a number 177 of classes. For example, if 10ms of delay is acceptable, the 178 flow could potentially be assigned to either a 10ms delay class 179 or a 1ms delay class. This packing problem is quite difficult to 180 solve if the target parameters of the classes are allowed to 181 change dynamically as flows arrive and depart. It is quite 182 simple if the target parameters of each class is held fixed, and 183 the class table is simply searched to find a class appropriate 185 Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page 186 4] 187 for the arriving flow. This document adopts the latter approach. 189 2. Of the appropriate traffic classes, which if any have enough 190 capacity available to accept the new flow? 191 This is the admission control problem. It is necessary to 192 compare the level of traffic currently assigned to each class 193 with the available level of network resources (bandwidth, 194 buffers, etc), to ensure that adding the new flow to the class 195 will not cause the class's performance to go below its target 196 values. This problem is compounded because in a priority queuing 197 system adding traffic to a higher-priority class can affect the 198 performance of lower-priority classes. The admission control 199 algorithm for a system using the default 802 priority behavior 200 must be reasonably sophisticated to provide acceptable results. 202 If an acceptable class is found, the network returns the chosen 203 user_priority value to the client. 205 Note that the client may be an end station, a router at the edge 206 of the layer 2 network, or a first switch acting as a proxy for 207 a device that does not participate in these protocols for 208 whatever reason. Note also that a device e.g. a server or router 209 may choose to implement both the "client" as well as the 210 "network" portion of this model so that it can select its own 211 user_priority values. Such an implementation would generally be 212 discouraged unless the device has a close tie-in with the 213 network topology and resource allocation policies. It may, 214 however, work acceptably in cases where there is known over- 215 provisioning of resources. 217 3. Choosing a flow's IEEE 802 user_priority class 219 This section describes the method by which IP-level flows are mapped 220 into appropriate IEEE user_priority classes. The IP-level services 221 considered are Best Effort, Controlled Load, and Guaranteed Service. 223 The major issue is that admission control requests and application 224 requirements are specified in terms of a multidimensional vector of 225 parameters e.g. bandwidth, delay, jitter, service class. This 226 multidimensional space must be mapped onto a set of traffic classes 227 whose default behaviour in L2 switches is unidimensional (i.e. strict 228 priority default queuing). This priority queuing alone can provide 229 only relative ordering between traffic classes. It can neither 231 Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page 232 5] 233 enforce an absolute (quantifiable) delay bound for a traffic class, 234 nor can it discriminate amongst Int-Serv flows within the aggregate 235 in a traffic class. Therefore, it cannot provide the absolute control 236 of packet loss and delay required for individual Int-Serv flows. 238 To provide absolute control of loss and delay three things must 239 occur: 241 (1) The amount of bandwidth available to the QoS-controlled flows 242 must be known, and the number of flows admitted to the network 243 (allowed to use the bandwidth) must be limited. 245 (2) A traffic scheduling mechanism is needed to give preferential 246 service to flows with lower delay targets. 248 (3) Some mechanism must ensure that best-effort flows and QoS 249 controlled flows that are exceeding their Tspecs do not damage 250 the quality of service delivered to in-Tspec QoS controlled 251 flows. This mechanism could be part of the traffic scheduler, or 252 it could be a separate policing mechanism. 254 For IEEE 802 networks, the first function (admission control) is 255 provided by a Subnet Bandwidth Manager, as discussed below. We 256 use the link-level user_priority mechanism at each switch and 257 bridge to implement the second function (preferential service to 258 flows with lower delay targets). Because a simple priority 259 scheduler cannot provide policing (function three), policing for 260 IEEE networks is generally implemented at the edge of the 261 network by a layer-3 device. When this policing is performed 262 only at the edges of the network it is of necessity approximate. 263 This issue is discussed further in [5]. 265 3.1. Context of admission control and delay bounds 267 As described above, it is the combination of priority-based 268 scheduling and admission control that creates quantified delay 269 bounds. Thus, any attempt to quantify the delay bounds expected by a 270 given traffic class has to made in the context of the admission 271 control elements. Section 6 of the framework [5] provides for two 272 different models of admission control - centralized or distributed 273 Bandwidth Allocators. 275 It is important to note that in this approach it is the admission 277 Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page 278 6] 279 control algorithm that determines which of the Int-Serv services is 280 being offered. Given a set of priority classes with delay targets, a 281 relatively simple admission control algorithm can place flows into 282 classes so that the bandwidth and delay behavior experienced by each 283 flow corresponds to the requirements of the Controlled-Load service, 284 but cannot offer the higher assurance of the Guaranteed service. To 285 offer the Guaranteed service, the admission control algorithm must be 286 much more stringent in its allocation of resources, and must also 287 compute the C and D error terms required of this service. 289 A delay bound can only be realized at the admission control element 290 itself so any delay numbers attached to a traffic class represent the 291 delay that a single element can allow for. That element may 292 represent a whole L2 domain or just a single L2 segment. 294 With either admission control model, the delay bound has no scope 295 outside of a L2 domain. The only requirement is that it be understood 296 by all Bandwidth Allocators in the L2 domain and, for example, be 297 exported as C and D terms to L3 devices implementing the Guaranteed 298 Service. Thus, the end-to-end delay experienced by a flow can only be 299 characterized by summing along the path using the usual RSVP 300 mechanisms. 302 3.2. Default service mappings 304 Table 1 presents the default mapping from delay targets to IEEE 802.1 305 user_priority classes. However, these mappings must be viewed as 306 defaults, and must be changeable. 308 In order to simplify the task of changing mappings, this mapping 309 table is held by *switches* (and routers if desired) but generally 310 not by end-station hosts. It is a read-write table. The values 311 proposed below are defaults and can be overridden by management 312 control so long as all switches agree to some extent (the required 313 level of agreement requires further analysis). 315 In future networks this mapping table might be adjusted dynamically 316 and without human intervention. It is possible that some form of 317 network-wide lookup service could be implemented that serviced 318 requests from clients e.g. traffic_class = getQoSbyName("H.323 319 video") and notified switches of what traffic categories they were 320 likely to encounter and how to allocate those requests into traffic 321 classes. Alternatively, the network's admission control mechanisms 322 might directly adjust the mapping table to maximize the utilization 324 Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page 325 7] 326 of network resources. Such mechanisms are for further study. 328 user_priority Service 329 0 Default, assumed to be Best Effort 330 1 reserved, "less than" Best Effort 331 2 reserved 332 3 reserved 333 4 Delay Sensitive, no bound 334 5 Delay Sensitive, 100ms bound 335 6 Delay Sensitive, 10ms bound 336 7 Network Control 338 Table 1 - Example user_priority to service mappings 340 The delay bounds numbers proposed above are for per-Bandwidth 341 Allocator element delay targets and are derived from a subjective 342 analysis of the needs of typical delay-sensitive applications e.g. 343 voice, video. See Annex H of [2] for further discussion of the 344 selection of these values. Although these values appear to address 345 the needs of current video and voice technology, it should be noted 346 that there is no requirement to adhere to these values and no 347 dependence of IEEE 802.1 on these values. 349 Note: These mappings are believed to be useful defaults but further 350 implementation and usage experience is required. The mappings may be 351 refined in future editions of this document. 353 With this example set of mappings, delay-sensitive, admission 354 controlled traffic flows are mapped to user_priority values in 355 ascending order of their delay bound requirement. Note that the 356 bounds are targets only - see [5] for a discussion of the effects of 357 other non-conformant flows on delay bounds of other flows. Only by 358 applying admission control to higher-priority classes can any 359 promises be made to lower-priority classes. 361 This set of mappings also leaves several classes as reserved for 362 future definition. 364 Note: this mapping does not dictate what mechanisms or algorithms a 365 network element (e.g. an Ethernet switch) must perform to implement 366 these mappings: this is an implementation choice and does not matter 367 so long as the requirements for the particular service model are met. 369 Note: these mappings apply primarily to networks constructed from 370 devices that implement the priority-scheduling behavior defined as 372 Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page 373 8] 374 the default in 802.1D. Some devices may implement more complex 375 scheduling behaviors not based only on priority. In that circumstance 376 these mappings might still be used, but other, more specialized 377 mappings may be more appropriate. 379 3.3. Discussion 381 The recommendation of classes 4, 5 and 6 for Delay Sensitive, 382 Admission Controlled flows is somewhat arbitrary; any classes with 383 priorities greater than that assigned to Best Effort can be used. 384 Those proposed here have the advantage that, for transit through 385 802.1D switches with only two-level strict priority queuing, all 386 delay-sensitive traffic gets "high priority" treatment (the 802.1D 387 default split is 0-3 and 4-7 for a device with 2 queues). 389 The choice of the delay bound targets is tuned to an average expected 390 application mix, and might be retuned by a network manager facing a 391 widely different mix of user needs. The choice is potentially very 392 significant: wise choice can lead to a much more efficient allocation 393 of resources as well as greater (though still not very good) 394 isolation between flows. 396 Placing Network Control traffic at class 7 is necessary to protect 397 important traffic such as route updates and network management. 398 Unfortunately, placing this traffic higher in the user_priority 399 ordering causes it to have a direct effect on the ability of devices 400 to provide assurances to QoS controlled application traffic. 401 Therefore, an estimate of the amount of Network Control traffic must 402 be made by any device that is performing admission control (e.g. 403 SBMs). This would be in terms of the parameters that are normally 404 taken into account by the admission control algorithm. This estimate 405 should be used in the admission control decisions for the lower 406 classes (the estimate is likely to be a configuration parameter of 407 SBMs). 409 A traffic class such as class 1 for "less than best effort" might be 410 useful for devices that wish to dynamically "penalty tag" all of the 411 data of flows that are presently exceeding their allocation or Tspec. 412 This provides a way to isolate flows that are exceeding their service 413 limits from flows that are not, to avoid reducing the QoS delivered 414 to flows that are within their contract. Data from such tagged flows 415 might also be preferentially discarded by an overloaded downstream 416 device. 417 9 419 9 Seaman,Smith,Crawley,Wroclawski. Expires February 1999 420 A somewhat simpler approach would be to tag only the portion of a 421 flow's packets that actually exceed the Tspec at any given instant as 422 low priority. However, it is often considered to be a bad idea to 423 treat flows in this way as it will likely cause significant re- 424 ordering of the flow's packets, which is not desirable. Note that the 425 default 802.1D treatment of user_priorities 1 and 2 is "less than" 426 the default class 0. 428 4. Computation of integrated services characterization parameters by 429 IEEE 802 devices 431 The integrated service model requires that each network element that 432 supports integrated services compute and make available certain 433 "characterization parameters" describing the element's behavior. 434 These parameters may be either generally applicable or specific to a 435 particular QoS control service. These parameters may be computed by 436 calculation, measurement, or estimation. When a network element 437 cannot compute its own parameters (for example, a simple link), we 438 assume that the device sending onto or receiving data from the link 439 will compute the link's parameters as well as it's own. 441 The accuracy of calculation of these parameters may not be very 442 critical; in some cases loose estimates are all that is required to 443 provide a useful service. This is important in the IEEE 802 case, 444 where it will be virtually impossible to compute parameters 445 accurately for certain topologies and switch technologies. Indeed, it 446 is an assumption of the use of this model by relatively simple 447 switches (see [5] for a discussion of the different types of switch 448 functionality that might be expected) that they merely provide values 449 to describe the device and admit flows conservatively. 451 The discussion below presents a general outline for the computation 452 of these parameters, and points out some cases where the parameters 453 must be computed accurately. Further specification of how to export 454 these parameters is for further study. 456 4.1. General characterization parameters 458 There are some general parameters [9] that a device will need to use 459 and/or supply for all service types: 461 * Ingress link 463 Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page 464 10] 465 * Egress links and their MTUs, framing overheads and minimum 466 packet sizes (see media-specific information presented above). 468 * available path bandwidth: updated hop-by-hop by any device along 469 the path of the flow. 471 * minimum latency 473 Of these parameters, the MTU and minimum packet size information 474 must be reported accurately. Also, the "break bits" must be set 475 correctly, both the overall bit that indicates the existence of 476 QoS control support and the individual bits that specify support 477 for a particular scheduling service. The available bandwidth 478 should be reported as accurately as possible, but very loose 479 estimates are acceptable. The minimum latency parameter should 480 be determined and reported as accurately as possible if the 481 element offers Guaranteed service, but may be loosely estimated 482 or reported as zero if the element offers only Controlled-Load 483 service. 485 4.2. Parameters to implement Guaranteed Service 487 A network element supporting the Guaranteed Service must be able to 488 determine the following parameters [7]: 490 * Constant delay bound through this device (in addition to any 491 value provided by "minimum latency" above) and up to the 492 receiver at the next network element for the packets of this 493 flow if it were to be admitted. This includes any access 494 latency bound to the outgoing link as well as propagation delay 495 across that link. This value is advertised as the "C" parameter 496 of the Guaranteed Service. 498 * Rate-proportional delay bound through this device and up to the 499 receiver at the next network element for the packets of this 500 flow if it were to be admitted. This value is advertised as the 501 "D" parameter of the Guaranteed Service. 503 * Receive resources that would need to be associated with this 504 flow (e.g. buffering, bandwidth) if it were to be admitted and 505 not suffer packet loss if it kept within its supplied 506 Tspec/Rspec. These values are used by the admission control 507 algorithm to decide whether a new flow can be accepted by the 508 device. 510 Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page 511 11] 512 * Transmit resources that would need to be associated with this 513 flow (e.g. buffering, bandwidth, constant- and rate-proportional 514 delay bounds) if it were to be admitted. These values are used 515 by the admission control algorithm to decide whether a new flow 516 can be accepted by the device. 518 The exported characterization parameters for this service should be 519 reported as accurately as possible. If estimations or approximations 520 are used, they should err in whatever direction causes the user to 521 receive better performance than requested. For example, the C and D 522 error terms should overestimate delay, rather than underestimate it. 524 4.3. Parameters to implement Controlled Load 526 A network element implementing the Controlled Load service must be 527 able to determine the following [6]: 529 * Receive resources that would need to be associated with this 530 flow (e.g. buffering) if it were to be admitted. These values 531 are used by the admission control algorithm to decide whether a 532 new flow can be accepted by the device. 534 * Transmit resources that would need to be associated with this 535 flow (e.g. buffering) if it were to be admitted. These values 536 are used by the admission control algorithm to decide whether a 537 new flow can be accepted by the device. 539 The Controlled Load service does not export any service-specific 540 characterization parameters. Internal resource allocation estimates 541 should ensure that the service quality remains high when considering 542 the statistical aggregation of Controlled Load flows into 802 traffic 543 classes. 545 4.4. Parameters to implement Best Effort 547 For a network element that implements only best effort service there 548 are no explicit parameters that need to be characterized. Note that 549 an integrated services aware network element that implements only 550 best effort service will set the "break bit" described in [11]. 552 Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page 553 12] 554 5. Merging of RSVP/SBM objects 556 Where reservations that use the SBM protocol's TCLASS object [10] 557 need to be merged, an algorithm needs to be defined that is 558 consistent with the mappings to individual user_priority values in 559 use in the network. 561 A merged reservation must receive at least as good a service as the 562 best of the component reservations. In the circumstances considered 563 here, this translates into placing the merged reservation into the 564 lowest delay class of those that could be used for the individual 565 reservations. 567 For the example mappings proposed in this document, the merging 568 device should merge to the "highest" priority value of the values 569 received in TCLASS objects of the PATH/RESV messages where "highest" 570 is defined as follows: 572 Lowest -------> Highest 573 1, 2, 0, 3, 4, 5, 6, 7 575 Note: this counter-intuitive ordering is an artifact of the *default* 576 relative treatment of user_priority values in the IEEE 802.1D 577 specification (see Annex H of [2]). If a device has been configured 578 to apply non-default treatment of user_priority values then it should 579 adjust this merging operation accordingly. 581 6. Applicability of these service mappings 583 Switches using layer-2-only standards (e.g. 802.1D-1990, 802.1D- 584 1998) need to inter-operate with routers and layer-3 switches. Wide 585 deployment of such 802.1D-1998 switches will occur in a number of 586 roles in the network: "desktop switches" provide dedicated 10/100 587 Mbps links to end stations and high speed core switches often act as 588 central campus switching points for layer-3 devices. Layer-2 devices 589 will have to operate in all of the following scenarios: 591 * every device along a network path is layer-3 capable and 592 intrusive into the full data stream 594 * only the edge devices are pure layer-2 596 Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page 597 13] 598 * every alternate device lacks layer-3 functionality 600 * most devices lack layer-3 functionality except for some key 601 control points such as router firewalls, for example. 603 Where int-serv flows pass through equipment which does not support 604 Integrated Services or 802.1D traffic management and which places all 605 packets through the same queuing and overload-dropping paths, it is 606 obvious that some of a flow's desired service parameters become more 607 difficult to support. In particular, the two integrated service 608 classes studied here, Controlled Load and Guaranteed Service, both 609 assume that flows will be policed and kept "insulated" from 610 misbehaving other flows or from best effort traffic during their 611 passage through the network. This cannot be done within an IEEE 802 612 network using devices with the default user_priority function; in 613 this case policing must be approximated at the network edges. 615 In addition, in order to provide a Guaranteed Service, *all* 616 switching elements along the path must participate in special 617 treatment for packets in such flows: where there is a "break" in 618 guaranteed service, all bets are off. Thus, a network path that 619 includes even a single switch transmitting onto a shared or half- 620 duplex LAN segment is unlikely to be able to provide a very good 621 approximation to Guaranteed Service. For Controlled Load service, the 622 requirements on the switches and link types are less stringent 623 although it is still necessary to provide differential queueing and 624 buffering in switches for CL flows over best effort in order to 625 approximate CL service. Note that users receive indication of such 626 breaks in the path through the "break bits" described in [11]. These 627 bits must be correctly set when IEEE 802 devices that cannot provide 628 a specific service exist in a network. 630 Other approaches might be to pass more information between switches 631 about the capabilities of their neighbours and to route around non- 632 QoS-capable switches: such methods are for further study. And of 633 course the easiest solution of all is to upgrade links and switches 634 to higher capacities. 636 Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page 637 14] 638 7. References 640 [1] "MAC Bridges", ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993 642 [2] "Information technology - Telecommunications and information 643 exchange between systems - Local and metropolitan area networks 644 - Common specifications - Part 3: Media Access Control (MAC) 645 Bridges: Revision (Incorporating IEEE P802.1p: Traffic Class 646 Expediting and Dynamic Multicast Filtering", ISO/IEC Final CD 647 15802-3 IEEE P802.1D/D15, November 1997 649 [3] Clark, D. et al. "Integrated Services in the Internet 650 Architecture: an Overview" RFC1633, June 1994 652 [4] Braden, R., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource 653 Reservation Protocol (RSVP) - Version 1 Functional 654 Specification", RFC 2205, September 1997 656 [5] Ghanwani, A., Pace, W., Srinivasan, V., Smith, A., Seaman, M., 657 "A Framework for Providing Integrated Services Over Shared and 658 Switched LAN Technologies", Internet Draft, March 1998 661 [6] Wroclawski, J., "Specification of the Controlled-Load Network 662 Element Service", RFC 2211, September 1997 664 [7] Schenker, S., Partridge, C., Guerin, R., "Specification of 665 Guaranteed Quality of Service", RFC 2212 September 1997 667 [8] 668 "IEEE Standards for Local and Metropolitan Area Networks: for 669 Virtual Bridged Local Area Networks", March 1998, IEEE Draft 670 Standard P802.1Q/D10 672 [9] Shenker, S., Wroclawski, J., "General Characterization 673 Parameters for Integrated Service Network Elements", RFC 2215, 674 September 1997 676 [10] Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F., Speer, M., 677 "SBM (Subnet Bandwidth Manager): A Protocol for Admission 678 Control over IEEE 802-style Networks", Internet Draft, March 679 1998 681 [11] Wroclawski, J., "The use of RSVP with IETF Integrated Services", 682 RFC 2210, September 1997. 684 Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page 685 15] 686 8. Security Considerations 688 Any use of QoS requires examination of security considerations 689 because it leaves the possibility open for denial of service or theft 690 of service attacks. This document introduces no new security issues 691 on top of those discussed in the companion ISSLL documents [5] and 692 [10]. Any use of these service mappings assumes that all requests 693 for service are authenticated appropriately. 695 9. Acknowledgments 697 This document draws heavily on the work of the ISSLL WG of the IETF 698 and the IEEE P802.1 Interworking Task Group. 700 9. Authors' Addresses 702 Mick Seaman 703 3Com Corp. 704 5400 Bayfront Plaza 705 Santa Clara CA 95052-8145 706 USA 707 +1 (408) 764 5000 708 mick_seaman@3com.com 710 Andrew Smith 711 Extreme Networks 712 10460 Bandley Drive 713 Cupertino CA 95014 714 USA 715 +1 (408) 863 2821 716 andrew@extremenetworks.com 718 Eric Crawley 719 Argon Networks 720 25 Porter Rd. 721 Littleton MA 01460 722 USA 723 +1 (978) 486 0665 724 esc@argon.com 726 Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page 727 16] 728 John Wroclawski 729 MIT Laboratory for Computer Science 730 545 Technology Sq. 731 Cambridge, MA 02139 732 USA 733 +1 (617) 253 7885 734 jtw@lcs.mit.edu 736 Table of Contents 738 1 Introduction ................................................. 2 739 2 Flow Identification and Traffic Class Selection .............. 3 740 3 Choosing a flow's IEEE 802 user_priority class ............... 5 741 3.1 Context of admission control and delay bounds .............. 6 742 3.2 Default service mappings ................................... 7 743 3.3 Discussion ................................................. 9 744 4 Computation of integrated services characterization 745 parameters by IEEE 802 devices ............................ 10 746 4.1 General characterization parameters ........................ 10 747 4.2 Parameters to implement Guaranteed Service ................. 11 748 4.3 Parameters to implement Controlled Load .................... 12 749 4.4 Parameters to implement Best Effort ........................ 12 750 5 Merging of RSVP/SBM objects .................................. 13 751 6 Applicability of these service mappings ...................... 13 752 7 References ................................................... 15 753 8 Security Considerations ...................................... 16 754 9 Authors' Addresses ........................................... 16 756 Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page 757 17] 758 Copyright (C) The Internet Society (date). All Rights 759 Reserved. 761 This document and translations of it may be copied and 762 furnished 763 to others, and derivative works that comment on or otherwise 764 explain it or assist in its implmentation may be prepared, 765 copied, 766 published and distributed, in whole or in part, without 767 restriction of any kind, provided that the above copyright 768 notice 769 and this paragraph are included on all such copies and 770 derivative 771 works. However, this document itself may not be modified in 772 any 773 way, such as by removing the copyright notice or references to 774 the 775 Internet Society or other Internet organizations, except as 776 needed 777 for the purpose of developing Internet standards in which case 778 the 779 procedures for copyrights defined in the Internet Standards 780 process must be followed, or as required to translate it into 781 languages other than English. 783 The limited permissions granted above are perpetual and will 784 not 785 be revoked by the Internet Society or its successors or 786 assigns. 788 This document and the information contained herein is provided 789 on 790 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 791 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 792 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 793 OF 794 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 795 IMPLIED 796 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 797 PURPOSE. 799 Seaman,Smith,Crawley,Wroclawski. Expires February 1999 [Page 800 18]