idnits 2.17.1 draft-ietf-issll-is802-framework-02.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-26) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 (May 1997) is 9843 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: '2' is defined on line 757, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 774, 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' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Downref: Normative reference to an Historic RFC: RFC 1819 (ref. '10') Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force A. Ghanwani 2 INTERNET DRAFT J. W. Pace 3 V. Srinivasan 4 IBM 5 May 1997 7 A Framework for Providing Integrated Services 8 Over Shared and Switched LAN Technologies 10 draft-ietf-issll-is802-framework-02.txt 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, and may be updated, replaced, or obsoleted by other documents 21 at any time. It is not appropriate to use Internet Drafts as 22 reference material, or to cite them other than as a ``working draft'' 23 or ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check 26 the ``1id-abstracts.txt'' listing contained in the internet-drafts 27 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 28 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 29 Rim). 31 Abstract 33 Traditionally, LAN technologies such as Ethernet and token ring have 34 been required to handle best effort services only. No standard 35 mechanism exists for providing service guarantees on these media as 36 will be required by emerging and future multimedia applications. The 37 anticipated demand for such applications on the Internet has led 38 to the development of RSVP, a signaling mechanism for performing 39 resource reservation in the Internet. Concurrently, the Integrated 40 Services working group within the IETF has been working on the 41 definition of service classes called Integrated Services which are 42 expected to make use of RSVP. Applications will use these service 43 classes in order to obtain the desired quality of service from the 44 network. LAN technologies such as token ring and Ethernet typically 45 constitute the last hop in Internet connections. It is therefore 46 necessary to define standardized mechanisms for these technologies 47 so that they are able to support the Integrated Services. This memo 48 describes a framework for providing the functionality to support 49 Integrated Services on shared and switched LAN technologies. 51 1. Introduction 53 The Internet has traditionally provided support for best effort 54 traffic only. However, with the recent advances in link layer 55 technology, and with numerous emerging real-time applications such 56 as video conferencing and Internet telephony, there has been much 57 interest for developing mechanisms which enable real-time services 58 over the Internet. These new requirements have led to the design 59 of the ReSerVation Protocol (RSVP) [3], a signaling mechanism 60 for providing resource reservation on the Internet. The protocol 61 is currently being standardized by the IETF. Simultaneously, the 62 Integrated Services working group of the IETF has been working on 63 the specification of various service classes. Each of these service 64 classes is designed to provide certain Quality of Service (QoS) 65 guarantees to traffic conforming to a specified set of parameters. 66 Applications are expected to use one of these classes depending on 67 their QoS requirements. 69 There is no standard mechanism for providing service guarantees on 70 LAN technologies such as Ethernet and token ring. They, however, 71 typically constitute the last hop between users and the Internet 72 backbone. Furthermore, the development of standards for high speed 73 LANs such as gigabit Ethernet favors the likelihood that these 74 technologies will eventually be deployed in the backbone of campus 75 networks. It is therefore necessary to provide some standardized 76 mechanism for these technologies so that they are able to support 77 end-to-end service guarantees such as those defined by the Integrated 78 Services. 80 In order to support real-time services, there must be some mechanism 81 for resource management at the link level. Resource management 82 in this context encompasses the functions of admission control, 83 scheduling, traffic policing, etc. The ISSLL (Integrated Services 84 over Specific Link Layers) working group in the IETF was chartered 85 with the purpose of exploring and standardizing such mechanisms for 86 various link layer technologies. 88 This document is concerned with specifying a framework for providing 89 Integrated Services over shared and switched LAN technologies such 90 as Ethernet/802.3, token ring/802.5, FDDI, etc. We begin with a 91 list of definitions in Section 2. Section 3 lists the requirements 92 and goals for a mechanism capable of providing Integrated Services 93 in a subnet. We then discuss a taxonomy of topologies for the LAN 94 technologies under consideration with an emphasis on the capabilities 95 of each which can be leveraged for enabling Integrated Services. The 96 resource management functions outlined in Section 3 are expected 97 to be provided by an entity which, in this document, is referred 98 to as the Bandwidth Manager (BM). The various components of the 99 Bandwidth Manager are discussed in the following section and some 100 examples of the implementation of the Bandwidth Manager are provided. 101 Some issues with respect to link layer support for Integrated 102 Services are examined in Section 6. In the development of this 103 framework, no assumptions have been made about the technology or 104 topology at the link layer. The framework is intended to be as 105 exhaustive as possible; this means that it is possible that all the 106 functions discussed may not be supportable by a particular topology 107 or technology, but this should not preclude the usage of this model 108 for it. 110 2. Definitions 112 The following is a list of the terms used in this document. 114 - End Station: A device (e.g. router, host) which runs the 115 application program or higher layer protocol which needs to make 116 reservations. 118 - Link Layer/Layer 2: The data link layer. This memo is concerned 119 with link layer technologies such as Ethernet, token ring, and 120 FDDI. 122 - Link Layer Domain: An interconnection of segments and 123 bridges/switches between two end stations. 125 - Segment: A physical link which is shared by one or more senders. 127 - Traffic Class: A category of flows which are given similar 128 service within a bridge/switch. 130 3. Supporting Integrated Services Within a Subnet: Requirements and 131 Goals 133 This section discusses the requirements and goals which should drive 134 the design of an architecture for supporting Integrated Services over 135 LAN technologies. The requirements refer to functions and features 136 which must be supported, while goals refer to functions and features 137 which are desirable, but are not an absolute necessity. Many of the 138 requirements and goals are driven by the functionality supported by 139 Integrated Services and RSVP. 141 3.1. Requirements 143 - Resource Reservation: The mechanism must be capable of reserving 144 resources on a single segment or multiple segments and at 145 bridges/switches connecting them. It must be able to provide 146 reservations for both unicast and multicast sessions. It should 147 be possible to change the level of reservation while the session 148 is in progress. 150 - Admission Control: The mechanism must be able to estimate 151 the level of resources necessary to meet the QoS requested by 152 the session in order to decide whether or not the session can 153 be admitted. For the purpose of management, it is useful to 154 provide the ability to respond to queries about availability of 155 resources. It must be able to make admission control decisions 156 for different types of services such as guaranteed delay, 157 controlled load, etc. 159 - Flow Separation and Scheduling: It is necessary to provide a 160 mechanism for traffic flow separation so that real-time flows can 161 be given preferential treatment over best effort flows. Packets 162 of real-time flows can then be isolated and scheduled according 163 to their service requirements. 165 - Policing: Traffic policing must be performed in order to ensure 166 that sources adhere to their negotiated traffic specifications. 167 Policing must be implemented at the sources and must ensure 168 that violating traffic is either dropped or transmitted as best 169 effort. Policing may optionally be implemented in the bridges 170 and switches. Alternatively, traffic may be shaped to insure 171 conformance to the negotiated parameters. 173 - Soft State: The mechanism must maintain soft state information 174 about the reservations. This means that state information must 175 be periodically refreshed if the reservation is to be maintained; 176 otherwise the state information and corresponding reservations 177 will expire after some pre-specified interval. 179 - Centralized or Distributed Implementation: In the case of a 180 centralized implementation, a single entity manages the resources 181 of the entire subnet. This approach has the advantage of being 182 easier to deploy since bridges and switches may not need to be 183 upgraded with additional functionality. However, this approach 184 scales poorly with geographical size of the subnet and the number 185 of end stations attached. In a fully distributed implementation, 186 each segment will have a local entity managing its resources. 187 This approach has better scalability than the former. However, 188 it requires that all bridges and switches in the network support 189 new mechanisms. It is also possible to have a semi-distributed 190 implementation where there is more than one entity, each managing 191 the resources of a subset of segments and bridges/switches 192 within the subnet. Ideally, implementation should be flexible; 193 i.e. a centralized approach may be used for small subnets and a 194 distributed approach can be used for larger subnets. Examples 195 of centralized and distributed implementations are discussed in 196 Section 4. 198 - Scalability: The mechanism and protocols should have a low 199 overhead and should scale to the largest receiver groups likely 200 to occur within a single link layer domain. 202 - Fault Tolerance and Recovery: The mechanism must be able to 203 function in the presence of failures; i.e. there should not 204 be a single point of failure. For instance, in a centralized 205 implementation, some mechanism must be specified for back-up and 206 recovery in the event of failure. 208 - Interaction with Existing Resource Management Controls: The 209 interaction with existing infrastructure for resource management 210 needs to be specified. For example, FDDI has a resource 211 management mechanism called the "Synchronous Bandwidth Manager". 212 The mechanism must be designed so that it takes advantage of, 213 and specifies the interaction with, existing controls where 214 available. 216 3.2. Goals 218 - Independence from higher layer protocols: The mechanism should, 219 as far as possible, be independent of higher layer protocols such 220 as RSVP and IP. Independence from RSVP is desirable so that it 221 can interwork with other reservation protocols such as ST2 [10]. 222 Independence from IP is desirable so that it can interwork with 223 network layer protocols such as IPX, NetBIOS, etc. 225 - Receiver heterogeneity: Receiver heterogeneity refers to 226 multicast communication where different receivers request 227 different levels of service. For example, in a multicast 228 group with many receivers, it is possible that one of the 229 receivers desires a lower delay bound than the others. A 230 better delay bound may be provided by increasing the amount 231 of resources reserved along the path to that receiver while 232 leaving the reservations for the other receivers unchanged. 233 In its most complex form, receiver heterogeneity implies the 234 ability to simultaneously provide various levels of service as 235 requested by different receivers. In its simplest form, receiver 236 heterogeneity will allow a scenario where some of the receivers 237 use best effort service and those requiring service guarantees 238 make a reservation. Receiver heterogeneity, especially for the 239 reserved/best effort scenario, is a very desirable function. 240 More details on supporting receiver heterogeneity are provided in 241 Section 6. 243 - Support for different filter styles: It is desirable to provide 244 support for the different filter styles defined by RSVP such as 245 fixed filter, shared explicit and wildcard. Some of the issues 246 with respect to supporting such filter styles in the link layer 247 domain are examined in Section 6. 249 - Path Selection: In source routed LAN technologies such as token 250 ring/802.5, it may be useful for the mechanism to incorporate the 251 function of path selection. Using an appropriate path selection 252 mechanism may optimize utilization of network resources. 254 4. LAN Topologies and Their Features 256 As stated earlier, this memo is concerned with specifying a framework 257 for supporting Integrated Services in LAN technologies such as 258 Ethernet/IEEE 802.3, token ring/IEEE 802.5, and FDDI. The extent 259 to which service guarantees can be provided by a network depend to 260 a large degree on the ability to provide the key functions of flow 261 identification and scheduling in addition to admission control and 262 policing. This section discusses some of the capabilities of these 263 LAN technologies and provides a taxonomy of possible topologies 264 emphasizing the capabilities of each with regard to supporting the 265 above functions. 267 For the technologies considered here, the basic topology of a LAN 268 may be shared, switched half duplex or switched full duplex. In the 269 shared topology, multiple senders share a single segment. Contention 270 for media access is resolved using protocols such as CSMA/CD in 271 Ethernet and token passing in token ring and FDDI. Switched half 272 duplex, is essentially a shared topology with the restriction that 273 there are only two transmitters contending for resources on any 274 segment. This topology is fast becoming popular with the need for 275 increased bandwidth. Finally, in a switched full duplex topology, a 276 full bandwidth path is available to the transmitter at each end of 277 the link at all times. Therefore, in this topology, there is no need 278 for any access control mechanism such as CSMA/CD or token passing as 279 there is no contention between the transmitters. 281 Another important element in the discussion of topologies is the 282 support for multiple traffic classes. Traffic classes provide a 283 coarse method for isolation between flows and allows the possibility 284 to easily support scheduling algorithms in order to meet service 285 requirements. Native Ethernet/802.3 does not support multiple 286 traffic classes. Token ring/802.5 and FDDI on the other hand 287 provides support for traffic classes. Three bits of the Frame 288 Control field are used to indicate the Frame Priority which may be 289 mapped to a traffic class as appropriate. Equally important in 290 token ring networks are the notions of Reserved Priority and Access 291 Priority. Reserved Priority relates to the value of priority which 292 a station uses to reserve the token for the next transmission on 293 the ring. When a free token is circulating, only a station having 294 an Access Priority greater than or equal to the Reserved Priority 295 in the token will be allowed to seize the token for transmission. 296 More recently, the IEEE 802 Standards Committee has been working on 297 the a 802.1p, a standard for expedited traffic classes and dynamic 298 multicast filtering in bridges and switches [1]. The proposed 299 standard requires a new frame format for Ethernet and token ring 300 networks. The new frame format adds 4 bytes of information of which 301 3 bits are used to indicate User Priority. This adds new information 302 in the case of Ethernet networks. For token ring networks this 303 field carries the same information as the priority bits in the Frame 304 Control field. The User Priority may be mapped to any one of up to 305 eight traffic classes in the bridge/switch. The emerging standard 306 does not specify a requirement for the minimum number of traffic 307 classes which must be supported by a bridge/switch, nor does it 308 specify the scheduling algorithm to be used between traffic classes. 310 Depending on the basic topology used and the ability to support 311 traffic classes, there are six possible scenarios as follows: 313 1. Shared topology without traffic classes: This category includes 314 pure shared media such as Ethernet/802.3 networks which are 315 multi-access technologies with no support for priority signaling 316 and traffic classes. Shared topology without traffic classes 317 offers little capability for isolation between reserved and 318 unreserved flows. No service guarantees can be provided in 319 this scenario without modification to the basic transmission 320 mechanisms. 322 2. Shared topology with traffic classes: This category includes 323 Ethernet/802.3 networks which implement the emerging IEEE 324 802.1p standard, as well as token ring/802.5 and FDDI networks. 325 Even with support for traffic classes, shared Ethernet can at 326 best offer loose statistical service guarantees because of the 327 non-deterministic nature of the CSMA/CD protocol. On the other 328 hand, better guarantees can be provided on token ring media if 329 the Frame Priority, Reserved Priority and Access Priority are 330 used in conjunction with appropriate controls. 332 3. Switched half duplex topology without traffic classes: This 333 scenario is a special case of shared topology without traffic 334 classes where there are only two senders contending for resources 335 on any segment (a host and a switch or two switches). This 336 topology provides higher bandwidth per station and fewer 337 collisions. Due to the use of the CSMA/CD protocol and the lack 338 of traffic classes, little can be done to isolate flows and 339 provide scheduling. 341 4. Switched half duplex topology with traffic classes: This 342 scenario is a special case of shared topology with priority 343 but there are now only two senders contending for resources 344 on any segment. This reduces the contention for resources. 345 Ethernet/802.3 networks with this topology will likely be 346 able to support better statistical service guarantees than 347 the corresponding shared topology. Better guarantees will be 348 possible for token ring/802.5 media with this topology. 350 5. Switched full duplex topology without traffic classes: This 351 scenario includes switched Ethernet/802.3 and token ring/802.5 352 where the access control protocol is no longer used since a full 353 bandwidth path is available to each transmitter. However, since 354 traffic classes are not available, it is not possible to isolate 355 flows for scheduling. 357 6. Switched full duplex topology with traffic classes: This 358 category is similar to the above, but traffic classes are 359 also available. This topology is the most capable in terms of 360 link layer functions that can be exploited for supporting the 361 functions of flow separation and scheduling. 363 There is also the possibility of hybrid topologies where two or more 364 of the above coexist. For instance, it is possible that within a 365 single subnet, there are some bridges/switches which support traffic 366 classes and some which do not. If the flow in question traverses 367 both kinds of bridges/switches in the network, the least common 368 denominator will prevail. In other words, as far as that flow is 369 concerned, the network is of the type corresponding to the least 370 capable topology that is traversed. 372 Note that even within the different switched topologies categorized 373 above, there are likely to be switches having varied capabilities 374 with respect to providing functions such as receiver heterogeneity 375 and the ability to dedicate resources such as buffering and 376 scheduling algorithms for supporting the various Integrated Services. 377 Future work on service mappings in the ISSLL working group will 378 elaborate on these issues. 380 5. Architecture for Supporting Integrated Services in LANs 382 The functional requirements described in Section 3 will be performed 383 by an entity which we refer to as the Bandwidth Manager (BM). The BM 384 is responsible for providing mechanisms for an application or higher 385 layer protocol to request QoS from the network. For architectural 386 purposes, the BM consists of the following components. 388 5.1. Components of the Bandwidth Manager 390 5.1.1. Requester Module 392 The Requester Module (RM) resides in every end station in the subnet. 393 One of its functions is to provide an interface between applications 394 or higher layer protocols such as RSVP, STII, SNMP, etc. and the BM. 395 An application can invoke the various functions of the BM by using 396 the primitives for communication with the RM and providing it with 397 the appropriate parameters. To initiate a reservation, in the link 398 layer domain, the following parameters must be passed to the RM: the 399 service desired (Guaranteed Service or Controlled Load), the traffic 400 descriptors contained in the TSpec, and an RSpec specifying the 401 amount of resources to be reserved [8]. More information on these 402 parameters may be found in the relevant Integrated Services documents 403 [8,9]. When RSVP is used for signaling at the network layer, this 404 information is available and needs to be extracted from the RSVP PATH 405 and RSVP RESV messages (See [7] for details). In addition to these 406 parameters, the network layer addresses of the end points must be 407 specified. The RM must then translate the network layer addresses 408 to link layer addresses and convert the request into an appropriate 409 format which is understood by other components of the BM responsible 410 admission control. The RM is also responsible for returning the 411 status of requests processed by the BM to the invoking application or 412 higher layer protocol. 414 5.1.2. Bandwidth Allocator 416 The Bandwidth Allocator (BA) is responsible for performing admission 417 control and maintaining state about the allocation of resources 418 in the subnet. An end station can request various services, e.g. 419 bandwidth reservation, modification of an existing reservation, 420 queries about resource availability, etc. These requests are 421 processed by the BA. The communication between the end station and 422 the BA takes place through the RM. The location of the BA will 423 depend largely on the implementation method. In a centralized 424 implementation, the BA may reside on a single station in the 425 subnet. In a distributed implementation, the functions of the BA 426 may be distributed in all the end stations and bridges/switches as 427 necessary. The BA is also responsible for deciding how to label 428 flows, e.g. based on the admission control decision, the BA may 429 indicate to the RM that packets belonging to a particular flow be 430 tagged with some priority value which maps to the appropriate traffic 431 class. 433 5.1.3. Communication Protocols and Primitives 435 The protocols and primitives for communication between the various 436 components of the BM must be specified. These include the following: 438 - Communication between the higher layer protocols and the RM: 439 The BM must define primitives for the application to initiate 440 reservations, query the BA about available resources, and 441 change or delete reservations, etc. These primitives could be 442 implemented as an API for an application to invoke functions of 443 the BM via the RM. 445 - Communication between the RM and the BA: A signaling mechanism 446 must be defined for the communication between the RM and the BA. 447 This protocol will specify the messages which must be exchanged 448 between the RM and the BA in order to service various requests by 449 the higher layer entity. 451 - Communication between peer BAs: If there is more than one BA in 452 the subnet, a means must be specified for inter-BA communication. 453 Specifically, the BAs must be able to decide among themselves 454 about which BA would be responsible for which segments and 455 bridges or switches. Further, if a request is made for resource 456 reservation along the domain of multiple BAs, the BAs must be 457 able to handle such a scenario correctly. Inter-BA communication 458 will also be responsible for back-up and recovery in the event of 459 failure. 461 5.2. Implementation Scenarios 463 Example scenarios are provided showing the location of the the 464 components of the bandwidth manager in centralized and fully 465 distributed implementations. Note that in either case, the RM must 466 be present in all end stations which desire to make reservations. 467 Essentially, centralized or distributed refers to the implementation 468 of the BA, the component responsible for resource reservation 469 and admission control. In the figures below, "App" refers to 470 the application making use of the BM. It could either be a user 471 application, or a higher layer protocol process such as RSVP. 473 +---------+ 474 .-->| BA |<--. 475 / +---------+ \ 476 / .-->| Layer 2 |<--. \ 477 / / +---------+ \ \ 478 / / \ \ 479 / / \ \ 480 +---------+ / / \ \ +---------+ 481 | App |<----- /-/---------------------------\-\----->| App | 482 +---------+ / / \ \ +---------+ 483 | RM |<----. / \ .--->| RM | 484 +---------+ / +---------+ +---------+ \ +---------+ 485 | Layer 2 |<------>| Layer 2 |<------>| Layer 2 |<------>| Layer 2 | 486 +---------+ +---------+ +---------+ +---------+ 488 RSVP Host/ Intermediate Intermediate RSVP Host/ 489 Router Bridge/Switch Bridge/Switch Router 491 Figure 1: Bandwidth Manager with a centralized Bandwidth Allocator 493 Figure 1 shows a centralized implementation where a single BA is 494 responsible for admission control decisions for the entire subnet. 495 Every end station contains an RM. Intermediate bridges and switches 496 in the network need not have any functions of the BM since they will 497 not be actively participating in admission control. The RM at the 498 end station requesting a reservation initiates communication with 499 its BA. For larger subnets, a single BA may not be able to handle 500 the reservations for the entire subnet. In that case it would be 501 necessary to deploy multiple BAs, each managing the resources of a 502 non-overlapping subset of segments. In a centralized implementation, 503 the BA must be able to access topology information such as link layer 504 spanning tree information in order to be able to reserve resources 505 on appropriate segments. Without this topology information, the BM 506 would have to reserve resources on the entire spanning tree for all 507 flows leading to an inefficient utilization of resources. 509 +---------+ +---------+ 510 | App |<-------------------------------------------->| App | 511 +---------+ +---------+ +---------+ +---------+ 512 | RM/BA |<------>| BA |<------>| BA |<------>| RM/BA | 513 +---------+ +---------+ +---------+ +---------+ 514 | Layer 2 |<------>| Layer 2 |<------>| Layer 2 |<------>| Layer 2 | 515 +---------+ +---------+ +---------+ +---------+ 517 RSVP Host/ Intermediate Intermediate RSVP Host/ 518 Router Bridge/Switch Bridge/Switch Router 520 Figure 2: Bandwidth Manager with a fully distributed Bandwidth 521 Allocator 523 Figure 2 depicts the scenario of a fully distributed bandwidth 524 manager. In this case, all devices in the subnet must have some BM 525 functionality. All the end hosts are still required to have an RM. 526 In addition, all bridges and switches must actively participate in 527 admission control. With this approach, the BA would need only local 528 topology information since each BA is responsible for the resources 529 on segments that are directly connected to it. This local topology 530 information, such as which ports are on the spanning tree and 531 which unicast addresses are reachable from which ports, is readily 532 available in existing bridges/switches. 534 Note that in the figures above, the arrows between peer layers are 535 used to indicate logical connectivity. 537 5.3. Logical Operation of the BM in End Stations and Link Layer Domain 539 The figure below shows the location and logical operation of the 540 BM in end stations and the link layer domain. It is not possible 541 to provide the details of physical flows because of the inherent 542 differences that arise in centralized and distributed implementations 543 as discussed in Section 5.2. 545 +-------------------------+ 546 | +--------+ +------+ | 547 | |Appli- <---> RM | | 548 | | cation | +--^---+ | 549 | +--------+ | | +-------------------------+ 550 | || +--V---+ | | +------+ | 551 | || +------| BA <------------------------> BA | | 552 | || | +------+ | | +----------+ +-^-^|-+ | 553 | || | | | | |Forwarding| | || | 554 | || | | | | |Process <---+ || | 555 | || | | | | +---|------+ || | 556 | || | | | | | +---------+| | 557 | \/ | | | | | | | | 558 | +-----V-+ +--V---+ | | +---V--V+ +----V-+ | 559 | |Class- | |Sched-| | | |Class- | |Sched-| | 560 | | ifier |===>| uler |==========>| ifier |===>| uler |====> 561 | +-------+ +------+ | | +-------+ +------+ | 562 +-------------------------+ +-------------------------+ 564 End Station Link Layer Domain 566 ----> Signaling/Control 567 ====> Data 569 Figure 3: The logical Operation of the BM in end stations and the 570 link layer domain. 572 The application, which may be RSVP or some other higher layer 573 reservation protocol requests resources by passing the relevant 574 parameters to the RM. The RM then starts the process of resource 575 reservation at the link layer by contacting the local BA. In the 576 case of a distributed implementation, The local BA is responsible 577 for admission control on the segment to which the end station is 578 directly attached. If the reservation succeeds, the local BA sets 579 up the classifier and scheduler as required so that the appropriate 580 priority is used for the flow. The request is then propagated 581 to the the "remote" BA controlling the other segments along the 582 forwarding path. In this case, it is possible to set up more complex 583 schedulers as well as policing at the bridges/switches since the 584 BA, which maintains the state, is co-located in every bridge/switch 585 and participates actively in the process of admission control. In 586 a centralized implementation, the BA resides in a server within the 587 subnet. The classifier and scheduler in the bridges/switches along 588 the forwarding path are implicitly set up by the priority carried in 589 the data frames if the reservation is successful. 591 6. Mapping Issues and Link Layer Support for Integrated Services 593 As stated earlier, the Integrated Services working group has defined 594 various service classes offering varying degrees of QoS guarantees. 595 Initial effort will concentrate on enabling the Controlled Load 596 and Guaranteed Service classes [4,5]. The Controlled Load service 597 provides a loose guarantee, informally stated as "better than best 598 effort". The Guaranteed Service provides a delay bound which the 599 network guarantees will never be exceeded. The extent to which these 600 services can be supported at the link layer will depend on many 601 factors including the topology and technology used. Some of the 602 mapping issues are dicussed below in light of the emerging link layer 603 standards and the functions supported by higher layer protocols. 604 Considering the limitations of some of the topologies under 605 consideration, it may not be possible to satisfy all the requirements 606 for Integrated Services on a given topology. In such cases, it 607 is useful to consider providing support for an approximation of 608 the service which may suffice in most practical instances. For 609 example, it may not be feasible to provide policing/shaping at each 610 network element (bridge/switch) as required by the Controlled Load 611 specification [4]. But if this task is left to the end stations, a 612 reasonably good approximation to the service can be obtained. 614 6.1. Mapping of Services to Link Level Priority 616 The number of traffic classes supported and access methods of 617 the technology under consideration will determine how many and 618 what services may be supported. Native token ring/802.5, for 619 instance, supports eight priority levels which may be mapped to 620 one or more traffic classes. Ethernet/802.3 has no support for 621 signaling priorities within frames. However, the IEEE 802 standards 622 committee is working on a new standard for bridges/switches related 623 to multimedia traffic expediting and dynamic multicast filtering 624 [1]. The standard allows for up to eight traffic classes on all 625 media. The User Priority bits carried in the frame are mapped 626 to a particular traffic class within a bridge/switch. The User 627 Priority is signaled on an end-to-end basis, unless overridden by 628 bridge/switch management. 630 The traffic class that is used by a flow should depend on the quality 631 of service desired and whether the reservation is successful or not. 632 Therefore, a sender should use the a User Priority value which maps 633 to the best effort traffic class until told otherwise by the BM. 634 The BM will, upon successful completion of resource reservation, 635 specify the User Priority to be used by the sender for that session's 636 data. Future work in the ISSLL working group will address the issue 637 of mapping the various Integrated Services to appropriate traffic 638 classes in the bridges/switches. 640 6.2. Supporting Receiver Heterogeneity 642 Receiver heterogeneity means that receivers within a group can each 643 have different QoS requirements; i.e. it is possible that, for a 644 given flow, some receivers make a reservation while others decide 645 to make use of best effort transport. RSVP allows heterogeneous 646 receivers within a group. However, handling the problem at layer 647 2 can be non-trivial. Consider for instance, the scenario in the 648 figure below. 650 +-----+ 651 | S | 652 +-----+ 653 | 654 v 655 +-----+ +-----+ +-----+ 656 | R1 |<-----| SW |----->| R2 | 657 +-----+ +-----+ +-----+ 659 Figure 4: An instance of receiver heterogeneity. S is the source. 660 R1 is a receiver which makes a reservation, and R2 is a receiver 661 which is satisfied with best effort service. SW is a Layer 2 device 662 (bridge/switch) participating in resource reservation. 664 In the figure above, S is the upstream end station and R1 and R2 665 are downstream end stations. R1 would like to make a reservation 666 for the flow while R2 would like to receive the flow using best 667 effort transport. S sends RSVP PATH messages which are multicast 668 to both R1 and R2. R1 sends an RSVP RESV message to S requesting 669 the reservation of resources. If the reservation is successful at 670 Layer 2, the frames addressed to the group will be categorized in 671 the traffic class corresponding to the service requested by R1. At 672 SW, there must be some mechanism which forwards the packet providing 673 service corresponding to the reserved traffic class at the interface 674 to R1 while using the best effort traffic class at the interface to 675 R2. This may involve changing the contents of the frame itself, or 676 ignoring the frame priority at the interface to R2. 678 Another possibility for supporting heterogeneous receivers would 679 be to have separate groups with distinct MAC addresses, one for 680 each class of service. By default, a receiver would join the "best 681 effort" group where the flow is classified as best effort. If the 682 receiver makes a reservation successfully, it can be transferred to 683 the group for the class of service desired. The dynamic multicast 684 filtering capabilities of bridges and switches implementing the 685 emerging IEEE 802.1p standard would be a very useful feature in 686 such a scenario. A given flow would be transmitted only on those 687 segments which are on the path between the sender and the receivers 688 of that flow. The obvious disadvantage of such an approach is that 689 the sender needs to send out multiple copies of the same packet 690 corresponding to each class of service desired thus potentially 691 duplicating the traffic on a portion of the distribution tree. 693 6.3. Support for Different Reservation Styles 695 +-----+ +-----+ +-----+ 696 | S1 | | S2 | | S3 | 697 +-----+ +-----+ +-----+ 698 | | | 699 | v | 700 | +-----+ | 701 +--------->| SW |<---------+ 702 +-----+ 703 | | 704 +----+ +----+ 705 | | 706 v V 707 +-----+ +-----+ 708 | R1 | | R2 | 709 +-----+ +-----+ 711 Figure 5: An illustration of filter styles. S1, S2, S3, R1 and R2 712 are RSVP end stations which are members of the same group. SW is a 713 bridge/switch in the link layer domain. 715 In the figure above, S1, S2, S3, R1 and R2 are end stations which 716 are members of a group associated with the same RSVP flow. S1, S2 717 and S3 are upstream end stations. R1 and R2 are the downstream end 718 stations which receive traffic from all the senders. RSVP allows 719 receivers R1 and R2 to specify reservations which can apply to: (a) 720 one specific sender only (fixed filter); (b) any of two or more 721 explicitly specified senders (shared explicit filter); and (c) any 722 sender in the group (shared wildcard filter). Support for the fixed 723 filter style is straightforward; a separate reservation is made for 724 the traffic from each of the senders. However, support for the the 725 other two filter styles has implications regarding policing; i.e. 726 the merged flow from the different senders must be policed so that 727 they conform to traffic parameters specified in the filter's RSpec. 728 This scenario is further complicated if the services requested by R1 729 and R2 are different. Therefore, in the absence of policing within 730 bridges/switches, it may be possible to support only fixed filter 731 reservations at the link layer. 733 7. Summary 735 This document has specified a framework for providing Integrated 736 Services over shared and switched LAN technologies. The ability to 737 provide QoS guarantees necessitates some form of admission control 738 and resource management. The requirements and goals of a resource 739 management scheme for subnets have been identified and discussed. 740 We refer to the entire resource management scheme as a Bandwidth 741 Manager. Architectural considerations were discussed and examples 742 were provided to illustrate possible implementations of a Bandwidth 743 Manager. Some of the issues involved in mapping the services 744 from higher layers to the link layer have also been discussed. 745 Forthcoming documents from the ISSLL working group will address 746 service mapping issues and provide a protocol specification for the 747 Bandwidth manager based on the requirements and goals dicussed in 748 this document. 750 References 752 [1] IEEE Standards for Local and Metropolitan Area Networks: 753 Draft Standard for Traffic Class and Dynamic Multicast Filtering 754 Services in Bridged Local Area Networks (Draft Supplement to 755 802.1D), P802.1p/D5, February, 1997. 757 [2] IEEE Standards for Local and Metropolitan Area Networks: 758 Draft Standard for Virtual Bridged Local Area Networks, 759 P802.1Q/D5, February, 1997. 761 [3] B. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin, 762 "Resource Reservation Protocol (RSVP) - Version 1 Functional 763 Specification," Internet Draft, November 1996, 764 766 [4] J. Wroclawski, "Specification of the Controlled Load Network 767 Element Service," Internet Draft, November 1996, 768 770 [5] S. Shenker, C. Partridge and R. Guerin, "Specification of 771 Guaranteed Quality of Service," Internet Draft, August 1996, 772 774 [6] R. Braden, D. Clark and S. Shenker, "Integrated Services in the 775 Internet Architecture: An Overview," RFC 1633, June 1994. 777 [7] J. Wroclawski, "The Use of RSVP with IETF Integrated Services," 778 Internet Draft, October 1996, 780 [8] S. Shenker and J. Wroclawski, "Network Element Service 781 Specification Template," Internet Draft, November 1995, 782 784 [9] S. Shenker and J. Wroclawski, "General Characterization Parameters 785 for Integrated Service Network Elements," Internet Draft, 786 October 1996, 788 [10] L. Delgrossi and L. Berger (Editors), "Internet Stream Protocol 789 Version 2 (ST2) Protocol Specification - Version ST2+," 790 Request For Comments 1819, August 1995. 792 Acknowledgements 794 Much of the work presented in this document has benefited greatly 795 from discussion held at the meetings of the Integrated Services over 796 Specific Link Layers (ISSLL) working group. In particular we would 797 like to thank Eric Crawley, Don Hoffman, Mick Seaman, Andrew Smith 798 and Raj Yavatkar who have contributed to this effort via earlier 799 Internet drafts. 801 Authors' Address 803 Anoop Ghanwani 804 IBM Corporation 805 P. O. Box 12195 806 Research Triangle Park, NC 27709 807 Phone: +1-919-254-0260 808 Fax: +1-919-254-5410 809 Email: anoop@raleigh.ibm.com 811 Wayne Pace 812 IBM Corporation 813 P. O. Box 12195 814 Research Triangle Park, NC 27709 815 Phone: +1-919-254-4930 816 Fax: +1-919-254-5410 817 Email: pacew@raleigh.ibm.com 819 Vijay Srinivasan 820 IBM Corporation 821 P. O. Box 12195 822 Research Triangle Park, NC 27709 823 Phone: +1-919-254-2730 824 Fax: +1-919-254-5410 825 Email: vijay@raleigh.ibm.com