home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-issll-lane-00.txt < prev    next >
Text File  |  1996-11-27  |  12KB  |  244 lines
  1.  
  2.  
  3.  
  4.  
  5.        Internet Engineering Task Force                       Eric S. Crawley
  6.        Internet-Draft                                     Bay Networks, Inc.
  7.        draft-ietf-issll-lane-00.txt                            November 1996
  8.  
  9.              Integrated Services over ATM LAN Emulation (LANE) Networks
  10.  
  11.        Status Of This Memo
  12.        This document is an Internet-Draft. Internet-Drafts are working
  13.        documents of the Internet Engineering Task Force (IETF), its areas, and
  14.        its working groups. Note that other groups may also distribute working
  15.        documents as Internet-Drafts.
  16.  
  17.        Internet-Drafts are draft documents valid for a maximum of six months
  18.        and may be updated, replaced, or obsoleted by other documents at any
  19.        time. It is inappropriate to use Internet- Drafts as reference material
  20.        or to cite them other than as _work in progress_.
  21.        To learn the current status of any Internet-Draft, please check the
  22.        _1id-abstracts. txt_ listing contained in the Internet- Drafts Shadow
  23.        Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
  24.        ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  25.  
  26.        Abstract
  27.        This document discusses the mapping of the Integrated Services
  28.        (IntServ) models to ATM Forum LAN Emulation version 2 (LANEv2)
  29.        networks.  This involves the combination of three items:  LANEv2, IEEE
  30.        802.1p, and mapping of IntServ models to ATM.
  31.  
  32.        1. Introduction
  33.        As the name states, LANE [1-3] tries to emulate the behavior of IEEE
  34.        802 style networks but has access to the QoS facilities that ATM can
  35.        provide.  Although these features are not used in LANEv1, LANEv2 is
  36.        expected to utilize them and have QoS capabilities.  Given that IEEE
  37.        802.1 is developing class of service mechanisms for 802 networks, it
  38.        only makes sense to apply these to LANE and utilize some of the
  39.        mappings being defined for IntServ services over ATM to create QoS
  40.        capabilities that can meet the needs of IntServ and LANE.
  41.  
  42.        2. LANE
  43.        The ATM Forum's LAN Emulation (LANE) standard is a simple way to use
  44.        ATM to connect network devices so they appear to each other as devices
  45.        on an IEEE 802-style network (e.g. Ethernet).  It hides the mechanisms
  46.        of ATM from the layer 2 and higher protocols allowing for quick
  47.        adoption of ATM.  LANE provides services for address resolution,
  48.        broadcast, and multicast so the LAN Emulation Client (LEC) behaves like
  49.        it would on a traditional multi-access LAN.  LANEv2, currently under
  50.        development in the ATM Forum provides enhanced capabilities over LANEv1
  51.        including enhanced multicast support, server redundancy, and QoS.
  52.  
  53.        LECs set up ATM Virtual Circuits (referred to as Data Direct VCs or
  54.        DDVCs) between each other in order to transfer data.  VCs are set up in
  55.        response to LANE ARP Requests (LE_ARPs).  When one LEC wants to
  56.        transmit data to another LEC, it LE_ARPs for the destination MAC
  57.        address.  The LEC that services the requested MAC address responds and
  58.  
  59.  
  60.  
  61.        E. Crawley                 Expires May 1997                     Page 1
  62.  
  63.        INTERNET DRAFT      Integrated Services over LANE        November 1996
  64.  
  65.        sets up a DDVC back to the requesting LEC.  MAC addresses are
  66.        maintained in the native format of the type of LAN being emulated.
  67.  
  68.        3. IEEE 802.1p
  69.        IEEE has been adding a class of service capability in 802.1p [5] and
  70.        802.1Q [4].  There are three bits that specify the _User Priority_ for
  71.        a given frame.  This yields 8 different service classes. The minimal
  72.        implementation of these services is a strict priority with larger
  73.        values getting a greater priority (0 = lowest, 7 = highest).  It is
  74.        even possible to limit the number of queues by lumping multiple
  75.        priorities into the same queue.  While this is the minimal
  76.        interpretation, it is also possible to assign specific behaviors to the
  77.        User Priorities.  This document will discuss mapping specific IntServ
  78.        behaviors to particular priorities for 802.1p when applied to LANE.
  79.        [10] discusses the use of specific 802.1p priorities for particular
  80.        IntServ models.  Some initial mappings are proposed and a mechanism
  81.        that allows an end system to request what priority to use for a
  82.        particular flow is discussed.
  83.  
  84.        While [10] discusses many of the architectural and protocol
  85.        considerations for mapping user priorities, the basic mapping can be
  86.        fairly simple.  The following is one such example taken from [10].
  87.  
  88.                  Priority  Service
  89.                    0       "less than" Best Effort
  90.                    1       Best Effort
  91.                    2       reserved
  92.                    3       reserved
  93.                    4       Controlled Load
  94.                    5       reserved
  95.                    6       Guaranteed Service
  96.                    7       reserved
  97.  
  98.        Notice that all the IntServ traffic is set to only two User Priorities.
  99.        While this may not be an optimal mapping, it is provided here as an
  100.        example.  Further options divide the Guaranteed Service between
  101.        multiple priorities that might provide some specific delay bounds that
  102.        more closely match application needs.
  103.  
  104.        4. Applying 802.1p to LANE
  105.        The application of IEEE 802.1p to LANE is described in [6].  The basic
  106.        scheme allows multiple Data Direct VCs to be set up between LECs for
  107.        each 802.1p User Priority.  This means that a LEC can have up to 8
  108.        different DDVCs between it and any other LEC on the Emulated LAN
  109.        (ELAN).  The call setup parameters for each type of VC can be set up by
  110.        an administrator and provided to the LEC from the LAN Emulation
  111.        Configuration Server (LECS).  When the LEC transmits a packet, it
  112.        checks the User Priority and places on the DDVC that corresponds to the
  113.        priority.  This means that all queue management is handled by ATM
  114.        traffic management, eliminating the need for a separate packet
  115.        scheduler in the LEC.
  116.  
  117.        The remaining problem is to determine what call setup parameters should
  118.        be used for the DDVCs that carry traffic corresponding to the IntServ
  119.  
  120.  
  121.        E. Crawley                 Expires May 1997                     Page 2
  122.  
  123.        INTERNET DRAFT      Integrated Services over LANE        November 1996
  124.  
  125.  
  126.        Controlled Load [7] and Guaranteed Service [8] models.  In the example
  127.        provided in section 3, these parameters would be used for the VCs for
  128.        priorities 4 and 6.
  129.  
  130.        5. Integrated Services Mapping to ATM
  131.        [9] describes the mapping of the Controlled Load and Guaranteed Service
  132.        models to IETF IP over ATM networks. This provides a set of call setup
  133.        parameters that can be used for supporting the IntServ Controlled Load
  134.        and Guaranteed Service models.  These call setup parameters can be
  135.        applied to the VCs that are set up by the LECs.  This allows the LEC to
  136.        provide very specific support for IntServ flows as IEEE 802.1p
  137.        priorities on emulated LANs.  [9] allows for multiple mappings from
  138.        IntServ to ATM based on the IntServ model and the ATM service
  139.        categories available. For example, Guaranteed Service can be mapped to
  140.        both Constant Bit Rate (CBR) and real time Variable Bit Rate (rtVBR)
  141.        service classes with appropriate call setup parameters for each.  For
  142.        the VCs corresponding to the priorities and service models used, the
  143.        call setup parameters can be determined to provide the proper QoS
  144.        required by the service model.
  145.  
  146.        6. The Missing Pieces
  147.        Since LECs will possibly be sending traffic for multiple flows over the
  148.        same DDVC, the sizing of the DDVC becomes an important management
  149.        problem.  The DDVCs must be sized to accommodate all the traffic for a
  150.        particular class.  For example, if a rtVBR VC with a Maximum Cell Rate
  151.        (MCR) that equates to a bandwidth of 10Mb/s, is created to carry all
  152.        the Controlled Load traffic from a given LEC, then the amount of
  153.        Controlled Load traffic cannot exceed 10Mb/s even though the LEC may
  154.        have a link to the ATM network that runs at a much higher rate.
  155.        Additionally, either the traffic sources must be well behaved or the VC
  156.        must be over-allocated to handle situations where multiple flows are
  157.        aggregated over the same priority.  It should be noted that this does
  158.        solve some of the scaling problems for IntServ over ATM noted in [11]
  159.        and [12] by aggregating multiple flows over a single VC.
  160.  
  161.        The setup parameters for the 802.1p traffic classes must be extracted
  162.        from [9] and added to the MIBs used by the LANE Configuration Server
  163.        with comments about which values should be administratively controlled
  164.        by the network administrator.  This is reserved for a future revision
  165.        of this draft.
  166.  
  167.        7. Security Considerations
  168.        Security issues are not discussed in this memo.
  169.  
  170.        8. References
  171.        1. ATM Forum Technical Committee. LAN Emulation over ATM, Version 1.0
  172.          Specification, af-lane-0021.000, January 1995.
  173.        2. ATM Forum Technical Committee. LAN Emulation over ATM Version 2 -
  174.          LNNI Specification - Draft 7, BTD-LANE-LNNI-02.07, December 1996.
  175.        3. ATM Forum Technical Committee. LAN Emulation over ATM Version 2 -
  176.          LUNI Specification - Draft 5, BTD-LANE-LUNI-02.05, December 1996.
  177.        4. LAN MAN Standards Committee of the IEEE Computer Society. Draft
  178.          Standard for Virtual Bridged Local Area Networks, P802.1Q.
  179.  
  180.  
  181.  
  182.        E. Crawley                 Expires May 1997                     Page 3
  183.  
  184.        INTERNET DRAFT      Integrated Services over LANE        November 1996
  185.  
  186.  
  187.        5. LAN MAN Standards Committee of the IEEE Computer Society. Draft
  188.          Standard for Traffic Class and Dynamic Multicast Filtering Services
  189.          in Bridged Local Area Networks (Draft Supplement to 802.1D),
  190.          P802.1p.
  191.        6. E. Crawley, J. Luciani, N. Finn. LANE QoS Using IEEE 802.1p Service
  192.          Classes, ATM Forum Contribution, AF-96-1632.
  193.        7. J. Wroclawski. Specification of the Controlled-Load Network Element
  194.          Service. Internet Draft, draft-ietf-intserv-ctrl-load-svc-03.txt,
  195.          August 1996.
  196.        8. S. Shenker, C. Partridge, R. Guerin. Specification of Guaranteed
  197.          Quality of Service. Internet Draft, draft-ietf-intserv-guaranteed-
  198.          svc-06.txt, June 1996.
  199.        9. M. Borden, M. Garrett. Interoperation of Controlled-Load and
  200.          Guaranteed Service with ATM, Internet Draft, draft-ietf-issll-atm-
  201.          mapping-00.txt, September, 1996.
  202.        10. M. Seaman, A. Smith, E. Crawley. Integrated Services over IEEE
  203.          802.1D/802.1p Networks. Internet Draft, draft-ietf-issll-802-00.txt.
  204.        11. L. Berger, S. Berson, IP Integrated Services with RSVP over ATM.
  205.          Internet Draft, draft-ietf-issll-atm-support-01.txt, September 24,
  206.          1996.
  207.        12. M. Borden, E. Crawley, B. Davie, S. Batsell.  Integration of Real-
  208.          Time Services in an IP-ATM Network Architecture,  RFC1821, August
  209.          1995.
  210.  
  211.  
  212.        9. Author's Address
  213.        Eric S. Crawley
  214.        Bay Networks, Inc.
  215.        3 Federal Street
  216.        Billerica, MA 01821
  217.        esc@baynetworks.com
  218.        +1-508-670-8888
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.        E. Crawley                 Expires May 1997                Page 4
  244.