Network Working Group                             Tissa Senevirathne
   Internet Draft                                             (Force10)
   Document: draft-tsenevir-l2-req-00.txt             Waldemar Augustyn
   Category: Informational                            (Nortel Networks)

                                                              May, 2001


                Requirements for Network Based Layer 2 VPN

Status of this Memo


   This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of RFC2026 [1].

   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."
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


   For potential updates to the above required-text see:
   http://www.ietf.org/ietf/1id-guidelines.txt



1. Abstract

   Requirements that needed to be considered when implementing or
   providing Layer 2 NBVPN services are presented. This document does
   not suggest any specific solution, instead outline the requirements
   that need to be satisfied.



Senevirathne et. al, Informational û October 2001                    1
                     draft-tsenevir-l2-req-00.txt             May 2001



2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [2].


Table of Content

3. Introduction.......................................................2
3.1 Background........................................................4
4. Requirements for Network Based Layer 2 VPN.........................5
4.1  Layer 2 Domain representation and VLAN allocation................5
4.2  Customer End-point and VLAN discovery............................6
4.2.1 End-point-VLAN policies.........................................6
4.2.2 End-point VLAN tag translation..................................6
4.3 Customer end point inter connection...............................7
4.4  Layer 2 Virtual Forwarding Instance..............................7
4.5 MAC address learning..............................................7
4.6  Unknown, Multicast and Broadcast forwarding......................8
4.6.1  Multi site spanning broadcast domains..........................8
4.6.2 Group (Multicast) Address Registration Services.................9
4.6.3 Scope of Unknown MAC Addresses..................................9
4.7 Mac address transparency in the core..............................9
4.8 Support for Layer 2 control protocols such as GVRP and STP.......10
4.9 Recovery and Restoration.........................................11
4.10 Security Requirements...........................................11
4.11 Dynamic Service Signaling.......................................12
4.12 Graceful reconfiguration........................................12
4.13 Immunity from malformed customer traffic........................12
4.14 Class of Service Model..........................................12
4.15 Minimum MTU.....................................................12
4.16 Packet re-ordering or duplication...............................12
4.17 L3, and higher, service access point............................12
4.18 Monitoring......................................................13
4.19 Support for MAC Services........................................13
4.19.1 Preservation of MAC services..................................13
4.19.2 Quality of service maintenance................................13
4. References........................................................16
5. Acknowledgments...................................................16
6. Author's Addresses................................................16
Appendix A: Acronyms and Abbreviations...............................16
Full Copyright Statement.............................................18


3. Introduction


Senevirathne et.al,    Informational û October 2001                  2
                     draft-tsenevir-l2-req-00.txt             May 2001


   Traditionally, the typical connectivity between a service provider
   and a customer is a WAN link with some type of a point-to-point
   protocol. This arrangement was borne out of the necessity to
   traverse TDM circuits originally designed for voice traffic. The
   introduction of WAN links to network architecture significantly
   increased the complexity of the network topologies and required high
   skilled personnel to manage and maintain the network.

   The L2 protocols running over WAN networked served the sole purpose
   of bringing customer traffic to the network core.  These protocols
   did not find any other use in a typical customer network and only
   burdened the customer with the necessity to acquire knowledge skills
   and maintenance ability.

   With the explosive growth of the Internet, the metro networks change
   and now offer data oriented connectivity.  The lower cost of fiber
   and the popularity of Optical Ethernet brings the opportunity to
   eliminate unnecessary complexity of WAN networks.  More and more,
   the customers have the opportunity to extend their networks via a
   service provider by running native L2 protocols, such as Ethernet,
   without having to go through a complex and unnecessary
   transformation to WAN protocols.

   Optical based network infrastructure is growing. It is anticipated
   that most slow speed T rate links will be replaced by optical
   technology based connections. With the optical technology based WAN
   links, the inter site connections are no longer limited to T rate.
   Thus eliminating the speed bottleneck that was present in historical
   remote bridged networks. At the same time cost of high speed optical
   connections are decreasing. It is anticipated the cost of 1Gps
   optical connection will be comparable to a 155 Mbps T1 connection.

   VPN technology is widely used for providing Layer 3 routed VPN. When
   providing network based VPN services the PE devices are required to
   maintain the private IP routing tables of the customers. It is
   theoretically possible that customers are maintaining large routing
   tables. Requirements by PE devices to maintain large routing tables
   seriously affect the scalability of PE devices. On the other hand,
   in a given LAN segment, there is only a finite set of MAC devices.
   Typically, the number of MAC addresses in a given LAN is much less
   than an average routing table of a network. In addition, when
   providing routed VPN services, PE devices are required to support
   different routing protocols such as BGP, OSPF, so that the PE device
   could learn routing updates from the CPE. In addition, some times,
   PE devices may require to maintain separate routing instance per
   Layer 3 NBVPN. Requirement for complex routing protocols not only
   increase the complexity of the product, it also make the product
   more expensive. On the other hand, Layer 2 VPN services do not
   require any additional routing protocol support between the CE and
   the PE devices.

   Given the above reasons, it appears that Network Based Layer 2 VPN
   services are cheaper, easy to manage and transparent. It is

