Network Working Group A. Ghanwani Request for Comments: 2816 Nortel Networks Category: Informational W. Pace IBM V. Srinivasan CoSine Communications A. Smith Extreme Networks M. Seaman Telseon May 2000 A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo describes a framework for supporting IETF Integrated Services on shared and switched LAN infrastructure. It includes background material on the capabilities of IEEE 802 like networks with regard to parameters that affect Integrated Services such as access latency, delay variation and queuing support in LAN switches. It discusses aspects of IETF's Integrated Services model that cannot easily be accommodated in different LAN environments. It outlines a functional model for supporting the Resource Reservation Protocol (RSVP) in such LAN environments. Details of extensions to RSVP for use over LANs are described in an accompanying memo [14]. Mappings of the various Integrated Services onto IEEE 802 LANs are described in another memo [13]. Ghanwani, et al. Informational [Page 1] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000 Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 2. Document Outline . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 4. Frame Forwarding in IEEE 802 Networks . . . . . . . . . . 5 4.1. General IEEE 802 Service Model . . . . . . . . . . . 5 4.2. Ethernet/IEEE 802.3 . . . . . . . . . . . . . . . . . 7 4.3. Token Ring/IEEE 802.5 . . . . . . . . . . . . . . . . 8 4.4. Fiber Distributed Data Interface . . . . . . . . . . 10 4.5. Demand Priority/IEEE 802.12 . . . . . . . . . . . . . 10 5. Requirements and Goals . . . . . . . . . . . . . . . . . . 11 5.1. Requirements . . . . . . . . . . . . . . . . . . . . 11 5.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . 13 5.3. Non-goals . . . . . . . . . . . . . . . . . . . . . . 14 5.4. Assumptions . . . . . . . . . . . . . . . . . . . . . 14 6. Basic Architecture . . . . . . . . . . . . . . . . . . . . 15 6.1. Components . . . . . . . . . . . . . . . . . . . . . 15 6.1.1. Requester Module . . . . . . . . . . . . . . 15 6.1.2. Bandwidth Allocator . . . . . . . . . . . . . 16 6.1.3. Communication Protocols . . . . . . . . . . . 16 6.2. Centralized vs. Distributed Implementations . . . . 17 7. Model of the Bandwidth Manager in a Network . . . . . . . 18 7.1. End Station Model . . . . . . . . . . . . . . . . . . 19 7.1.1. Layer 3 Client Model . . . . . . . . . . . . 19 7.1.2. Requests to Layer 2 ISSLL . . . . . . . . . . 19 7.1.3. At the Layer 3 Sender . . . . . . . . . . . . 20 7.1.4. At the Layer 3 Receiver . . . . . . . . . . . 21 7.2. Switch Model . . . . . . . . . . . . . . . . . . . . 22 7.2.1. Centralized Bandwidth Allocator . . . . . . . 22 7.2.2. Distributed Bandwidth Allocator . . . . . . . 23 7.3. Admission Control . . . . . . . . . . . . . . . . . . 25 7.4. QoS Signaling . . . . . . . . . . . . . . . . . . . . 26 7.4.1. Client Service Definitions . . . . . . . . . 26 7.4.2. Switch Service Definitions . . . . . . . . . 27 8. Implementation Issues . . . . . . . . . . . . . . . . . . 28 8.1. Switch Characteristics . . . . . . . . . . . . . . . 29 8.2. Queuing . . . . . . . . . . . . . . . . . . . . . . . 30 8.3. Mapping of Services to Link Level Priority . . . . . 31 8.4. Re-mapping of Non-conforming Aggregated Flows . . . . 31 8.5. Override of Incoming User Priority . . . . . . . . . 32 8.6. Different Reservation Styles . . . . . . . . . . . . 32 8.7. Receiver Heterogeneity . . . . . . . . . . . . . . . 33 9. Network Topology Scenarios . . . . . . . . . . . . . . . 35 9.1. Full Duplex Switched Networks . . . . . . . . . . . . 36 9.2. Shared Media Ethernet Networks . . . . . . . . . . . 37 9.3. Half Duplex Switched Ethernet Networks . . . . . . . 38 9.4. Half Duplex Switched and Shared Token Ring Networks . 39 Ghanwani, et al. Informational [Page 2] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000 9.5. Half Duplex and Shared Demand Priority Networks . . . 40 10. Justification . . . . . . . . . . . . . . . . . . . . . . 42 11. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 43 References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Security Considerations . . . . . . . . . . . . . . . . . . . 45 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 47 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 and Internet telephony, there has been much interest for developing mechanisms which enable real time services over the Internet. A framework for meeting these new requirements was set out in RFC 1633 [8] and this has driven the specification of various classes of network service by the Integrated Services working group of the IETF, such as Controlled Load and Guaranteed Service [6,7]. Each of these service classes is designed to provide certain Quality of Service (QoS) to traffic conforming to a specified set of parameters. Applications are expected to choose one of these classes according to their QoS requirements. One mechanism for end stations to utilize such services in an IP network is provided by a QoS signaling protocol, the Resource Reservation Protocol (RSVP) [5] developed by the RSVP working group of the IETF. The IEEE under its Project 802 has defined standards for many different local area network technologies. These all typically offer the same MAC layer datagram service [1] to higher layer protocols such as IP although they often provide different dynamic behavior characteristics -- it is these that are important when considering their ability to support real time services. Later in this memo we describe some of the relevant characteristics of the different MAC layer LAN technologies. In addition, IEEE 802 has defined standards for bridging multiple LAN segments together using devices known as "MAC Bridges" or "Switches" [2]. Recent work has also defined traffic classes, multicast filtering, and virtual LAN capabilities for these devices [3,4]. Such LAN technologies often constitute the last hop(s) between users and the Internet as well as being a primary building block for entire campus networks. It is therefore necessary to provide standardized mechanisms for using these technologies to support end-to-end real time services. In order to do this, there must be some mechanism for resource management at the data link layer. Resource management in this context encompasses the functions of admission control, scheduling, traffic policing, etc. The ISSLL (Integrated Services Ghanwani, et al. Informational [Page 3] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000 over Specific Link Layers) working group in the IETF was chartered with the purpose of exploring and standardizing such mechanisms for various link layer technologies. 2. Document Outline This document is concerned with specifying a framework for providing Integrated Services over shared and switched LAN technologies such as Ethernet/IEEE 802.3, Token Ring/IEEE 802.5, FDDI, etc. We begin in Section 4 with a discussion of the capabilities of various IEEE 802 MAC layer technologies. Section 5 lists the requirements and goals for a mechanism capable of providing Integrated Services in a LAN. The resource management functions outlined in Section 5 are provided by an entity referred to as a Bandwidth Manager (BM). The architectural model of the BM is described in Section 6 and its various components are discussed in Section 7. Some implementation issues with respect to link layer support for Integrated Services are examined in Section 8. Section 9 discusses a taxonomy of topologies for the LAN technologies under consideration with an emphasis on the capabilities of each which can be leveraged for enabling Integrated Services. This framework makes no assumptions about the 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 or technology, but this should not preclude the usage of this model for it. 3. Definitions The following is a list of terms used in this and other ISSLL documents. - Link Layer or Layer 2 or L2: Data link layer technologies such as Ethernet/IEEE 802.3 and Token Ring/IEEE 802.5 are referred to as Layer 2 or L2. - Link Layer Domain or Layer 2 Domain or L2 Domain: Refers to a set of nodes and links interconnected without passing through a L3 forwarding function. One or more IP subnets can be overlaid on a L2 domain. - Layer 2 or L2 Devices: Devices that only implement Layer 2 functionality as Layer 2 or L2 devices. These include IEEE 802.1D [2] bridges or switches. - Internetwork Layer or Layer 3 or L3: Refers to Layer 3 of the ISO OSI model. This memo is primarily concerned with networks that use the Internet Protocol (IP) at this layer. Ghanwani, et al. Informational [Page 4] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000 - Layer 3 Device or L3 Device or End Station: These include hosts and routers that use L3 and higher layer protocols or application programs that need to make resource reservations. - Segment: A physical L2 segment that is shared by one or more senders. Examples of segments include: (a) a shared Ethernet or Token Ring wire resolving contention for media access using CSMA or token passing; (b) a half duplex link between two stations or switches; (c) one direction of a switched full duplex link. - Managed Segment: A managed segment is a segment with a DSBM (designated subnet bandwidth manager, see [14]) present and responsible for exercising admission control over requests for resource reservation. A managed segment includes those interconnected parts of a shared LAN that are not separated by DSBMs. - Traffic Class: Refers to an aggregation of data flows which are given similar service within a switched network. - Subnet: Used in this memo to indicate a group of L3 devices sharing a common L3 network address prefix along with the set of segments making up the L2 domain in which they are located. - Bridge/Switch: A Layer 2 forwarding device as defined by IEEE 802.1D [2]. The terms bridge and switch are used synonymously in this memo. 4. Frame Forwarding in IEEE 802 Networks 4.1. General IEEE 802 Service Model The user_priority is a value associated with the transmission and reception of all frames in the IEEE 802 service model. It is supplied by the sender that is using the MAC service and is provided along with the data to a receiver using the MAC service. It may or may not be actually carried over the network. Token Ring/IEEE 802.5 carries this value encoded in its FC octet while basic Ethernet/IEEE 802.3 does not carry it. IEEE 802.12 may or may not carry it depending on the frame format in use. When the frame format in use is IEEE 802.5, the user_priority is carried explicitly. When IEEE 802.3 frame format is used, only the two levels of priority (high/low) that are used to determine access priority can be recovered. This is based on the value of priority encoded in the start delimiter of the IEEE 802.3 frame. Ghanwani, et al. Informational [Page 5] RFC 2816 Framework for Int-Serv Over IEEE 802 LAN May 2000 NOTE: The original IEEE 802.1D standard [2] contains the specifications for the operation of MAC bridges. This has recently been extended to include support for traffic classes and dynamic multicast filtering [3]. In this document, the reader should be aware that references to the IEEE 802.1D standard refer to [3], unless explicitly noted otherwise. IEEE 802.1D [3] defines a consistent way for carrying the value of the user_priority over a bridged network consisting of Ethernet, Token Ring, Demand Priority, FDDI or other MAC layer media using an extended frame format. The usage of user_priority is summarized below. We refer the interested reader to the IEEE 802.1D specification for further information. If the user_priority is carried explicitly in packets, its utility is as a simple label enabling packets within a data stream in different classes to be discriminated easily by downstream nodes without having to parse the packet in more detail. Apart from making the job of desktop or wiring closet switches easier, an explicit field means they do not have to change hardware or software as the rules for classifying packets evolve; e.g. based on new protocols or new policies. More sophisticated Layer 3 switches, perhaps deployed in the core of a network, may be able to provide added value by performing packet classification more accurately and, hence, utilizing network resources more efficiently and providing better isolation between flows. This appears to be a good economic choice since there are likely to be very many more desktop/wiring closet switches in a network than switches requiring Layer 3 functionality. The IEEE 802 specifications make no assumptions about how user_priority is to be used by end stations or by the network. Although IEEE 802.1D defines static priority queuing as the default mode of operation of switches that implement multiple queues, the user_priority is really a priority only in a loose sense since it depends on the number of traffic classes actually implemented by a switch. The user_priority is defined as a 3 bit quantity with a value of 7 representing the highest priority and a value of 0 as the lowest. The general switch algorithm is as follows. Packets are queued within a particular traffic class based on the received user_priority, the value of which is either obtained directly from the packet if an IEEE 802.1Q header or IEEE 802.5 network is used, or is assigned according to some local policy. The queue is selected based on a mapping from