Internet Engineering Task Force Eric S. Crawley Internet-Draft Bay Networks, Inc. draft-ietf-issll-lane-00.txt November 1996 Integrated Services over ATM LAN Emulation (LANE) Networks 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 inappropriate to use Internet- Drafts as reference material or to cite them other than as _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 This document discusses the mapping of the Integrated Services (IntServ) models to ATM Forum LAN Emulation version 2 (LANEv2) networks. This involves the combination of three items: LANEv2, IEEE 802.1p, and mapping of IntServ models to ATM. 1. Introduction As the name states, LANE [1-3] tries to emulate the behavior of IEEE 802 style networks but has access to the QoS facilities that ATM can provide. Although these features are not used in LANEv1, LANEv2 is expected to utilize them and have QoS capabilities. Given that IEEE 802.1 is developing class of service mechanisms for 802 networks, it only makes sense to apply these to LANE and utilize some of the mappings being defined for IntServ services over ATM to create QoS capabilities that can meet the needs of IntServ and LANE. 2. LANE The ATM Forum's LAN Emulation (LANE) standard is a simple way to use ATM to connect network devices so they appear to each other as devices on an IEEE 802-style network (e.g. Ethernet). It hides the mechanisms of ATM from the layer 2 and higher protocols allowing for quick adoption of ATM. LANE provides services for address resolution, broadcast, and multicast so the LAN Emulation Client (LEC) behaves like it would on a traditional multi-access LAN. LANEv2, currently under development in the ATM Forum provides enhanced capabilities over LANEv1 including enhanced multicast support, server redundancy, and QoS. LECs set up ATM Virtual Circuits (referred to as Data Direct VCs or DDVCs) between each other in order to transfer data. VCs are set up in response to LANE ARP Requests (LE_ARPs). When one LEC wants to transmit data to another LEC, it LE_ARPs for the destination MAC address. The LEC that services the requested MAC address responds and E. Crawley Expires May 1997 Page 1 INTERNET DRAFT Integrated Services over LANE November 1996 sets up a DDVC back to the requesting LEC. MAC addresses are maintained in the native format of the type of LAN being emulated. 3. IEEE 802.1p IEEE has been adding a class of service capability in 802.1p [5] and 802.1Q [4]. There are three bits that specify the _User Priority_ for a given frame. This yields 8 different service classes. The minimal implementation of these services is a strict priority with larger values getting a greater priority (0 = lowest, 7 = highest). It is even possible to limit the number of queues by lumping multiple priorities into the same queue. While this is the minimal interpretation, it is also possible to assign specific behaviors to the User Priorities. This document will discuss mapping specific IntServ behaviors to particular priorities for 802.1p when applied to LANE. [10] discusses the use of specific 802.1p priorities for particular IntServ models. Some initial mappings are proposed and a mechanism that allows an end system to request what priority to use for a particular flow is discussed. While [10] discusses many of the architectural and protocol considerations for mapping user priorities, the basic mapping can be fairly simple. The following is one such example taken from [10]. Priority Service 0 "less than" Best Effort 1 Best Effort 2 reserved 3 reserved 4 Controlled Load 5 reserved 6 Guaranteed Service 7 reserved Notice that all the IntServ traffic is set to only two User Priorities. While this may not be an optimal mapping, it is provided here as an example. Further options divide the Guaranteed Service between multiple priorities that might provide some specific delay bounds that more closely match application needs. 4. Applying 802.1p to LANE The application of IEEE 802.1p to LANE is described in [6]. The basic scheme allows multiple Data Direct VCs to be set up between LECs for each 802.1p User Priority. This means that a LEC can have up to 8 different DDVCs between it and any other LEC on the Emulated LAN (ELAN). The call setup parameters for each type of VC can be set up by an administrator and provided to the LEC from the LAN Emulation Configuration Server (LECS). When the LEC transmits a packet, it checks the User Priority and places on the DDVC that corresponds to the priority. This means that all queue management is handled by ATM traffic management, eliminating the need for a separate packet scheduler in the LEC. The remaining problem is to determine what call setup parameters should be used for the DDVCs that carry traffic corresponding to the IntServ E. Crawley Expires May 1997 Page 2 INTERNET DRAFT Integrated Services over LANE November 1996 Controlled Load [7] and Guaranteed Service [8] models. In the example provided in section 3, these parameters would be used for the VCs for priorities 4 and 6. 5. Integrated Services Mapping to ATM [9] describes the mapping of the Controlled Load and Guaranteed Service models to IETF IP over ATM networks. This provides a set of call setup parameters that can be used for supporting the IntServ Controlled Load and Guaranteed Service models. These call setup parameters can be applied to the VCs that are set up by the LECs. This allows the LEC to provide very specific support for IntServ flows as IEEE 802.1p priorities on emulated LANs. [9] allows for multiple mappings from IntServ to ATM based on the IntServ model and the ATM service categories available. For example, Guaranteed Service can be mapped to both Constant Bit Rate (CBR) and real time Variable Bit Rate (rtVBR) service classes with appropriate call setup parameters for each. For the VCs corresponding to the priorities and service models used, the call setup parameters can be determined to provide the proper QoS required by the service model. 6. The Missing Pieces Since LECs will possibly be sending traffic for multiple flows over the same DDVC, the sizing of the DDVC becomes an important management problem. The DDVCs must be sized to accommodate all the traffic for a particular class. For example, if a rtVBR VC with a Maximum Cell Rate (MCR) that equates to a bandwidth of 10Mb/s, is created to carry all the Controlled Load traffic from a given LEC, then the amount of Controlled Load traffic cannot exceed 10Mb/s even though the LEC may have a link to the ATM network that runs at a much higher rate. Additionally, either the traffic sources must be well behaved or the VC must be over-allocated to handle situations where multiple flows are aggregated over the same priority. It should be noted that this does solve some of the scaling problems for IntServ over ATM noted in [11] and [12] by aggregating multiple flows over a single VC. The setup parameters for the 802.1p traffic classes must be extracted from [9] and added to the MIBs used by the LANE Configuration Server with comments about which values should be administratively controlled by the network administrator. This is reserved for a future revision of this draft. 7. Security Considerations Security issues are not discussed in this memo. 8. References 1. ATM Forum Technical Committee. LAN Emulation over ATM, Version 1.0 Specification, af-lane-0021.000, January 1995. 2. ATM Forum Technical Committee. LAN Emulation over ATM Version 2 - LNNI Specification - Draft 7, BTD-LANE-LNNI-02.07, December 1996. 3. ATM Forum Technical Committee. LAN Emulation over ATM Version 2 - LUNI Specification - Draft 5, BTD-LANE-LUNI-02.05, December 1996. 4. LAN MAN Standards Committee of the IEEE Computer Society. Draft Standard for Virtual Bridged Local Area Networks, P802.1Q. E. Crawley Expires May 1997 Page 3 INTERNET DRAFT Integrated Services over LANE November 1996 5. LAN MAN Standards Committee of the IEEE Computer Society. Draft Standard for Traffic Class and Dynamic Multicast Filtering Services in Bridged Local Area Networks (Draft Supplement to 802.1D), P802.1p. 6. E. Crawley, J. Luciani, N. Finn. LANE QoS Using IEEE 802.1p Service Classes, ATM Forum Contribution, AF-96-1632. 7. J. Wroclawski. Specification of the Controlled-Load Network Element Service. Internet Draft, draft-ietf-intserv-ctrl-load-svc-03.txt, August 1996. 8. S. Shenker, C. Partridge, R. Guerin. Specification of Guaranteed Quality of Service. Internet Draft, draft-ietf-intserv-guaranteed- svc-06.txt, June 1996. 9. M. Borden, M. Garrett. Interoperation of Controlled-Load and Guaranteed Service with ATM, Internet Draft, draft-ietf-issll-atm- mapping-00.txt, September, 1996. 10. M. Seaman, A. Smith, E. Crawley. Integrated Services over IEEE 802.1D/802.1p Networks. Internet Draft, draft-ietf-issll-802-00.txt. 11. L. Berger, S. Berson, IP Integrated Services with RSVP over ATM. Internet Draft, draft-ietf-issll-atm-support-01.txt, September 24, 1996. 12. M. Borden, E. Crawley, B. Davie, S. Batsell. Integration of Real- Time Services in an IP-ATM Network Architecture, RFC1821, August 1995. 9. Author's Address Eric S. Crawley Bay Networks, Inc. 3 Federal Street Billerica, MA 01821 esc@baynetworks.com +1-508-670-8888 E. Crawley Expires May 1997 Page 4