Senevirathne et.al,    Informational û October 2001                  3
                     draft-tsenevir-l2-req-00.txt             May 2001


   anticipated that networks based Layer 2 VPN may be a key service in
   future metro service infrastructure.

   In this document we attempt to outline the requirements for network
   based Layer 2 VPN services. The work presented in this document
   intends to serve as a guideline for equipment vendors and service
   providers. This document does not discuss any specific protocol,
   however it does specifies requirements that needed to be satisfied
   by a given protocol.


3.1 Background

   Typically Layer 2 NBVPN may be used to connect a local LAN segment
   to multiple remote LAN segments. These LAN segments may contain one
   or more Work stations. A pictorial representation of a typical
   deployment is depicted below.

   |
                                              %
                                              |
                                           -------        |----a'
                    |                     |  PE   |       o
                    %                -----|   B   |--o-o--|----b'
                    |               /     |       |       o
     a-----|      ------           /       ------         |----c'
           o     |  PE  |         /           |          CE B
     b-----|-o-o-|   A  |---------            %
           o     |      |         \
     b-----|      ------           \          %
                    |               \      -------        |----x
        CE  A       %                -----|   PE  |       o
                    |                     |    C  |-o-o-- |----y
                                          |       |       o
                                           -------        | ---z
                                              |           CE C
                                              %
                                              |


   CE - Customer Edge (Represent one more Devices in a LAN)

   PE - Provider Edge

   -o-  Physical Connection

   ---  Logical Connection

   -%-  Partition of Functionality


   Fig: Typical Layer 2 NBVPN deployment


Senevirathne et.al,    Informational û October 2001                  4
                     draft-tsenevir-l2-req-00.txt             May 2001


   In general Layer 2 NBVPN contain multiple end points (sites). These
   end points may or may not be within the same service provider
   infrastructure. Within a given service provider infrastructure there
   exists multiple Layer 2 NBVPN planes that belongs to different
   customers. [3] Has logically represented this as a tower of disks.


                                  |
                          -----------------
                         |                 |  Plane-2
                          -----------------
                                  |
                                  |
                                  |
                                  |
                                  |
                          -----------------
                         |                 | Plane-1
                          -----------------
                                  |
                          -----------------
                         |                 | Infrastructure
                          -----------------

   Fig: Logical representation of Layer 2 NBVPN

   Within each plane, multiple broadcast domains exist based on the
   VLAN usage by the customers. A given VLAN in a given Layer 2 NBVPN
   plane may span across a set of given end points.



4. Requirements for Network Based Layer 2 VPN

   In this section we present key requirements in Network Based Layer 2
   VPN services.


