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