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