Provider Provisioned VPN WG Hamid Ould-Brahim Internet Draft Vasile Radoaca draft-ouldbrahim-l2vpn-lpe-01.txt Michael Chen Expiration Date: April 2002 Nortel Networks Pascal Menezes Terabeam Networks November 2001 VPLS/LPE L2VPNs: Virtual Private LAN Services using Logical PE Architecture Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC-2026], except that the right to produce derivative works is not granted. 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. Ould-Brahim, et. al 1 draft-ouldbrahim-l2vpn-lpe-01.txt November 2001 Abstract Consider a common network scenario in the metro area where the service provider offers Virtual Private LAN services (VPLS) known also as Transparent LAN services (TLS) to a large number of customers attached to low-cost Ethernet provider devices. These devices specialized mostly for Ethernet based functions (e.g., MAC learning, etc) may not have adequate resources and functions compared to provider devices offering large scale layer-2 or layer-3 VPN services. Consider also the case where those devices are themselves attached to either switched Ethernet networks or through uplinks to other provider edge devices, which are attached to a core IP/MPLS network infrastructure. The problem is how to provide a network-based VPLS solution that scales to a large number of VPLSs, each with a large number of customer ports while at the same time the solution should be cost-effective at service provider network- edges. This draft introduces the "Logical PE" architecture to effectively address this problem. 1. 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]. 2. Introduction Consider a common network scenario in the metro area where the service provider offers Virtual Private LAN services (VPLS) known also as Transparent LAN services (TLS) to a large number of customers attached to low-cost Ethernet provider devices. These devices specialized mostly for Ethernet based functions (e.g., MAC learning, etc) may not have adequate resources and functions compared to provider devices offering large scale layer-2 or layer-3 VPN services. Consider also the case where those devices are themselves attached to either switched Ethernet networks or through uplinks to other provider edge devices, which are attached to a core IP/MPLS network infrastructure. The problem is how to provide a network-based VPLS solution that scales to a large number of VPLSs each with a large number of customer ports while at the same time the solution should be cost-effective at service provider network- edges. This draft introduces the "Logical PE" architecture to effectively address this problem. Architecting a scalable network based VPLS solution faces challenges related to the nature of the Ethernet technology itself and the network-based VPN mechanisms used. Most of existing VPLS solutions attempt to address the VPLS architecture Ould-Brahim, et al. May 2002 [Page 2] draft-ouldbrahim-l2vpn-lpe-01.txt November 2001 within a problem space similar to the layer-3 and point-to-point layer-2 VPNs. Although the layer-3/2 VPN problem space is indeed part of the VPLS problem space, it doesn't fully meet all the possible scaling characteristics and common VPLS network deployment scenarios. This section illustrates the nature of VPLS service/architecture, network based VPN technologies with VPLS, VPLS architecture models and functions. Initially introduced in [RFC-2764], and adopted in [VPLS-REQ], a Virtual Private LAN service (VPLS) is a VPN service, which emulates a LAN segment using IP based facilities. A VPLS can be used to provide what is known as a Transparent LAN Service (TLS) used to interconnect multiple customer edge devices (CEs) (e.g., bridges, router, routing switch) across a shared Ethernet and IP/MPLS service provider network infrastructure. The primary benefits of a VPLS are complete protocol transparency, which are important both for multiprotocol transpor. From an end-user's perspective, a VPLS ties geographically separate sites together as if they share a common LAN segment. A VPLS network is built by attaching customer LAN equipment into the provider Ethernet ports, and interconnecting them to other provider customer facing ports across the service provider network. The end user does not need to know exactly how the packets are delivered only that they are delivered unmodified to the proper sites. Multiple VPLS services can be provided on a single service provider network. A provider edge device (PE) can support multiple VPLS services. Layer-2 VPN solutions extend the concept of traditional layer-2 circuits to accommodate VPN constructs like membership, auto- discovery, tunneling, and topology discovery. The mechanisms developed within these solutions (e.g., [BGP-AD]) can greatly benefit scaling VPLS architectures. VPN Scalability is addressed mostly from aggregation and auto-discovery mechanisms. Aggregation offers the ability to multiplex multiple VPNs over shared network pipes. Auto-discovery provides the ability to dynamically discover the VPN members and hence simplifies service provisioning within the network (e.g., single ended provisioning). An Ethernet VPLS based solution is required to meet the scaling requirement where the PEs facing customer devices and attached to a core network need to perform MAC learning for all the VPLS services. In addition to providing VPLS services, the PEs may also be used to provide other VPN services (like layer-3 VPNs or point to point L2VPNs). One way of achieving both scaling and cost objectives is to distribute some of the VPLS and VPN functions like MAC learning, Ould-Brahim, et al. May 2002 [Page 3] draft-ouldbrahim-l2vpn-lpe-01.txt November 2001 auto-discovery and aggregation among low-cost Ethernet based provider edge devices (facing customer devices) and high capacity core provider edge devices (attached to service provider core network). A service provider may want to use a "logical PE" function based on association between PE-facing customer ports, called "PE-Edges", and core provider edge devices, labeled as "PE-Core". Another objective of the logical PE approach besides scaling is to be able to fit nicely with all existing VPN technologies supported on the service provider network [VPN-VR], [VPN-RFC2545bis], [L2VPN-KOMP], [L2VPN-ROSEN], [OVPN]. 3. Logical PE Architecture This section describes the LPE architecture with its related building blocks and functions. 3.1 VPLS/L2VPN Reference Model The VPLS network reference model follows the model described in [PPVPN-REQ] and [VPLS-REQ]. A service provider may offer VPLS services where a customer edge device (CE), which can be a layer 2 Ethernet switch, a server, a router, a routing switch or an Ethernet bridge is attached to a service provider edge device. PEs are connected to internal provider devices (P) which are considered VPLS unaware. This reference model is similar to existing layer-3 and point-to-point reference models. 3.2 VPLS LPE Reference Model The logical PE architecture addresses network scenarios when PEs facing customer devices is connected to some switched Ethernet transport networks or uplinks attached to other PEs which themselves are attached to a core network infrastructure. In the example illustrated in figure 1, from a conceptual view PEs facing customer equipment (and not attached to the core network) combined with PE attached to the core network represent from a conceptual view a "logical PE" construct where many VPLSs along with other layer-2 and layer-3 VPN services are attached to it. +---+ +----+ +---+ +---+ |CE4| |CE-2| | P |....| P |\ +---+ +----+ /+---+ +---+ \ | \ PE2 / \ | +---+ \ +-----+ +-------+ |CE5| \| | | PE4 | +---+ PE1 | | / +-------+ / Ould-Brahim, et al. May 2002 [Page 4] draft-ouldbrahim-l2vpn-lpe-01.txt November 2001 +---+ /+-----+ / | +-/--+ +---+ | | / | | | | |CE1|-| |-{ uplinks or} CORE |{uplinks or}-| PE5| +---+ | |{L2 Networks} Networks |{L2 networks}| | +---+ /\ \ | +----+ / \ +-----+ +---+ | \\ / \| | |PE8| | +---+ +---+ | PE3 | +---+ | |CE6| +---+ | | /+-----+ / | +---+ |CE8|---|PE7| / \ / +---+ +---+ +---+ / +---+ +---+ |PE6| +---+ | P |....| P | +---+\ |CE3| +---+ +---+ +-/-+ \+---+ +---+ |CE9| |CE7| +---+ +---+ Figure 1: Example of VPLS service To highlight the case described in figure 1, we label each PE within the network as a PE-Edge or PE-Core depending if the PE is attached to the core network or not (and depending if there is a functional relationship between the PE-Edge and the PE- Core). PEs who do not participate in these schemes are not labeled. This model extends the previous L2VPN model described in the section 2.5.1. Using figure 1, PE1, PE7, PE5, PE6 can be labeled PE-Edges while PE2, PE3, PE4, and PE8 are labeled PE- Cores. Within the LPE reference model, a CE can be attached to one or more than one PE-Edges. However, connecting to more than one PE-Edge may require the PE-Edges to participate in customer spanning tree protocol. PE-Edges can be connected through the Switched Ethernet transport network or direct links to one (or more) PE-Core(s). There can be multiple switched Ethernet transport domains within a Logical PE. A Switched Ethernet transport domain is equivalent to a broadcast domain. All the devices within the switched Ethernet transport domain will receive an Ethernet broadcast message sent onto the switched Ethernet transport domain. Within a carrier's metro Ethernet network it can contain multiple Switched Ethernet Transport domains. For example, a particular 802.1Q VLAN in a carrier's metro Ethernet network is a switched Ethernet transport domain. Most likely PE-Cores are highly scalable routers/Ethernet switches (with IP/MPLS based capabilities). PE-Cores like any other PEs can provide VPLS, layer-2, and layer-3 VPN services - PE-Cores are connected to each other over core network (e.g. MPLS) through P devices as usual VPN architectures [PPVPN-REQ]. Ould-Brahim, et al. May 2002 [Page 5] draft-ouldbrahim-l2vpn-lpe-01.txt November 2001 Logical PE concept can be used in situations requiring high scalability in terms of number of VPLSs and port density while aiming towards reusing low-cost PE devices. LPE can also be used in situations where the provider PEs don't have equal weight with respect to resource availability and full VPN functionality supported. Logical PE also allows a provider to gracefully introduce MPLS functionality into their existing 802.1Q or stacked Q-tag Ethernet network. One migration path is that the existing customer facing devices will evolve into PE-Edges devices. These PE-Edge devices need not be MPLS aware and can remain simple from the control plane side. PE-Edge to PE-Edge communication can continue to be carried over the existing switched Ethernet transport network. PE-Core can then be added into the switched Ethernet transport network to provide connectivity to the IP/MPLS core. The grouping of PE-Core, PE-Edge, and switched Ethernet transport devices can give the appearance of a PE from other PEs across the IP/MPLS core. 3.3 Logical PE A logical PE (LPE) is a PE constructed by distributing VPLS functions across PE-Edges and PE-Cores interconnected by switched Ethernet transport network(s) or one or more than one uplink. LOGICAL PE +-------------------------------------------+ | | | +---------+ | | +---------+ | | | +----+ | | | | | | |CE-1|-| | PE-Edge |--{ Distributed }--| PE-Core |-|--{Core}... +----+ | | (n) | {VPLS Functions} | (m) | | | +---------+ | | | | | +----|----+ | | | | | +------|-----------------------------|------+ | | +----+ +----+ |CE-2| |CE-3| +----+ +----+_ Figure 2: Logical PE with PE-Edges and PE-Cores Ould-Brahim, et al. May 2002 [Page 6] draft-ouldbrahim-l2vpn-lpe-01.txt November 2001 Note that the PE-Core platform may also have PE-Edge functions as shown in Figure 2 where CE-3 to connects directly to the PE- Core platform. Within the Logical PE concept, the PE-Edge is connected to the CE through Ethernet ports (which can be logical ports) called LPE endpoints. An LPE endpoint can be defined on the PE-Core or the PE-Edge. An LPE endpoint where the CE is attached to is the demarcation point between the customer and the VPLS service. The PE Core device is connected to the Core network. PE-Edges interoperate with other PE-Edges between different Logical PEs and within the same Logical PE. PE-Edges interconnected through a switched Ethernet transport domain can inter-operate without involvement of PE-Cores. A network consists of only PE-Edges can also deliver low-scale VPLS services. The PE-Cores provide intermediary functions to enable PE-Edges to interoperate with PEs outside their local Switched Ethernet Transport domain. This may be with another PE or with PE-Edges in other Logical PEs, with PE-Edges in the same LPE but belonging to different switched Ethernet transport domain. PE-Cores can also offer VPLS services for directly connected CEs. Finally, when LPEs are used they can communicate with conventional PE devices that are not associated with any PE- Edges. Inter-site connectivity between PE-Edges sharing the same switched Ethernet transport domain need not involve PE-Core. Inter-site connectivity between PE-Edges in different switched Ethernet transport domains within the logical PE need not involve any PEs outside of the logical PE. PE-Cores are connected in a fully mesh topology of transport tunnels across the core network. PE-Edges see only PE-Cores and other PE-Edges in the same switched Ethernet transport domain, therefore there is no direct full meshing between PE-Edges across the core network, and any inter-site connectivity between PE-Edges across the core network will traverse the PE-Cores. 3.4 PE-Core and Source MAC Learning Implementation The logical PE can be built with a PE-Core with or without source MAC learning capabilities. A PE-Core needs to perform source MAC learning in situations where VPLS customer sites are attached to the PE-Core. However, when no customer sites are attached to a PE-Core, the LPE will perform MAC learning function only at the PE-Edge level. 3.5 Network Connectivity within the Logical PE Ould-Brahim, et al. May 2002 [Page 7] draft-ouldbrahim-l2vpn-lpe-01.txt November 2001 Various network configurations can be implemented within the Logical PE. This section describes some of these configurations (the LPE scheme is flexible enough to support many other configurations). 3.5.1 PE-Edges connected directly to the PE-Core In this configuration the PE-Edges are connected directly to the PE-Cores using single line Ethernet trunks. For enhanced reliability the PE-Edges can be connected to the PE-Core via two Ethernet trunks where the PE-Core which can be used for load sharing and for recovery from link and device failures. 3.5.2 Multiple Broadcast Domains in Logical PE In this case, a single PE-Core can be connected to PE-Edges via multiple Switched Ethernet Transport domains. An implementation example of Switched Ethernet Transport domain is Resilient Packet Rings (RPR). 3.6 Functional Elements of the Logical PE Following sections describe a list of PE functions that can be distributed in forming a LPE: 3.6.1 MAC learning To provide VPLS service, the provider network is required to learn customer MAC addresses and their associated customer site. MAC learning refers to the learning and aging the L2 forwarding tables based on MAC addresses received from customer packets. 3.6.2 Participation in customer Spanning Tree Protocol(OPTIONAL) Provider VPLS network can participate in customer STP to avoid loops in the customer network for multi-homed customers or customers with backdoor connectivity. This is an OPTIONAL function. 3.6.3 Transport tunnel within the LPE IP/MPLS based tunnels can be used in the core network. Since the PE-Edge and PE-Core devices are connected via switched Ethernet transport domains, Ethernet header can be used as a form of transport tunnel between PE-Edge and PE-Core devices. 3.6.4 Service label de-multiplexing within LPE De-multiplexing header used to identify the service within a transport tunnel. Mechanisms analogous to the "VC label" stated in [MARTINI-ENCAPS] can be used. Ould-Brahim, et al. May 2002 [Page 8] draft-ouldbrahim-l2vpn-lpe-01.txt November 2001 3.6.5 PE-Edge/PE-Core auto-discovery Mechanism (LPE-AD) A lightweight protocol needs to be established between the PE- Edge and PE-Core for VPLS information exchange (e.g. membership, tunneling, etc). An example of functions provided by an LPE-AD: o Notification of endpoint Addition, Deletion, Modification of VPLSs. o Service Label/Tunnel information exchange within the LPE. o Addition/Deletion/Modification of PE-Edges. 3.6.6 Customer traffic prioritizing, policing, and shaping Function includes ingress classification, metering, policing, and egress shaping of customer traffic at the provider boundary. 3.6.7 Customer VLAN processing On customer facing interfaces where the provider recognizes and acts on customer 802.1Q tagged frames. 3.6.8 VPLS membership determination A VPLS service visible at the LPE level can be created either at the PE-Edge or the PE-Core or both. A VPLS solution is a port- based VPN type architecture. Therefore, the VPN membership is accomplished by configuring customer facing ports and associating the port/endpoints to the VPLS VPN membership scheme. 3.6.9 Topology Full mesh transport tunnels with other PE device across the core. 3.6.10 VPLS auto-discovery between PEs On the core network, point-to-point circuits can be created using either [L2VPN-KOMP], or [Martini-TRANSP] with extensions to accomodate signaling/auto-discovery VPLS service information. For example, [MARTINI-TRANSP] type signaling can be used to create VC LSPs between virtual endpoints. In this scheme, the auto-discovery mechanism is decoupled from signaling. LDP-DU can be used where the VFEC will carry VPLS membership scheme (e.g., VPN-ID) and relevant information about VPLS endpoints (new VFEC parameter IDs can be defined for carrying such information). BGP based auto-discovery mechanism can also be used in the core to inform each PE about VPLS membership information (e.g., described in [BGP-AD], and [L2VPN-KOMP]). Ould-Brahim, et al. May 2002 [Page 9] draft-ouldbrahim-l2vpn-lpe-01.txt November 2001 3.6.11 VPN Membership Mapping from within LPE domain to core domain (OPTIONAL) Typically a VPLS is associated with a VPN-ID, which uniquely identifies the VPLS across the service provider network. An example of VPN-ID format can be found in [RFC-2685]. This draft doesn't preclude the use of other schemes for VPLS membership as those used in layer-3 and optical VPNs (e.g., route-target schemes). It may happen that a VPLS has dual membership schemes within the LPE and inter-LPE on the core network. In this case, a VPN membership mapping function is needed at the LPE level. 3.6.12 Forwarding Plane Mechanism Translation Mechanism in the forwarding plane within the LPE can be different than the forwarding plane mechanism in the core network. For example, with the existence of switched Ethernet transport networks within the LPE, a form of forwarding plane mechanism within the LPE can be Ethernet. 4. LPE Functional Distribution Distribution of Logical PE functions is primarily determined upon the VPLS architecture model used. This section discusses one such possible distribution of these LPE functions. In most cases, the PE-Edge provides such functions as managing the SLA including bandwidth policing, traffic classification and QoS, as well as customer Ethernet frame encapsulation, and MAC and VLAN learning. Also, in most cases, the PE-Core maintains membership information and performs VPN membership determination and advertisement to all the PE-Cores members of the same VPLS. By using a signaling and/or an auto-discovery mechanism, the PE-Core distributes the VPN and/or endpoint related information to all PEs/LPEs across the core. Such distribution can be constrained to only the PEs/LPEs that have VPLS membership in common. 4.1 PE-Edge Functions Typically a PE-Edge being a bridge, a routing switch, or a router will perform regular Ethernet based functions. Among these functions: o MAC learning Ould-Brahim, et al. May 2002 [Page 10] draft-ouldbrahim-l2vpn-lpe-01.txt November 2001 o Participation in customer Spanning Tree Protocol(OPTIONAL) o Transport tunneling within the LPE o Service label de-multiplexing within LPE o PE-Edge/PE-Core auto-discovery Mechanism (LPE-AD) o Customer traffic prioritizing, policing, and shaping o Customer VLAN processing o VPLS membership determination o VPLS configuration (depending on the configuration model) 4.2 PE-Core Functions A PE-Core being attached to an IP/MPLS network and providing other VPN service than just VPLS should provide the following functions: o Transport tunnel within the LPE o Service label de-multiplexing within LPE o PE-Edge/PE-Core auto-discovery Mechanism (LPE-AD) o VPLS Configuration (depending on the configuration model) o VPLS membership determination o Tunneling between PEs (MPLS/IP based) o Service label de-multiplexing between PEs o VPLS auto-discovery between PEs o VPLS signaling between PEs (OPTIONAL) o VPN Membership mapping from within LPE domain to core domain (OPTIONAL) o Forwarding plane mechanism translation 5. LPE Configuration Models A VPLS service can be configured on the PE-Edge or PE-Core or using a service provider network management system to configure both PE-Edge and PE-Core. The LPE-AD auto-discovery conveys configuration data between PE-Edge and PE-Core. The information needed on the PE-Edge/PE-Core relates to the VPLS membership scheme, the port/endpoint configuration. It may happen that the a different membership scheme is used intra-LPE than the membership used inter-LPE, in this case a mapping function is used to maintain unique VPLS membership across the service provider network. 6. Quality of Service Intra-LPE or inter PE-Core connectivity can be traffic engineered. RSVP-TE/CR-LDP can be used at the core and/or switched Ethernet transport. Customer traffic can be policed and shaped at the access port on the PE-Edge. The customer traffic is classified on the PE-Edge, and is mapped onto the endpoints VC-Labels. Most generally priority configured per Ould-Brahim, et al. May 2002 [Page 11] draft-ouldbrahim-l2vpn-lpe-01.txt November 2001 access port (at the PE-Edge level) maps the customer 802.1p traffic to the network priority tunneling. This mapping is based on customer VPLS SLA. 7. LPE Resiliency VPLS/L2VPN architecture resiliency is key to ensure service availability in presence of failures. Indeed, VPLS, like any layer-2 scheme is subject to failures like link, trunk, node failures. Within the logical PE, failures can appear at the PE-Edge, PE- Core, the PE-Edge/PE-Core interconnecting link or switched Ethernet network. Dual PE-Cores can be used to protect the LPE failure and VPLS failures. Although using two dual PE-Cores, the LPE appears to the network as a single LPE. 8. Security Considerations VPLS security needs to be considered within the LPE and inter- LPEs. Within the LPE Customer traffic needs to be separated within the LPE. Ethernet Qtag, MPLS/IP based tunneling can be used. The level of data path security is same as ATM or FR networks. This document doesn't preclude the use of encryption mechanisms within the LPE (although not recommended, particularly if Ethernet switched transport is used). Inter-LPE security is provided within the layer-2 VPN architecture. A range of security parameters can be used, from using link layer type security to full encryption and authentication. An inter-domain solution usually requires some security mechanism across provider boundaries. For full inter- provider security (only when needed), IPSec tunneling mechanism is recommended. 9. References [BGP-AD] Ould-Brahim, H,. et al., "Using BGP as an Auto- discovery Mechanism for network-based VPNs", draft-ietf- ppvpn-bgpvpn-auto-00.txt, work in progress. [ETHER-REQ] Ould-Brahim, H., et al, "Service Requirements for Ethernet based L2VPNs", draft-ouldbrahim-ethernet-l2vpn requirements-00.txt, work in progress, July 2001. [KOMP-DTLS] Kompella, K., et. al., "Decoupled Transparent LAN Services", draft-kompella-ppvpn-dtls-00.txt, October 2001, work in progress. Ould-Brahim, et al. May 2002 [Page 12] draft-ouldbrahim-l2vpn-lpe-01.txt November 2001 [L2VPN-ROSEN] Rosen, E., et al., "An Architecture for L2VPNs", draft-ietf-ppvpn-l2vpn-00.txt, July 2001, work in progress. [L2VPN-KOMP] Kompella, K., et al., "MPSL based Layer-2 VPNs", draft-kompella-ppvpn-l2vpn-00.txt, June 2001, work in progress.. [MARTINI-ENCAPS] Martini, L., et al. "Encapsulation Methods for Transport of Layer 2 Frames Over MPLS", draft-martini- l2circuit-encap-mpls-03.txt, work in progress. [MARTINI-TRANSP] Martini, L., et al., "Transport of Layer-2 Frames over MPLS", draft-martini-l2circuit-trans-mpls- 07.txt, work in progress, July 2001. [PPVPN-REQ] Carugi, M., et al., "Service requirements for Provider Provisioned Virtual Private Networks", work in progress. [PPVPN-FRAME] Callon, R., et al., "A Framework for Provider Provisioned Virtual Private Networks", July 2001, work in progress. [PWE3-REQ] Xiao, X., et al., "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", draft-ietf-pwe3- requirements-01.txt, July 2001. [OVPN] Ould-Brahim, H., Rekhter, Y. et al., "BGP/GMPLS Optical VPNs", draft-ouldbrahim-bgpgmpls-ovpn-02.txt, work in progress. [RFC-2685] Fox B., et al, "Virtual Private Networks Identifier", RFC 2685, September 1999. [RFC-2764] Gleeson, B., et al., "A Framework for IP Based Virtual Private Networks", February 2000. [ROSEN-SIG] Rosen, E., "Single Sided Signaling for L2VPN", draft-rosen-ppvpn-l2-signaling-00.txt, October 2001, work in progress. [VPLS-LASS] Lasserre, M., et al., "Transparent VLAN Services over MPLS", draft-lasserre-tls-mpls-00.txt, August 2001. [VPLS-REQ] Waldemar, A., et al., "Requirements for Virtual Private LAN Services (VPLS)", draft-augustyn-vpls requirements-00.txt, October 2001. [VPLS-VPSN] Virtual Private Switched Network Services over MPLS Network", draft-vkompella-ppvpn-vpsn-mpls-00.txt, July 2001. Ould-Brahim, et al. May 2002 [Page 13] draft-ouldbrahim-l2vpn-lpe-01.txt November 2001 [VPN-RFC2547bis] Rosen, E., et al., "BGP/MPLS VPNs", draft- draft-ietf-ppvpn-rfc2547bis-00.txt, July 2001, work in progress. [VPN-VR] Ould-Brahim H., et al., "Network-based IP VPN using Virtual Routers", draft-ietf-ppvpn-vr-00.txt, July 2001, work in progress. [802-P] IEEE Std 802.1Q-1998 10. Acknowledgments. We would like to acknowledge the following individuals for their constructive comments: Marc Holness, Paul Valentine, Phil Edholm, Sam Sigarto, Bilel Jamoussi, Frank Neil, Liam Casey, Wai-Chai Chau, Hesham El-Bakoury, Dinesh Mohan, Paul Knight and many other people who contributed to the concept of logical PE. 11. Intellectual Property Considerations Nortel Networks may seek patent or other intellectual property protection for some of all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Nortel Networks, Nortel Networks intends to disclose those patents and license them on reasonable and non-discriminatory terms. 12. Author's Addresses Hamid Ould-Brahim Nortel Networks P O Box 3511 Station C Ottawa ON K1Y 4H7 Canada Phone: +1 (613) 765 3418 Email: hbrahim@nortelnetworks.com Vasile Radoaca Nortel Networks 600 Technology Park Billerica, MA 01821 vasile@nortelnetworks.com 978-288-6097 Michael Chen Nortel Networks 4010 E Chapel Hill-Nelson Hwy Research Triangle Park, NC 27709 USA Phone: +1 (919) 997 3840 Email: mchen@nortelnetworks.com Ould-Brahim, et al. May 2002 [Page 14] draft-ouldbrahim-l2vpn-lpe-01.txt November 2001 Pascal Menezes Terabeam Networks 2300 Seventh Ave Seattle, WA, USA 98121 Access Line and Fax : 206 686-2001 email: pascal.menezes@terabeam.com Ould-Brahim, et al. May 2002 [Page 15] draft-ouldbrahim-l2vpn-lpe-01.txt November 2001 Full Copyright Statement Copyright (C) The Internet Society (2000). 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 implementation 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 languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Ould-Brahim, et al. May 2002 [Page 16]