Internet Engineering Task Force A. Ghanwani INTERNET DRAFT J. W. Pace V. Srinivasan IBM 20 September 1996 A Framework for Providing Integrated Services Over Shared and Switched LAN Technologies draft-ghanwani-framework-is-lan-00.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 built to handle best-effort services. There is currently no mechanism for providing bandwidth or delay guarantees. 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 be designed to use these services in order to obtain the desired QoS from the network. LAN technologies such as token ring and ethernet typically constitute Ghanwani, Pace, Srinivasan Expires 19 March 1997 [Page i] Internet Draft Integrated Services Over LANs 20 September 1996 the "last hop" in Internet connections. There is therefore a need to enhance these technologies so that they are able to support these Integrated Services. In order to enable such services, it necessary to provide a framework for the deployment of resource management functions. These functions include the reservation of bandwidth, provision of delay guarantees, etc. This memo describes a framework for providing the necessary functionality on shared and switched LAN technologies. Ghanwani, Pace, Srinivasan Expires 19 March 1997 [Page ii] Internet Draft Integrated Services Over LANs 20 September 1996 1. Introduction The Internet has traditionally provided support for only best-effort traffic. As such, legacy LAN technologies such as ethernet and token ring have been designed with little support for real-time traffic. 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. Since technologies such as ethernet and token ring typically constitute the "last hop" between users and the Internet "back-bone", it is necessary to enhance these technologies so that they are able to support end-to-end provision of such services. 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 bandwidth reservation, priority handling, scheduling, admission control, 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. 2. Managing Resources within a Subnet: The Bandwidth Manager One method of managing the resources within a subnet is to have a "Bandwidth Manager" (BM). The BM is responsible for providing functionality so that a host can request QoS from the network. These functions will be described in detail in the following section. The BM consists of: 1. Bandwidth Allocator (BA): The BA is responsible for tracking the allocation of resources in the subnet. A host can request various services, e.g. bandwidth reservation, change in reservation, query about resource availability, etc. Ghanwani, Pace, Srinivasan Expires 19 March 1997 [Page 1] Internet Draft Integrated Services Over LANs 20 September 1996 2. Requester Module (RM): The RM provides a set of primitives which define the services that are provided by the BA. The host uses these primitives to talk to the RM. The RM will create messages and use the defined protocol to communicate with the BA. Also an integral part of the BM are the protocols and primitives which will enable communication between the various components and between applications and the BM. In the sequel, 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 technology from using this model. 3. Functions of the Bandwidth Manager The BM must be able to provide the functions discussed below. It must be capable of providing these functions for both unicast and multicast sessions. - Bandwidth Reservation: The BM must be capable of reserving bandwidth 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. - QoS Calculations and Admission Control: The BM must be able to compute QoS estimates for a session based on the current levels of resource reservation in order to decide whether or not the session can be admitted. It should also be possible for a host to query the BM to find out if a given QoS can be supported at a given time. The BM must be able to provide different levels of QoS such as guaranteed delay, guaranteed bandwidth, etc. - Policing: The BM needs to perform traffic policing 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 BM must be able to function in the presence of failure. The failure of a single agent should not prevent its functioning altogether. There should be back-up and recovery mechanisms. Ghanwani, Pace, Srinivasan Expires 19 March 1997 [Page 2] Internet Draft Integrated Services Over LANs 20 September 1996 - Synchronization: There should be some mechanism for resolving synchronization and deadlock issues. For instance, the case where multiple sessions request resources on a common part of the network must be correctly handled. - 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. 4. Features of the Bandwidth Manager - Centralized or distributed implementation of the BA: If the BA is centralized, all RMs in the subnet will forward their requests to it. There will be no synchronization and deadlock problems. However, the approach will not scale well if the number of RMs is large. It is likely that each station in the subnet will have an RM. For the purpose of scaling, it would be best if the BA can be implemented with varying degrees of distributedness; a small subnet can be managed by a single BA, while a larger subnet may have many BAs, each responsible for a (non-overlapping) subset of segments and bridges or switches. - MIBs supported: The MIBs that the BM will support need to be specified. - Soft state reservations: The BA must maintain soft-state information about the reservations. This means that reservations must be periodically refreshed by messages from the RM if the reservation is to be maintained; otherwise the reservation will time out after some pre-specified interval. - Independent 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. Ghanwani, Pace, Srinivasan Expires 19 March 1997 [Page 3] Internet Draft Integrated Services Over LANs 20 September 1996 5. Communication Protocols and Primitives for the Bandwidth Manager - Primitives for Communication Between the host and 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. - Communication between the RM and 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. Additional, 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 BAs: If there is more than one BA in the subnet, we must specify a means 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. 6. Definition of Service Classes and Provision of QoS As stated earlier, the Integrated Services working group has defined many service classes offering varying degrees of QoS guarantees. The services include controlled load, controlled delay, predictive service, committed rate and guaranteed service [4,5,6]. Controlled load provides a loose guarantee, informally stated as "better than best effort". The guaranteed service provides the most stringent delay guarantees. The method for providing support for such service classes will be technology dependent and will depend on several factors as outlined below. - The number of delay priorities handled by the technology under consideration will determine how many and what services may be supported. Token ring, for instance, supports eight priority levels. Which of these services will be supported and what priorities they map to must be specified. Ghanwani, Pace, Srinivasan Expires 19 March 1997 [Page 4] Internet Draft Integrated Services Over LANs 20 September 1996 - The interaction with existing infrastructure would need to be specified. For example, FDDI already has a BM called the "Synchronous Bandwidth Manager". The BM for FDDI must be designed so that it takes advantage of this. - In order to avoid over-allocation of bandwidth, it is necessary for bridges and switches to perform filtering which will limit the traffic to only those segments which have receivers, or which are on a path between the sender and receiver. Priorities and filtering are currently being standardized by the IEEE 802 in 802.1p and 802.1Q [1,2]. 7. 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. These functions are expected to be provided by a "bandwidth manager". The functional requirements of such a bandwidth manager have been identified and discussed. References [1] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Traffic Class and Dynamic Multicast Filtering 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] F. Baker et. al., "Specification of Committed Rate Quality of Service", Internet Draft, June 1996, Ghanwani, Pace, Srinivasan Expires 19 March 1997 [Page 5] Internet Draft Integrated Services Over LANs 20 September 1996 [6] 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 E-mail: 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 E-mail: 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 E-mail: vijay@raleigh.ibm.com Ghanwani, Pace, Srinivasan Expires 19 March 1997 [Page 6]