Internet Engineering Task Force A. Ghanwani INTERNET DRAFT J. W. Pace V. Srinivasan IBM 25 November 1996 A Framework for Providing Integrated Services Over Shared and Switched LAN Technologies draft-ghanwani-framework-is-lan-01.txt Status of This Memo This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract Traditionally, LAN technologies such as ethernet and token ring have been required to handle best effort services only. No standard mechanism exists for providing bandwidth or delay guarantees on these media. It is therefore not possible to provide guaranteed quality of service as will be required by emerging and future multimedia applications. The anticipated demand for real-time applications on the Internet has led to the development of RSVP, a signaling mechanism for performing resource reservation in the Internet. Concurrently, the Integrated Services working group within the IETF has been working on the definition of service classes called "Integrated Services" which are expected to make use of RSVP. Applications will use these service classes in order to obtain the desired quality of service from the network. LAN technologies Ghanwani, Pace, Srinivasan Expires 24 May 1997 [Page i] Internet Draft Integrated Services Over LANs 25 November 1996 such as token ring and ethernet typically constitute the last hop in Internet connections. There is therefore a need to enhance these technologies so that they are able to support the Integrated Services. In order to enable such services, it is necessary to provide a resource management functions. This memo describes a framework for providing the necessary functionality on shared and switched LAN technologies. Ghanwani, Pace, Srinivasan Expires 24 May 1997 [Page ii] Internet Draft Integrated Services Over LANs 25 November 1996 1. Introduction The Internet has traditionally provided support for best effort traffic only. However, with the recent advances in link layer technology, and with numerous emerging real-time applications such as video conferencing, Internet telephony, etc, there has been much interest for supporting real-time services over the Internet. These new requirements have led to the development of RSVP [3], a signaling mechanism for providing resource reservation on the Internet. The protocol is currently being standardized by the IETF. Simultaneously, the Integrated Services working group of the IETF has been working on the specification of various service classes. Each of these service classes is designed to provide certain Quality of Service (QoS) guarantees to traffic conforming to a specified set of parameters. Applications are expected to use one of these classes depending on their QoS requirements. Legacy LAN technologies such as ethernet and token ring currently lack the necessary functionality to support real-time traffic. They, however, typically constitute the last mile between users and the Internet backbone. Furthermore, the development of standards for high speed LANs such as gigabit ethernet favors the likelihood that these technologies will eventually be deployed in the backbone. It is therefore necessary to enhance these technologies so that they are able to support end-to-end service guarantees. In order to support real-time services, there must be some mechanism for resource management at the link level. The ISSLL (Integrated Services over Specific Link Layers) working group was chartered with the purpose of exploring such mechanisms for various link layer technologies. Resource management in this context encompasses the functions of admission control, scheduling, traffic policing, path selection, etc. The degree to which each of these functions can be provided depends on the technology in question. This document is concerned with specifying a framework for providing Integrated Services over LAN technologies such as ethernet and token ring. We begin by listing the requirements and goals for resource management in a subnet. These functions will be provided by an entity referred to as the Bandwidth Manager. We then discuss the various components of the Bandwidth Manager. No assumptions have been made about the technology or topology at the link layer. The framework is intended to be as exhaustive as possible; this means that it is possible that all the functions discussed may not be supportable by a particular topology/technology, but this should not altogether preclude the usage of this model for the technology. Ghanwani, Pace, Srinivasan Expires 24 May 1997 [Page 1] Internet Draft Integrated Services Over LANs 25 November 1996 2. Resource Management Within a Subnet: Requirements and Goals This section discusses the requirements and goals which should drive the design of a resource management mechansim for LAN technologies. The requirements refer to functions and features which must be supported, while goals refer to functions and features which are desirable, but are not an absolute necessity. The requirements and goals are driven by the functionality supported by RSVP. 2.1. Requirements - Resource Reservation: The mechanism must be capable of reserving resources on a single segment or multiple segments and at bridges/switches connecting them. It must be able to provide reservations for both unicast and multicast sessions. It should be possible to change the level of reservation while the session is in progress. - Admission Control: The mechanism must be able to estimate the level of resources necessary to meet the QoS for a session based on the existing reservations in order to decide whether or not the session can be admitted. It should also be possible for a host to query about the availability of resources. It must be able to provide different types of QoS such as guaranteed delay, guaranteed bandwidth, etc. - Scheduling: It will be necessary to implement a scheduling algorithm so that real-time flows can be given preferential treatment over best effort flows. Scheduling algorithms can range from simple static priority queueing to more complex algorithms such as weighted fair queueing. - Policing: Traffic policing must be performed in order to ensure that sources adhere to their negotiated traffic specifications. Policing must be implemented at the sources and must ensure that violating traffic is either dropped or transmitted as best effort. - Fault Tolerance and Recovery: The mechanism must be able to function in the presence of failures; i.e. there should not be a single point of failure. Back-up and failure recovery mechanisms must be provided. - Synchronization: There should be some mechanism for resolving synchronization and deadlock issues. For instance, the case where multiple sessions simulteneously request resources on a common part of the network must be correctly handled. Ghanwani, Pace, Srinivasan Expires 24 May 1997 [Page 2] Internet Draft Integrated Services Over LANs 25 November 1996 - Soft state reservations: The mechanism must maintain soft-state information about the reservations. This means that reservations must be periodically refreshed if the reservation is to be maintained; otherwise the reservation will expire after some pre-specified interval. - Centralized or distributed implementation: In the case of a centralized implementation, a single entity manages the resources of the entire subnet. This approach avoids synchronization and deadlock problems but will not scale to subnets with a large number of hosts. In a fully distributed implementation, each segment will have a separate entity managing its resources. This approach is scalable, but requires synchronization. Ideally, implementation should be flexible; i.e. a centralized approach may be used for small subnets and distributed approach, where one or more segments is managed by a single entity, can be used for larger subnets. Examples of centralized and distributed implementations are discussed in Section 4. - Network Management: The MIBs supported must be specified. 2.2. Goals - Independence from higher layer protocols: The BM should be independent of higher layer protocols such as RSVP and IP. Independence from RSVP is desirable so that it can interwork with other reservation protocols such as STII. Independence from IP is desirable so that it can interwork with protocols such as IPX, NetBIOS, etc. - Receiver heterogeneity: The mechanism should support heterogeneous receiver groups; i.e. the level of reservation may be different for different receivers of a multicast group. - Scalability: The mechanism and protocols should have a low overhead and should scale to large receiver groups. - Path Selection: In a bridged or switched LAN, it may be worthwhile to have the BM do path selection for a given source-destination in order to utilize resources in an efficient manner. Along with other mechanisms, such as source routing in token ring networks and bridge filtering, path selection can ensure optimum utilization of network resources. Frames will appear only on those segments on which there are designated receivers, or when the segment is on the path between the sender and receiver. Ghanwani, Pace, Srinivasan Expires 24 May 1997 [Page 3] Internet Draft Integrated Services Over LANs 25 November 1996 3. Architecture for Resource Management in Legacy LANs The resource management functions described above will be performed by an entity which we refer to as the Bandwidth Manager (BM). The BM is responsible for providing functionality so that a host can request QoS from the network. The major components of the BM are discussed below. 3.1. Requester Module The requester module (RM) provides an interface between higher layer protocols (such as RSVP, STII, etc.) and the bandwidth manager. It provides a set of primitives which define the mechanism by which the various services of the BM are invoked. For instance, the higher layer protocol will initiate the resource reservation at layer 2 by providing the RM with the traffic descriptors and desired quality of service. The RM then communicates with the other components of the BM to perform admission control. The function of the RM must be provided in every device (e.g. host, router) which might need to initiate the resource reservation at the link layer. 3.2. Bandwidth Allocator The bandwidth allocator (BA) is responsible for performing admission control and tracking the allocation of resources in the subnet. A host can request various services, e.g. bandwidth reservation, changes in reservation, queries about resource availability, etc. The communication between the host and the BA will take place through the RM. The location of the BA will depend largely on the implementation method. In a centralized implementation, the BA may reside on a single station in the subnet. In a distributed implementation, the functions of the BA may be provided in all the hosts and bridges/switches as necessary. 3.3. Communication Protocols and Primitives The protocols and primitives for communication between the various components of the BM must be specified. These include the following: - Communication between the higher layer protocols and the RM: The BM must define primitives for the application to initiate reservations, query the BA about available resources, and change or delete reservations, etc. These primitives could be implemented as an API for an application to invoke functions of the BM via the RM. Ghanwani, Pace, Srinivasan Expires 24 May 1997 [Page 4] Internet Draft Integrated Services Over LANs 25 November 1996 - Communication between the RM and the BA: A protocol must be defined for the communication between the RM and the BA. This protocol will specify the messages which must be exchanged between the RM and the BA in order to service various requests by the application. Additionally, the protocol must specify a method by which a RM can send a query message which will trigger a response from its BA. - Communication between peer BAs: If there is more than one BA in the subnet, a means must be specified for inter-BA communication. Specifically, the BAs must be able to decide among themselves about which BA would be responsible for which segments and bridges or switches. Further, if a request is made for resource reservation along the domain of multiple BAs, the BAs must be able to handle such a scenario correctly. Inter-BA communication will also be required to handle failures. When a BA fails, another BA should assume its responsibility. 4. Implementation Scenarios Example scenarios are provided below showing the location of the the components of the bandwidth manager in centralized and fully distributed implementations. Note that in either case, the RM must be present on all end-stations/hosts which desire to make reservations. Essentially, centralized or distributed refers to the implementation of the BA, the component responsible for resource reservation and admission control. +---------+ .-->| BA |<--. / +---------+ \ / .-->| Layer 2 |<--. \ / / +---------+ \ \ / / \ \ / / \ \ +---------+ / / \ \ +---------+ | RSVP |<----- /-/---------------------------\-\----->| RSVP | +---------+ / / \ \ +---------+ | RM |<----. / \ .--->| RM | +---------+ / +---------+ +---------+ \ +---------+ | Layer 2 |<------>| Layer 2 |<------>| Layer 2 |<------>| Layer 2 | +---------+ +---------+ +---------+ +---------+ RSVP Host/ Intermediate Intermediate RSVP Host/ Router Bridge/Switch Bridge/Switch Router Ghanwani, Pace, Srinivasan Expires 24 May 1997 [Page 5] Internet Draft Integrated Services Over LANs 25 November 1996 Figure 1: Bandwidth Manager with a centralized Bandwidth Allocator Figure 1 shows a centralized implementation. Each host would contain an RM. Intermediate bridges and switches in the network need not have any functions of the BM since they will not be actively participating in admission control. The RM at the station requesting a reservation intiates communication with its BA. With this approach, the end host must be able to identify its BA. For larger subnets, a single BA may not be able to handle the reservations for the entire subnet. In that case it would be necessary to deploy multiple BAs, each managing the resources of a non-overlapping subset of segments. In a centralized implementation, the BA must maintain topology information in order to be able to reserve resources on appropriate segments. +---------+ +---------+ | RSVP |<-------------------------------------------->| RSVP | +---------+ +---------+ +---------+ +---------+ | RM/BA |<------>| BA |<------>| BA |<------>| RM/BA | +---------+ +---------+ +---------+ +---------+ | Layer 2 |<------>| Layer 2 |<------>| Layer 2 |<------>| Layer 2 | +---------+ +---------+ +---------+ +---------+ RSVP Host/ Intermediate Intermediate RSVP Host/ Router Bridge/Switch Bridge/Switch Router Figure 2: Bandwidth Manager with a fully distributed Bandwidth Allocator Figure 2 depicts the scenario of a fully distributed bandwidth manager. In this case, all devices in the subnet must have some BM functionality. All the end hosts are still required to have an RM. In addition, all bridges and switches must participate in admission control, but there is the possibility of relying on the link layer for the maintenance of topology information. 5. Mapping Issues and Link Layer Support for IntServ Traffic Classes As stated earlier, the Integrated Services working group has defined many service classes offering varying degrees of QoS guarantees. Initial effort will concentrate on enabling the controlled load and guaranteed service classes [4,5]. The controlled load service provides a loose guarantee, informally stated as "better than best effort". The guaranteed service provides a delay bound which the network guarantees will never be exceeded. The extent to which Ghanwani, Pace, Srinivasan Expires 24 May 1997 [Page 6] Internet Draft Integrated Services Over LANs 25 November 1996 these services can be supported at the link layer will be technology dependent and will depend on many factors. Some of the mapping issues in light of the emerging link layer standards are discussed below. 5.1. Mapping of Services to Link Level Priority The number of delay priorities and access methods of the technology under consideration will determine how many and what services may be supported. Native token ring, for instance, supports eight priority levels while ethernet has no support for priorities. However, the IEEE 802 standards committee is working on two new standards for bridges related to multimedia traffic expediting, multicast filtering and virtual LANs [1,2]. These standards allow for end-to-end signaling of eight levels of frame priority. Work is in progress to address how each of these priorities will map to the traffic classes supported by a bridge/switch; even though eight levels of priority are allowed, a bridge/switch need not support eight distinct service classes. 5.2. Interaction with Existing Resource Management Controls The interaction with existing infrastructure would need to be specified. For instance, FDDI has resource management with its "Synchronous Bandwidth Manager". The BM for FDDI must be designed so that it takes advantage of this. 6. Summary This document has specified a framework for providing Integrated Services over shared and switched LAN technologies. The ability to provide QoS guarantees necessitates some form of admission control and resource management. The requirements and goals of a resource management scheme for subnets have been identified and discussed. We refer to the entire resource management scheme as a Bandwidth Manager. Architectural considerations were discussed and examples were provided to illustrate possible implementations of a Bandwidth Manager. References [1] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Traffic Class and Dynamic Multicast Filtering Ghanwani, Pace, Srinivasan Expires 24 May 1997 [Page 7] Internet Draft Integrated Services Over LANs 25 November 1996 Services in Bridged Local Area Networks (Draft Supplement to 802.1D), P802.1p/D3, April 30, 1996. [2] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q/D1, July 4, 1996. [3] B. Braden, et. al. "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", Internet Draft, July 1996, [4] J. Wroclawski, "Specification of the Controlled-Load Network Element Service", Internet Draft, August 1996, [5] S. Shenker et. al., "Specification of Guaranteed Quality of Service", Internet Draft, August 1996, Authors' Address Anoop Ghanwani IBM Corporation P. O. Box 12195 Research Triangle Park, NC 27709 Phone: +1-919-254-0260 Fax: +1-919-254-5410 Email: anoop@raleigh.ibm.com Wayne Pace IBM Corporation P. O. Box 12195 Research Triangle Park, NC 27709 Phone: +1-919-254-4930 Fax: +1-919-254-5410 Email: pacew@raleigh.ibm.com Vijay Srinivasan IBM Corporation P. O. Box 12195 Research Triangle Park, NC 27709 Phone: +1-919-254-2730 Fax: +1-919-254-5410 Email: vijay@raleigh.ibm.com Ghanwani, Pace, Srinivasan Expires 24 May 1997 [Page 8]