idnits 2.17.1 draft-ietf-issll-is802-svc-mapping-01.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-18) 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. ** 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 9 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 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. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1997) is 9651 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 379, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 395, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Mick Seaman 3 Expires May 1998 3Com 4 draft-ietf-issll-is802-svc-mapping-01.txt Andrew Smith 5 Extreme Networks 6 Eric Crawley 7 Argon Networks 8 November 1997 10 Integrated Service Mappings on IEEE 802 Networks 12 Status of this Memo 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet 22 Drafts as reference material or to cite them other than as a "working 23 draft" or "work in progress." 25 To view the entire list of current Internet-Drafts, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). This document is a product of the IS802 30 subgroup of the ISSLL working group of the Internet Engineering Task 31 Force. Comments are solicited and should be addressed to the working 32 group's mailing list at issll@mercury.lcs.mit.edu and/or the authors. 34 Abstract 36 This document describes mappings of IETF Integrated Services over LANs 37 built from IEEE 802 network segments which may be interconnected by IEEE 38 802.1 MAC Bridges (switches) [1][2]. 40 It describes parameter mappings for supporting Controlled Load [6] and 41 Guaranteed Service [7] using the inherent capabilities of relevant IEEE 42 802 technologies and 802.1D/802.1p queuing features in switches [2]. 44 These mappings fit in with the ISSLL over 802 LANs framework described 45 in [5]. 47 1. Introduction 49 The IEEE 802.1 Interworking Task Group has recently agreed on 50 enhancements to the basic MAC Service provided in Bridged Local Area 51 Networks (a.k.a. "switched LANs"). As a supplement to the original IEEE 52 MAC Bridges standard [1], the update P802.1p [2] proposes differential 53 traffic class queuing and access to media on the basis of a 54 "user_priority" signaled in frames. 56 In this document we summarise the model for selecting traffic classes 57 described in the framework [5] and how we identify those classes in 58 data-link layer devices. We then discuss how to map the existing IETF- 59 defined Integrated Services onto the ISSLL 802 traffic class model, 60 propose an example of particular choices of traffic class, discuss some 61 particular issues with the use of RSVP/SBM signaling protocols and 62 discuss the applicability of all of the above in some different network 63 topologies. 65 It is recommended that readers be familiar with the framework in which 66 these mappings are expected to be used - this is described fully in [5]. 68 2. Selecting traffic classes 70 One fundamental question is "who gets to decide what the classes mean 71 and who gets access to them?" One approach would be for the meanings of 72 the classes to be "well-known": we would then need to standardise a set 73 of classes e.g. 1 = best effort, 2 = controlled- load, 3 = guaranteed 74 (loose delay bound, high bandwidth), 4 = guaranteed (slightly tighter 75 delay) etc. The values to encode in such a table in end stations, in 76 isolation from the network to which they are connected, is 77 problematical: one approach could be to define one user_priority value 78 per int-serv service and leave it at that (reserving the rest of the 79 combinations for future traffic classes). 81 The model described in [5] uses a more flexible mapping: clients ask 82 "the network" which user_priority traffic class to use for a given 83 traffic flow, as categorised by its flow-spec and layer-2 endpoints. The 84 network provides a value back to the requester which is appropriate to 85 the current network topology, load conditions, other admitted flows etc. 86 The task of configuring switches with this mapping (e.g. through network 87 management, a switch-switch protocol or via some network-wide QoS- 88 mapping directory service) is an order of magnitude less complex than 89 performing the same function in end stations. Also, when new services 90 (or other network reconfigurations) are added to such a network, the 91 network elements will typically be the ones to be upgraded with new 92 queuing algorithms etc. and can be provided with new mappings at this 93 time. 95 Given the need for a new session or "flow" requiring some QoS support, a 96 client then needs answers to the following questions: 98 1. which traffic class do I add this flow to? 99 The client needs to know how to label the packets of the flow as it 100 places them into the network. 102 2. who do I ask/tell? 103 The client asks "the network" which user_priority traffic class to 104 use for a given traffic flow. 106 3. how do I ask/tell them? 107 A request/response protocol is needed between client and network: in 108 fact, the request can be piggy-backed onto an admission control 109 request and the response can be piggy-backed onto an admission 110 control acknowledgment: this "one pass" assignment has the benefit of 111 completing the admission control in a timely way and reducing the 112 exposure to changing conditions which could occur if clients cached 113 the knowledge for extensive periods. ISSLL WG has defined extensions 114 to the RSVP protocol for communicating this information [10]. 116 The network (i.e. the first network element encountered downstream from 117 the client) must then answer the following questions: 119 1. to which traffic class do I add this flow? 120 This is a packing problem, difficult to solve in general, but many 121 simplifying assumptions can be made: presumably some simple form of 122 allocation can be done without a more complex scheme able to 123 dynamically shift flows around between classes. 125 2. which traffic class has worst-case parameters which meet the needs of 126 this flow? 127 This might be an ordering/comparison problem: which of two service 128 classes is "better" than the other? Again, we can make this tractable 129 by observing that all of the current int- serv classes can be ranked 130 (best effort <= Controlled Load <= Guaranteed Service) in a simple 131 manner. If any classes are implemented in the future that cannot be 132 simply ranked then the issue can be finessed by either a priori 133 knowledge about what classes are supported or by configuration. 135 and return the chosen user_priority value to the client. 137 Note that the client may be either an end station, router or a first 138 switch which may be acting as a proxy for a client which does not 139 participate in these protocols for whatever reason. Note also that a 140 device e.g. a server or router, may choose to implement both the 141 "client" as well as the "network" portion of this model so that it can 142 select its own user_priority values: such an implementation would, 143 however, be discouraged unless the device really does have a close tie- 144 in with the network topology and resource allocation policies but would 145 work in some cases where there is known over- provisioning of resources. 147 3. Flow Identification 149 Some other models for int-serv over lower-layers treat layer-2 switches 150 very much as a special case of routers: in particular, that switches 151 along the data path will make packet handling decisions based on the 152 RSVP flow and filter specifications and use them to classify the 153 corresponding data packets. However, filtering to the per-flow level 154 becomes expensive with increasing switch speed: devices with such 155 filtering capabilities are unlikely to have a very different 156 implementation complexity from IP routers and there already exist IETF 157 protocol specifications for those devices [4]. 159 This memo uses "aggregated flow" identification based on data-link layer 160 "user_priority" as a viable intermediate point between no QoS and full 161 router-type integrated services and this is the minimum flow 162 classification capability required of switches in the "ISSLL over IEEE 163 802 networks" model. 165 4. Mappings of int-serv characterisation parameters for IEEE 802 devices 167 It is assumed that admission control will be applied when deciding 168 whether or not to admit a new flow through a given network element and 169 that a device sending onto a link will be proxying the parameters and 170 admission control decisions on behalf of that link: this process will 171 require the device to be able to determine (by estimation, measurement 172 or calculation) several parameters. It is assumed that details of the 173 potential flow are provided to the device by some means (e.g. a 174 signaling protocol, network management). The service definition 175 specifications themselves provide some implementation guidance as to how 176 to calculate some of these quantities. 178 The accuracy of calculation of these parameters may not be very 179 critical: indeed it is an assumption of the use of this model by 180 relatively simple switches ("Class I" according to the taxonomy 181 presented in [5]) that they merely provide values to describe the device 182 and admit flows conservatively. 184 4.1 General characterisation parameters 185 There are some general parameters [9] that a device will need to use 186 and/or supply for all service types: 187 * Ingress link 188 * Egress links and their MTUs, framing overheads and minimum packet 189 sizes (see media-specific information presented above). 190 * available path bandwidth: updated hop-by-hop by any device along the 191 path of the flow. 192 * minimum latency 194 4.2 Parameters to implement Guaranteed Service 196 A network element must be able to determine the following parameters 197 [7]: 199 * Constant delay bound through this device (in addition to any value 200 provided by "minimum latency" above) and up to the receiver at the next 201 network element for the packets of this flow if it were to be admitted: 202 this would include any access latency bound to the outgoing link as well 203 as propagation delay across that link. 204 * Rate-proportional delay bound through this device and up to the 205 receiver at the next network element for the packets of this flow if it 206 were to be admitted. 207 * Receive resources that would need to be associated with this flow 208 (e.g. buffering, bandwidth) if it were to be admitted and not suffer 209 packet loss if it kept within its supplied Tspec/Rspec. 210 * Transmit resources that would need to be associated with this flow 211 (e.g. buffering, bandwidth, constant- and rate-proportional delay 212 bounds) if it were to be admitted. 214 4.3 Parameters to implement Controlled Load 216 A network element must be able to determine the following parameters 217 which can be extracted from [6]: 219 * Receive resources that would need to be associated with this flow 220 (e.g. buffering) if it were to be admitted. 221 * Transmit resources that would need to be associated with this flow 222 (e.g. buffering) if it were to be admitted. 224 4.4 Parameters to implement Best Effort 226 For a network element to implement best effort service there are no 227 explicit parameters that need to be characterised. 229 5. Mapping to IEEE 802 user_priority 231 There are many options available for mapping aggregations of flows 232 described by int-serv service models (Best Effort, Controlled Load, and 233 Guaranteed are the services considered here) onto user_priority classes. 234 The following mappings are presented as an example set in order to 235 stimulate experimentation in this area - they may be refined in future 236 editions of this memo. Note, this does not dictate what 237 mechanisms/algorithms a network element (e.g. an Ethernet switch) needs 238 to perform to implement these mappings: this is an implementation choice 239 and does not matter so long as the requirements for the particular 240 service model are met. In order to reduce the administrative problems, 241 such a mapping table is held by *switches* (and routers if desired) but 242 generally not by end-station hosts and is a read-write table. The values 243 proposed below are defaults and can be overridden by management control 244 so long as all switches agree to some extent (the required level of 245 agreement requires further analysis). 247 It is possible that some form of network-wide lookup service could be 248 implemented that serviced requests from clients e.g. traffic_class = 249 getQoSbyName("H.323 video") and notified switches of what sorts of 250 traffic categories they were likely to encounter and how to allocate 251 those requests into traffic classes: such mechanisms are for further 252 study. 254 user_priority Service 256 0 Default, assumed to be Best Effort 257 1 Background, "less than" Best Effort 258 2 reserved 259 3 reserved 260 4 Controlled Load 261 5 Guaranteed Service, 100ms bound 262 6 Guaranteed Service, 10ms bound 263 7 reserved 265 Table 1 - Example user_priority top service mappings 267 With this example set of mappings, all traffic that uses the Controlled 268 Load service is mapped to a single user_priority whilst that for 269 Guaranteed Service is placed into one of two user_priority classes with 270 different delay bounds. Unreserved best effort traffic is mapped to 271 another. 273 The use of classes 4, 5 and 6 for Controlled Load and Guaranteed Service 274 is somewhat arbitrary as long as they are increasing. Any two classes 275 greater than Best Effort can be used as long as GS is "greater" than CL 276 although those proposed here have the advantage that, for transit 277 through 802.1p switches with only two-level strict priority queuing, 278 they both get "high priority" treatment (the 802.1p default split is 0-3 279 and 4-7 for a device with 2 queues). The choice of delay bound is also 280 arbitrary but potentially very significant: this can lead to a much more 281 efficient allocation of resources as well as greater (though still not 282 very good) isolation between flows. 284 The "less than best effort" class might be useful e.g. for devices that 285 wish to "penalty tag" all of the data of flows that have abused the 286 network by excessively exceeding their Allocation or profile: these 287 might be preferentially discarded by a downstream device. It would 288 probably be a bad idea to just mark some of the packets of a flow in 289 this way as this will likely cause re-ordering of packets which is 290 generally a bad thing (tm). Note, this is not *required* by any current 291 int-serv models but is under study e.g. in the IETF's Differential 292 Services WG. 294 The advantage to this approach is that it puts some real delay bounds on 295 the Guaranteed Service without adding any additional complexity to the 296 other services. It still ignores the amount of *bandwidth* available 297 for each class. This should behave reasonably well as long as all 298 traffic for CL and GS flows does not exceed any resource capacities in 299 the device. Some isolation between very delay-critical GS and less 300 critical GS flows is provided but there is still an overall assumption 301 that flows will in general be well- behaved. In addition, this mapping 302 still leaves room for future service models. 304 Expanding the number of classes for CL service is not as appealing since 305 there is no need to map to a particular delay bound. There may be cases 306 where an administrator might map CL onto more classes for particular 307 bandwidths or policy levels. It may also be desirable to further 308 subdivide CL traffic in cases where it is frequently non-conformant for 309 certain applications. 311 6. Merging of RSVP/SBM objects 313 Where reservations that use the SBM protocol's TCLASS object [10] need 314 to be merged, an algorithm needs to be defined that is consistent with 315 the mappings to individual user_priority values in use in the network. 317 For the example mappings proposed in this memo, the merging device 318 should merge to the "lowest" priority value of the values received in 319 TCLASS objects of the PATH/RESV messages where "lowest" is defined as 320 follows: 321 Lowest -------> Highest 322 1, 2, 0, 3, 4, 5, 6, 7 324 Note: this counter-intuitive ordering is an artifact of the *default* 325 relative treatment of user_priority values in the IEEE 802.1p 326 specification (see Annex H of [2]). If a device has been configured to 327 apply non-default treatment of user_priority values then it should 328 adjust this merging operation accordingly. 330 7. Applicability of these service mappings 332 Switches using layer-2-only standards (e.g. 802.1D, 802.1p) need to 333 inter-operate with routers and layer-3 switches. Wide deployment of such 334 802.1p switches will occur in a number of roles in the network: "desktop 335 switches" provide dedicated 10/100 Mbps links to end stations and high 336 speed core switches often act as central campus switching points for 337 layer-3 devices. Layer-2 devices will have to operate in all of the 338 following scenarios: 339 * every device along a network path is layer-3 capable and intrusive 340 into the full data stream 341 * only the edge devices are pure layer-2 342 * every alternate device lacks layer-3 functionality 343 * most devices lack layer-3 functionality except for some key control 344 points such as router firewalls, for example. 346 Where int-serv flows pass through equipment which does not support 347 Integrated Services or 802.1p traffic management and which places all 348 packets through the same queuing and overload-dropping paths, it is 349 obvious that some of a flow's desired service parameters become more 350 difficult to support. In particular, the two integrated service classes 351 studied here, Controlled Load and Guaranteed Service, both assume that 352 flows will be policed and kept "insulated" from mis-behaving other flows 353 or from best effort traffic during their passage through the network. 355 In addition, in order to provide a Guaranteed Service, *all* switching 356 elements along the path must participate in special treatment for 357 packets in such flows: where there is a "break" in guaranteed service, 358 all bets are off. Thus, a network path that includes even a single 359 switch transmitting onto a shared or half- duplex LAN segment is 360 unlikely to be able to provide a very good approximation to Guaranteed 361 Service. For Controlled Load service, the requirements on the switches 362 and link types are less stringent although it is still necessary to 363 provide differential queueing and buffering in switches for CL flows 364 over best effort in order to approximate CL service. 366 Other approaches might be to pass more information between switches 367 about the capabilities of their neighbours and to route around non- 368 QoS-capable switches: such methods are for further study. And of course 369 the easiest solution of all is to upgrade links and switches to higher 370 capacities. 372 8. References 374 [1] ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993 "MAC Bridges" 376 [2] "Supplement to MAC Bridges: Traffic Class Expediting and 377 Dynamic Multicast Filtering", September 1997, IEEE P802.1p/D8 379 [3] "Integrated Services in the Internet Architecture: an Overview" 380 RFC1633, June 1994 382 [4] "Resource Reservation Protocol (RSVP) - Version 1 Functional 383 Specification", RFC 2205, September 1997 385 [5] "A Framework for Providing Integrated Services Over Shared and 386 Switched LAN Technologies", Internet Draft, November 1997 387 389 [6] "Specification of the Controlled-Load Network Element Service", 390 RFC 2211, September 1997 392 [7] "Specification of Guaranteed Quality of Service", 393 RFC 2212 September 1997 395 [8] "Draft Standard for Virtual Bridged Local Area Networks", 396 October 1997, IEEE P802.1Q/D8 398 [9] "General Characterization Parameters for Integrated 399 Service Network Elements", RFC 2215, September 1997 401 [10] D.Hoffman et al. "SBM (Subnet Bandwidth Manager): A Proposal for 402 Admission Control over Ethernet", Internet Draft, November 1997 403 405 9. Security Considerations 407 This memo introduces no new security issues on top of those discussed in 408 the companion ISSLL documents [5] and [10]. 410 10. Acknowledgments 412 This document draws heavily on the work of the ISSLL WG of the IETF and 413 the IEEE P802.1 Interworking Task Group. 415 11. Authors' addresses 417 Mick Seaman 418 3Com Corp. 419 5400 Bayfront Plaza 420 Santa Clara CA 95052-8145 421 USA 422 +1 (408) 764 5000 423 mick_seaman@3com.com 425 Andrew Smith 426 Extreme Networks 427 10460 Bandley Drive 428 Cupertino CA 95014 429 USA 430 +1 (408) 863 2821 431 andrew@extremenetworks.com 433 Eric Crawley 434 Argon Networks 435 25 Porter Rd. 436 Littleton MA 01460 437 USA 438 +1 (508) 486 0665 439 esc@argon-net.com