4.1  Layer 2 Domain representation and VLAN allocation

   Layer 2 Network based VPN infrastructure MUST distinguish different
   customer domains. Each of these customer domains MUST appear as a L2
   broadcast domain network behaving like a LAN (Local Area Network).

   Configurations within the provider MUST not constrain customers
   ability to configure VLANs or any other Layer 2 parameters.

   As explained in above section 3.1, Layer 2 NBVPN appears as a
   logical plane in the service infrastructure. The Layer 2 NBVPN plane
   MAY span across multiple service provider infrastructures. Layer 2
   NBVPN Domain Identifier (L2NBVPNDoamin) uniquely identify a given
   Layer 2 NBVPN. The L2NBVPNDoamin identification is hence required to
   be unique within all service providers.

Senevirathne et.al,    Informational û October 2001                  5
                     draft-tsenevir-l2-req-00.txt             May 2001



   It is suggested that L2NBVPNDoamin {AS:L2NBVPNdomain-ID} MAY be
   derived as a combination of AS (Autonomous System) Number and a
   unique number that represent the customer's domain (L2NBVPNdomain-
   ID) within the AS.

   Within a given AS L2NBVPNdomain-ID MUST be unique for all the end
   points in a given L2NBVPN plane.


4.2  Customer End-point and VLAN discovery

   A given customer may have several VLANs spanning multiple sets of
   sites. The L2 NBVPN infrastructure MUST NOT require all VLANs span
   the same set of sites.

   For the purpose of packet forwarding, address learning and tunnel
   construction, the infrastructure MUST employ methods to discover the
   end points that belong to different Layer 2 VLAN domains within a
   single L2 NBVPN plane.


   In simpler small-scale implementations, providers may configure the
   remote end-points and VLAN span manually. Though such methods works
   for smaller deployments, ability to discover and bind remote sites
   is essential in larger deployments. Hence it is required to have
   methods in place to distribute VLAN and domain information.
   Automatic VLAN distribution methods are required to have ability to
   limit the scope of distribution of customers VLAN information.


4.2.1 End-point-VLAN policies

   End-point-VLAN policies are broadly classified in to two categories;
   Announce Polices and Bind polices

   Bind Policies

   Bind polices specifies binding of incoming advertisements to the
   local representation. The End-point-VLAN policies are required to be
   flexible enough to cover different requirements.

   Announce Policies

   Announce policies apply when advertising L2NBVPN information. The
   announce policies identify which reachability information need to be
   advertised and the scope of the advertisement.


4.2.2 End-point VLAN tag translation

   The infrastructure MAY support translation of customersÆ VLAN tags.
   Such service simplifies connectivity of sites that want to keep

Senevirathne et.al,    Informational û October 2001                  6
                     draft-tsenevir-l2-req-00.txt             May 2001


   their tag assignments or sites that belong to different
   administrative entities.  In the latter case, the connectivity is
   sometimes referred to as L2 extranet.


4.3 Customer end point inter connection


   Layer 2 networks require a symmetric connectivity between devices.
   In other words each device MUST have connectivity to all other
   devices.

   Hub and spoke or point-to-multi-point is a popular deployment model
   in legacy Frame Relay networks. When providing routed services,
   inter site traffic is routed via the hub site.

   When providing Layer 2 Connectivity, Hub is required to implement
   complex forwarding policies to achieve symmetric connectivity. On
   the other hand hub and spoke model may be used for deployment that
   does not require symmetric connectivity. Example of such deployment
   is - remote sites that requires connectivity to the data center and
   does not require connectivity between remote sites.

   Many-to-many (either logical or physical) is required to be deployed
   for Layer 2 services that require symmetric connectivity. Enterprise
   networks that extend the private LAN using Layer2 NBVPN require
   many-to-many connectivity.


4.4  Layer 2 Virtual Forwarding Instance

   Traditional Layer 2 devices maintain a separate Layer 2 forwarding
   database per VLAN instance. All forwarding decision for the VLAN is
   made using the Layer 2 forwarding database of that VLAN. Layer 2
   NBVPN providers are required separate forwarding decision between
   customers. Within a given customer domain, forwarding decisions are
   again separated based on VLAN usage. Thus Layer 2 NBVPN requires
   two-level Layer 2 Virtual Forwarding Instance.

   Layer 2 NBVPN, Provider Edge devices MUST have capabilities to
   classify incoming customer traffic into the appropriate customer
   domain and identification of the proper Layer 2 Virtual Forwarding
   instance based on Customer domain and VLAN identifier.

4.5 MAC address learning

   The Layer2 NBVPN is intended to be transparent to L2 customer
   networks.

   Traditional Layer 2 devices learn MAC addresses in the context of a
   VLAN. Such devices learn MAC addresses against a physical/logical
   port.


Senevirathne et.al,    Informational û October 2001                  7
                     draft-tsenevir-l2-req-00.txt             May 2001


   In Layer 2 NBVPN MAC address learning takes place in the context of
   Layer 2 Virtual Forwarding Instance. That is in the context of
   Customer domain and a VLAN. The reachability of MAC addresses may be
   either via a directly attached physical port or a virtual port where
   remote MAC address may be reached. The virtual port may represent a
   physical port, a tunnel or some other logical representation. Hence,
   Layer 2 NBVPN PE devices are required to support virtual port
   concepts.

   It is expected that the Layer 2 NBVPN is able to derive all topology
   and forwarding information from packets originating at end user
   sites.  The service MAY implement a MAC addresses learning mechanism
   for this purpose.

   The Layer 2 NBVPN is intended to be transparent to Layer 2 end user
   networks.  It MUST NOT require any special packet processing by the
   end users before sending packets to the providerÆs network.


4.6  Unknown, Multicast and Broadcast forwarding

   Unknown, Broadcast and Multicast packets are required to be
   forwarded to all endpoints of the given customers given VLAN. The
   scope of Broadcast, Multicast and Unknown is called Broadcast
   domain. For a given customer there are multiple Broadcast domains,
   one for each VLAN.

   The PE device is required to have capabilities to forward traffic to
   multiple end points within a given Broadcast domain.

   The PE device is required to separate traffic between different
   broadcast domains.

   Each Layer 2 VFI instance is required to have flooding capabilities
   in the scope of its broadcast domain to facilitate proper forwarding
   of Broadcast, Multicast and Unknown traffic.
   The Layer2 NBVPN MUST be aware of the existence and the designated
   roles of special MAC addresses such as Multicast and Broadcast
   addresses. The Layer 2 NBVPN MUST forward these packets according to
   their intended functional meaning and scope.

   If the Layer 2 NBVPN relies on MAC learning for its operations, it
   MUST assure proper forwarding of packets with MAC addresses that
   have not been learned.

4.6.1  Multi site spanning broadcast domains

   Broadcast domain is defined as the flooding scope of the Layer 2
   network. Flooding scope of a Layer 2 network is the scope of end
   points that are included in Multicast, Broadcast and Unknown traffic
   forwarding. Each broadcast domain is defined in the context of a
   give customer and the scope of a given VLAN. In other words each

Senevirathne et.al,    Informational û October 2001                  8
                     draft-tsenevir-l2-req-00.txt             May 2001


   Layer 2 VFI MUST contain its own Broadcast domain or a flooding
   scope.


4.6.2 Group (Multicast) Address Registration Services

   Layer 2 NBVPN providers MAY provide Group Address Registration
   service. The Group Address Registration service facilitates
   customers to define applicable flooding scopes for multicast
   addresses. Some available alternatives for Group Address
   Registration services are, IGMP snooping, Generic Multicast Address
   Registration Protocol (GMRP).

   In the absence of Group Address Registration services either
   Provider has to manually configure the scope of the multicast
   addresses or flood the multicast addresses to all endpoints.

4.6.3 Scope of Unknown MAC Addresses

   In general, unknown MAC addresses are flooded to all end point of
   the Layer 2 NBVPN. In order to conserve bandwidth and allow
   security, some customers MAY require Layer 2 NBVPN PE devices
   provide methods to define scope of unicast MAC addresses.


4.7 Mac address transparency in the core

   Traditionally, Layer 2 forwarding requires learning of MAC
   addresses. A given device can only learn a finite set of MAC
   addresses. If Layer 2 NBVPN is implemented with the requirement to
   learn MAC addresses in the core; then the number of Layer 2 NBVPN
   that could be supported in the core will depend on the total number
   of MAC addresses a device can learn. On the other hand any topology
   change in the core may require to relearn MAC addresses. In order to
   keep data flow uninterrupted, during the interval of relearning
   flooding of data is required. Flooding of customer data in the
   network core may affect the available bandwidth. The Layer 2 address
   space of each customer is mutually exclusive from one-another. Hence
   the devices in the core are required to maintain multiple Layer 2
   VFI.

   Large scale Layer 2 NBVPN deployments scaling MAY require to
   implement tunneling method that interconnect remote sites. Tunneling
   protocol defines the forwarding in the core. Topology convergence
   and recovery is part of the tunneling protocol. The customer MAC
   addresses and VLAN are  require to be transparent to the devices in
   the core. Hence the devices in the core are not require to implement
   Layer 2 VFI for all the customers in the network. On the other hand
   the devices in the core may not be Layer 2 devices at all in its
   configuration. Only the PE devices required having Layer 2
   forwarding capabilities in its configuration.


Senevirathne et.al,    Informational û October 2001                  9
                     draft-tsenevir-l2-req-00.txt             May 2001


   The Layer 2 NBVPN is intended to be transparent to all customers
   per-VLAN basis.  The Layer 2 NBVPN MUST NOT rely on global
   uniqueness of MAC addresses.

4.8 Support for Layer 2 control protocols such as GVRP and STP

   The Layer 2 NBVPN in theory emulates a LAN. Hence like physical LAN
   Layer 2 NBVPN SHOULD be transparent to Layer 2 Control protocols
   such as STP. However, optionally, Laver 2 NBVPN PE device MAY
   participate in GVRP to create forwarding scope dynamically, within a
   given customer domain.

   GVRP is used as a dynamic VLAN registration protocol. Traditional
   Layer 2 devices create dynamic Layer 2 forwarding databases based on
   the GVRP registrations from CPE. Layer 2 VPN PE devices are required
   to maintain separate VFI instance for each customer's VLAN. In
   addition, VFI defines binding between the Local VFI and remote end
   points.

   Hence, PE devices that support dynamic VLAN registration via GVRP
   MUST have capabilities to create Layer 2 VFI instances based on
   incoming GVRP registrations. Also PE devices MUST have capabilities
   to bind GVRP registrations to Layer 2 VFI.

   Spanning Tree Protocol (STP) is a widely used Layer 2 protocol to
   prevent loops. Some customers may wish to implement the redundancy
   using STP rather than purchasing a redundant Layer 2 VPN service
   from the provider. The multi-point-to-multi-point Layer 2 VPN
   services in theory emulates legacy LAN topology. Unlike GVRP, the PE
   devices are not required to participate in STP processing. It is
   sufficient to transparently pass incoming BPDU to remote sites.

   Consider the following fully meshed Layer 2 VPN deployment and the
   logical representation of the deployment. It is clear that ability
   of all end devices to receive BPDU is sufficient for proper
   operation of STP.



         ------- (F)                              -------
    CPE |       |--------------------------------|       | CPE  (B)
   ---- |  PE   |---------------              (F)|  PE   |-----
        |  (R)  |               |                |       |      |
         -------                |                 -------       x
                                |                    |   backup |
                                |                    |          x
                                |                 -------       |
                                |                |       | CPE  x
                                 --------------  |  PE   |-----
                                             (F) |       |      (F)
                                                  -------
    Fig: Fully-meshed Layer 2 VPN topology


Senevirathne et.al,    Informational û October 2001                 10
                     draft-tsenevir-l2-req-00.txt             May 2001


        CPE                    CPE -x-x-x-x-x-x-x-  CPE
         |                      |(B)   Backup     (F)|
         |                      |                    |
     --------               ---------            ---------
    |        |             |         |          |         |
    |  PE    |             |  PE     |          |   PE    |
    |        |             |         |          |         |
     --------               ---------            ---------
         |(F)                   | (F)                | (F)
         |                      |                    |
         |                      |                    | Emulate LAN
   ------------------------------------------------------------

   Fig: Logical Representation of Fully Meshed Layer 2 VPN

   (R) - Root Bridge

   (F) - Forwarding Port
   (B) - Block Port

4.9 Recovery and Restoration

   Redundancy of Layer 2 topologies are mostly implemented using
   Spanning Tree Protocols. Any major change in Layer 2 topology
   requires STP to re-converge. Re-convergence of STP is in the order
   of 10's of seconds. It is sufficient to have the same degree of re-
   convergence capabilities in Layer 2 NBVPN.

   Alternatively Layer 2 NBVPN MAY provide redundant paths to assure
   high availability.  The reaction to failures should result in an
   attempt to restore the service using alternative paths.  It is
   desirable to make the restoration times as small as possible.

   The restoration time SHOULD be less than the failure detection time
   of L3 service running over the same VLAN.


4.10 Security Requirements

   All layer 2 NBVPN devices MUST require to have ability to isolate
   traffic for each Layer 2 VFI. Ingress classification MUST be well
   defined such that there exists one and only one VFI for each VLAN of
   each customer domain. In other words, provider MUST provide traffic
   separation between different customers and between different VLANs
   of the same customer.  The traffic separation MUST prevent leaking
   of the traffic in or out of VLANs in a normally functioning Layer 2
   NBVPN.

   Optionally; PE devices may offer data encryption and authentication
   services. Protection against denial of service attacks. Protection
   against bandwidth and connection hijacking. Ability to provide some
   of these optional security requirements may depend on tunneling
   protocol used in the core.

Senevirathne et.al,    Informational û October 2001                 11
                     draft-tsenevir-l2-req-00.txt             May 2001



4.11 Dynamic Service Signaling

   A provider MAY offer an in-band method for selecting services from
   the list specified in the SLA.

4.12 Graceful reconfiguration

   In cases where the provider knows a priori about impending fault,
   the network SHOULD be reconfigured without a loss, duplication, or
   re-ordering of customer packets.  This situation typically arises
   with planned network upgrades, or scheduled maintenance activities.

4.13 Immunity from malformed customer traffic.

   The providerÆs infrastructure MUST NOT be compromised by malformed,
   or maliciously altered, customer traffic.  These includes, but is
   not limited to, duplicate or invalid MAC addresses, short packets,
   long packets, etc.


4.14 Class of Service Model

   The VLAN service SHOULD define a graded selection of classes of
   traffic.  These include, but is not limited to

   o range of priorities
   o best effort vs. guaranteed effort
   o range of minimum delay characteristics

4.15 Minimum MTU

   The service MUST support customer frames 1500 bytes long.  The
   service MAY offer support for longer frames.

   The service MUST NOT fragment packets.  Packets exceeding committed
   MTU size MUST be discarded.

4.16 Packet re-ordering or duplication

   The service MUST preserve the order of packet sent from one end
   point to another end point within given VLAN with given committed
   topology.

   The service MUST NOT duplicate packets.

4.17 L3, and higher, service access point.

   The VLAN SHOULD a allow for a Provider based Service Access Point
   for orderly injection of L3 or higher services to the customerÆs
   VLAN.


Senevirathne et.al,    Informational û October 2001                 12
                     draft-tsenevir-l2-req-00.txt             May 2001


   As a value added service, L2 NBVPN may provide access to other
   services such as, IP gateways, Storage networks, Content delivery
   etc..

4.18 Monitoring

   The infrastructure SHOULD monitor all characteristics of the service
   that are reflected in the customer SLA. This includes but is not
   limited to bandwidth usage, packet counts, packet drops, service
   outages, etc.

4.19 Support for MAC Services

   Layer 2 NBVPN are required to provide MAC service as specified in
   IEEE 802.1D specification [4] Section 6. Some of the MAC services
   defined in [4] are directly applicable to Layer 2 NBVPN. Some other
   MAC services require changes in order to be meaningful in Layer 2
   NBVPN applications. In this section each of the MAC service
   requirements specified in [4] are revisited. All Layer 2 NBVPN
   devices are required to support MAC services presented in this
   section. Compliance with this section facilitates proper operation
   of 802.1 LAN and seamless integration of Layer 2 NBVPN with bridged
   Local Area Networks.

   A MAC service in the context of Layer 2 NBVPN is defined as;
   Transfer of user data between source and a destination end stations
   via the service access points using the information specified in the
   Layer 2 NBVPN VFI.

4.19.1 Preservation of MAC services

   MAC services offered by LAN's interconnected by Layer 2 NBVPN
   devices must be similar to MAC services provided in a single LAN.
   Hence,

   1. A Layer 2 NBVPN must not be directly accessed by end stations
   except for explicit management purposes.

   2. All MAC addresses must be unique within a given customer domain
   and a VLAN, i.e. within VFI.

   3. The MAC addresses of end stations must not be restricted by the
   topology and configuration of the Layer 2 NBVPN.

4.19.2 Quality of service maintenance

   The quality of services provided by Layer 2 NBVPN must not be
   significantly inferior to that of LAN or IEEE 802.1 bridges.
   Following areas, at minimum, must be considered when evaluating the
   quality of service maintenance in Layer 2 NBVPN. Section 4.14 above
   present quality of service requirements that may be specific to
   Layer 2 NBVPN.


Senevirathne et.al,    Informational û October 2001                 13
                     draft-tsenevir-l2-req-00.txt             May 2001


   . Service availability
   . Frame loss
   . Frame misordering
   . Frame duplication
   . The transit delay experienced by frames
   . Frame lifetime
   . The undetected frame error rate
   . MTU size support
   . User priority
   . Throughput
   . Scope of Layer 2 forwarding

   Service availability

   Service availability is defined as a fraction of some total time
   during which the Layer 2 NBVPN services are available.

   Automatic reconfiguration and other methods may increase Service
   availability. During service failures or automatic reconfiguration,
   Layer 2 NBVPN devices may deny access and discard frames to preserve
   forwarding aspects and other requirements of Layer 2 NBVPN.

   Frame loss

   Layer 2 NBVPN devices do not guarantee frame delivery. Frames may be
   discarded due to several reasons. PE device must provide statistics
   on frame loss that occur within the PE. Layer NBVPN PE devices are
   often connected via some tunneling method. Unlike 802.1 bridges the
   Layer 2 NBVPN PE devices may be separated by several hops. Hence
   Frame loss can occur some where in the transit. Collection of such
   loss of frames is OPTIONAL and some implementation may not provide
   them.

   Frame misordering

   Layer 2 NBVPN must not permit misordering of frames of a given
   customer domain, for  a given VLAN with a given user priority.

   Frame duplication

   The Layer 2 NBVPN must not permit frame duplication. If there exists
   multiple paths between PE devices forwarding pollicies of the local
   PE must ensure that only a single copy of the frame is transmitted
   to the remote PE device. Definition of frame forwarding polices are
   beyond the scope of this document. Section 7.7 of [4] provides
   detail explanation of frame forwarding in IEEE bridges. These
   forwarding policies may be extended to Layer 2 NBVPN.

   Transit delay

   It is difficult to measure the total transit time taken from end
   station to end station. However, transit time of Layer NBVPN PE
   devices may be measured in terms of total time taken for reception,

Senevirathne et.al,    Informational û October 2001                 14
                     draft-tsenevir-l2-req-00.txt             May 2001


   classification and transmission of the frame. Transit delay of Layer
   2 NBVPN MUST be in compliance with 802.1D specification [4]. The
   transit delay introduced by Layer 2 NBVPN must not be arbitrarily
   large.

   Frame lifetime

   In order to ensure proper operation of upper layer protocols, Layer
   2 NBVPN devices must specify an upper bound to the transit delay
   specified above.

   Traditional bridges consider transmit time as the time taken to
   transmit the packet in to the wire. However, due to multi-hop
   separation between PE devices, the transmission time of a frame at
   PE device must take in to account the delay introduced by the
   transit network (tunnels).

   As per 801.1D[4] specification lower bound for maximum frame life
   time is 1.0 seconds and upper bound for maximum frame life time is
   4.0 seconds.

   Layer 2 NBVPN MAY specify different set of frame life time
   parameters.

   MTU Size.

   Layer 2 NBVPN PE devices and the network must be capable of
   supporting the largest MTU size that customer is required to
   transmit. In another words, customer is capable of transmitting the
   smallest of all MTU sizes supported by the Layer 2 NBVPN devices and
   the network.

   Priority

   Layer 2 NBVPN PE devices maps priority of incoming user traffic in
   to different internal traffic classes. In the egress to the back end
   (tunnels) PE device may map these traffic classes in to different
   planes of the NBVPN. Each of these planes is defined with different
   traffic engineering parameters. Mapping of user priorities to egress
   traffic planes is entirely a local policy and beyond the scope of
   this publication.

   Throughput

   Based on the service level agreement and bandwidth provisioning, the
   total throughput provided by Layer 2 NBVPN network may be
   significantly less than that of the local LAN. Hence PE device may
   discard frames that exceed the provisioned bandwidth.

   Scope of Layer 2 forwarding

   In order to optimize forwarding of MAC addresses, Layer 2 NBVPN PE
   devices may provide methods to specify the scope of a MAC address.

Senevirathne et.al,    Informational û October 2001                 15
                     draft-tsenevir-l2-req-00.txt             May 2001


   The scope of the MAC address is defined as potential end-point where
   such MAC address can appear or where potential stations that wish to
   receive frames are located.


 5. References


   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997

   3  Senevirathne, T., and et.al., Framework For Virtual Metropolitan
      Internetworks (VMI), Work in Progress, February 2001

   4  ANSI/IEEE Std 802.1D, Media Access Control (MAC) Bridges,
      Internatyional Electrotechnical Commission, 1998.




6. Acknowledgments

   Ongoing discussion in PPVPN has influenced work presented in this
   document.

7. Author's Addresses

   Tissa Senevirathne
   Force10 Networks
   1475 McCarthy Blvd
   Milpitas, CA
   Phone: 408-965-5103
   Email: tissa@force10networks.com

   Waldemar Augustyn
   Nortel Networks
   600 Technology Park
   Billerica, MA 01821
   Phone: 978 288 4993
   Email: waldemar@nortelnetworks.com


Appendix A: Acronyms and Abbreviations

   NBVPN û Network Based Virtual Private Networks

   PE û Provider Edge Device

   CE û Customer Edge Device


Senevirathne et.al,    Informational û October 2001                 16
                     draft-tsenevir-l2-req-00.txt             May 2001


   VFI û Virtual Forwarding Instance

   GVRP û Generic VLAN registration Protocol

   SLA û Service Level Agreement

   STP û Spanning Tree Protocol

   VLAN û Virtual Local Area Network. VLAN in this document refers to
        VLAN identifiers assigned by customers

Senevirathne et.al,    Informational û October 2001                 17
                     draft-tsenevir-l2-req-00.txt             May 2001



Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into


Senevirathne et.al,    Informational û October 2001                 18