Provider Provisioned VPN WG Hamid Ould-Brahim Internet Draft Vasile Radoaca draft-ouldbrahim-l2vpn-lpe-00.txt Michael Chen Expiration Date: April 2002 Nortel 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. Abstract Consider a common network scenario in the metro area where the service provider offers Virtual Private LAN services (VPLS) Ould-Brahim, et. al 1 draft-ouldbrahim-l2vpn-lpe-00.txt November 2001 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. TABLE OF CONTENT Abstract 1. Conventions used in this document......................... 3 2. Introduction.............................................. 3 2.1 What is a VPLS Service?.................................. 4 2.2 VPLS Architecture and Ethernet Scaling Issues............ 4 2.3 Network-based VPNs and VPLS Service...................... 6 2.3.1 L2VPN Architectures.................................... 6 2.3.2 L2VPN Architectures and VPLS........................... 6 2.4 VPLS and Logical PE Approach............................. 7 2.5 VPLS Architecture Functions and VPLS Models.............. 7 2.5.1 VPLS/L2VPN Reference Model............................. 7 2.5.2 VPLS Main Functions.................................... 7 2.5.3 VPLS Model: Full Mesh Point-to-Point Circuits.......... 9 2.5.4 Virtual Switch Model................................... 9 2.5.5 Virtual Switch with Full mesh Point-to-Point Model..... 9 3. Logical PE Architecture................................... 9 3.1 VPLS LPE Reference Model................................. 9 3.2 Logical PE...............................................12 3.3 Network Connectivity within the Logical PE...............13 3.3.1 PE-Edges connected directly to the PE-Core.............13 3.3.2 Multiple Broadcast Domains in Logical PE...............13 3.4 Logical PE Function Distribution.........................14 3.4.1 PE-Edge Functions......................................14 3.4.2 PE-Core Functions......................................14 3.5 Logical PE Auto-Discovery Protocol (LPE-AD)..............15 3.6 VPLS Membership Determination............................15 3.7 Logical PE Forwarding and Auto-discovery.................15 3.7.1 VPN Auto-Discovery on the Core Network.................16 3.7.2 LPE Forwarding Algorithm for [MARTINI-TRANSP] on the Core..............................................16 3.7.3 LPE Forwarding Algorithm using [L2VPN-KOMP] on the Core..............................................17 3.7.4 Virtual Switch Proxy (VSP).............................18 Ould-Brahim, et al. May 2002 [Page 2] draft-ouldbrahim-l2vpn-lpe-00.txt November 2001 3.8 LPE Configuration Models.................................18 3.9 Quality of Service.......................................19 3.10 LPE Resiliency..........................................19 3.11 Security Considerations.................................19 4. References................................................20 5. Acknowledgments...........................................21 6. Intellectual Property Considerations......................21 7. Author's Addresses........................................22 Full Copyright Statement.....................................23 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 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. Ould-Brahim, et al. May 2002 [Page 3] draft-ouldbrahim-l2vpn-lpe-00.txt November 2001 2.1 What is a VPLS Service? Initially introduced in [RFC-2764], 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 transport and for regulatory reasons in particular service provider contexts. 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. 2.2 VPLS Architecture and Ethernet Scaling Issues This sections describes the main issues related to Ethernet technology in the VPN space: o Customer Separation on a shared infrastructure Ethernet was originally designed as an Enterprise Local Area Network where support for customer separation is not a requirement. As Ethernet deployment grew Enterprise customers sought ways of separating different departments traffic on single Ethernet based infrastructure. An enhancement to the original standard provided an answer with the addition of 802.1Q VLAN(s) that allow for separate broadcast domains on the one physical network. In its standard form 802.1Q VLAN(s) identifiers can provide up to 4,096 unique VLANs and many vendors have allowed for more than one 802.1Q identifier (stacked VLANs) in a single packet thus increasing the number of VLANs supported. For service providers who may have many thousands of customers this approach will not meet scaling objectives when used in a network environment with a large number of VPLSs along with a large number of other VPN services. o MAC and VLAN Explosion Ould-Brahim, et al. May 2002 [Page 4] draft-ouldbrahim-l2vpn-lpe-00.txt November 2001 The Ethernet MAC address is the unique global identifier for an Ethernet device. The MAC address is used to identify a specific device and is stored in Ethernet switches to identify the location of a device. In a large network with many devices the number of MAC addresses that need to be stored in an Ethernet switch can be in the tens of thousands. The need to store all device addresses on network nodes is a significant scaling and reliability issue and is known as the MAC explosion issue. A MAC "explosion" is a significant scaling issue in a Service Provider's network. As traffic migrates to the Core of the network, a large number of MAC addresses need to be learned. This approach is essentially unmanageable in situations where a failure of network devices impacts all devices whose addresses are stored on that device. A similar problem occurs with 802.1Q VLAN identifiers. Each customer may have many VLAN identifiers, which can overlap with other customers. Even with VLAN stacking the number of VLANs lead to significant complexity in network design and operational issues that limit the scale of the network. A VPLS solution must aim towards isolating the MAC and VLAN relevance to only the provider edge devices. All customer MAC addresses and VLAN identifiers are stored in edge devices and have only local significance. The intermediate network elements are not required to be aware of MAC customer addresses or VLAN. o Spanning Tree Protocol (STP) Issues The STP was designed to eliminate loops in Ethernet networks to ensure that there was always a path to every device on the network. It creates two major limitations when building a scalable VPLS solution on conventional PEs. Firstly, the STP builds a "tree" structure in the network that block the redundant links that create loops. This passive redundancy wastes available bandwidth. Second, the STP is a convergence type algorithm and in most cases requires an amount of time to re-compute and converge after a network failure. During this time the STP domain is not operational and no traffic is forwarded. To overcome this problem, a VPLS solution should aim towards building a fully redundant active network that utilizes all available bandwidth and resources and where recovery from failure occurs in fractions of a second. o Traffic Engineering When Ethernet was originally designed and to maintain simplicity of the technology, traffic engineering was not a significant requirement in enterprise Ethernet networks. With the introduction of VLANs it was possible to define multiple Ould-Brahim, et al. May 2002 [Page 5] draft-ouldbrahim-l2vpn-lpe-00.txt November 2001 STP domains in a single network. However, this approach does not alleviate the fundamental limitations of STP. With Ethernet and the STP network, traffic tends to migrate toward the core of the network resulting in hot spots in some parts of the network and under utilization in others. This is inefficient and limits network scalability. Using traffic engineering capabilities of MPLS for example in an IP based network, and bundling bandwidth reservation to the logical tunnels should be a design goal for a scalable network-based VPLS solution. 2.3 Network-based VPNs and VPLS Service 2.3.1 L2VPN Architectures Layer-2 VPN extends the concept of traditional layer-2 circuits to accommodate VPN constructs like membership, auto-discovery, tunneling, and topology discovery. Two layer-2 VPN architectures [L2VPN-ROSEN], [L2VPN-KOMP] are being proposed within provider provisioned VPNs working group. Both are based on [MARTINI- ENCAPS] for encapsulating layer-2 frames and they differ in the way l2vpn services are built and auto-discovered and whether signaling of l2vpn information (i.e., encapsulation) is decoupled from the auto-discovery scheme.[L2VPN-ROSEN] is based on [MARTINI-TRANSP] as a signaling scheme to establish layer-2 circuits. Further improvement to the scheme, [ROSEN-SIG] introduced the concept of single sided signaling to accommodate a VPLS service where endpoint need not have apriori knowledge of each other. [L2VPN-KOMP] build the l2vpn through site indexation scheme. Although these two architectures are still under development within PPVPN WG, this document describes how logical PE architecture can be adapted to a core network running either [MARTINI-TRANSP] based l2vpn solution, or [L2VPN-KOMP] architecture or running both types of architectures. 2.3.2 L2VPN Architectures and VPLS An important objective of existing Provider Provisioned network- based VPN solutions is to address VPN service and provider network scalability requirements [PPVPN-REQ], [PPVPN-FRAME]. 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). However, most of these network-based VPNs solutions and techniques have been applied to a network model with the assumption that the provider edge devices have all equal weight Ould-Brahim, et al. May 2002 [Page 6] draft-ouldbrahim-l2vpn-lpe-00.txt November 2001 and are assumed to scale to a large number of VPNs. An Ethernet VPLS based solution is required to meet the scaling requirement where the PEs facing customer devices need to support a large number of VPLS services where each VPLS has a large number of ports attached to it. Furthermore, the PEs may also be used to provide other VPN services (like layer-3 VPNs or point to point L2VPNs). Scaling the number of VPLSs and port density on the PE at the same time balancing the cost across provider edge devices should be a main design goal for any VPLS solution. 2.4 VPLS and Logical PE Approach One way of achieving both scaling and cost objectives is to distribute some of the VPLS and VPN functions like MAC learning, 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]. 2.5 VPLS Architecture Functions and VPLS Models This sections describes the basic functions in a VPLS solution and describes VPLS architecture models. 2.5.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. 2.5.2 VPLS Main Functions A VPLS service should provide a set of functions, which mostly are: o MAC Learning Ould-Brahim, et al. May 2002 [Page 7] draft-ouldbrahim-l2vpn-lpe-00.txt November 2001 MAC learning deals with the case where an Ethernet frame, received from customer let say CE1, arrives at the ingress PE1 with a source MAC address A and a destination MAC address B. B is not an entry in PE1 address look-up table. Mechanisms like multicast, flooding can be used to inform each VPLS member PE device of the unknown destination address frame, and eventually the packet is received by B. Source MAC learning will be accomplished by storing the source information with its route (i.e., PE/tunnel) at each PE member of the VPLS. One mechanism is to bound the service tunnel (e.g., VC Label in [MARTINI- TRANSP]) with the source MAC address. Therefore future lookup on a packet received by the PE having the learned MAC destination address will produce the egress tunnels that can be used to forward the packet to the proper egress PE device. o Broadcast and Multicast Capability A VPLS needs to have a broadcast capability. This is needed both for broadcast frames, and for link layer packet flooding, where a unicast frame is flooded because the path to the destination link layer address is unknown. o Tunneling Like any VPN technology, VPLS solution has to provide mechanisms by which customer traffic is separated. VPLS traffic can be tunneled using tunneling mechanism such as Ethernet, GRE, L2TP, MPLS, IPSec. o VPLS Membership Determination VPLS membership is analogous to that of layer-3 and layer-2 VPNs. It generally requires only knowledge of the local VPN link assignments at any given VPLS edge node, and the identity of, or route to, the other edge nodes in the VPLS. A common mechanism to associate a customer facing port at the PE level to the VPLS is to associate a VPN membership scheme to the VPLS and any port member of a given VPLS will be assigned the same VPN membership ID. Depending on the VPLS architecture, one common VPN membership scheme is to use the VPN-IDs format [RFC- 2685]. o VPLS Topology and Loop Prevention The topology of the VPLS could be manipulated by controlling the configuration of peer nodes at each VPLS edge node combined with an auto-discovery mechanism. In order to preclude the need for traffic between two VPLS nodes to transit through another VPLS node, which would then require the use of the Spanning Tree protocol, fully mesh VPLS topology between PEs can be used. Ould-Brahim, et al. May 2002 [Page 8] draft-ouldbrahim-l2vpn-lpe-00.txt November 2001 o VPLS Auto-Discovery Auto-discovery function (e.g., [BGP-AD]) is necessary for any network-based VPNs in order to meet network scalability requirements. VPLS architectures should support an automatic mechanism that allows a particular VPLS to automatically discover the VPLS members configured on a given PE. It may happen that the auto-discovery mechanism extends to also provide information such as encapsulation scheme to be used to forward private frames across the tunnels (e.g., [KOMP-L2VPN]). 2.5.3 VPLS Model: Full Mesh Point-to-Point Circuits The Full Mesh Point-to-Point VPLS model suggests that PE Ethernet ports member of a VPLS are connected in a fully mesh topology across the service provider network. The PE has the functionality to receive frames from the attached CEs and make a decision to what egress tunnel the frame should be forwarded. MAC learning is achieved through the data plane through broadcast/flooding on each per VPLS circuit (within the VPLS domain). When MPLS is used as the tunneling mechanism, bi- directional LSPs need to be established between each VPLS endpoint. 2.5.4 Virtual Bridge/Switch Model The virtual bridge/switch model is similar to layer-3 VPN virtual router/VRF models except that each VPLS edge node implements link layer forwarding rather than network layer forwarding. Virtual bridge/switches are connected through point-to-point private tunnels. As such, most of the layer-3 VPN tunneling and configuration mechanisms discussed in [PPVPN- FRAME] can also be used for virtual switches, with the appropriate changes to accommodate link layer, rather than network layer, packets and addressing information. 2.5.5 Virtual Switch with Full Mesh Point-to-Point Model It is possible to combine a virtual switch model with a full mesh point-to-point tunnels. One approach is to use virtual switch model based on VPLS membership for broadcast, user unknown, and multicast, and full-mesh for known Unicast packet. 3. Logical PE Architecture This section describes the LPE architecture with its related building blocks and functions. 3.1 VPLS LPE Reference Model Ould-Brahim, et al. May 2002 [Page 9] draft-ouldbrahim-l2vpn-lpe-00.txt November 2001 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 | | / +-------+ / +---+ /+-----+ / | +-/--+ +---+ | | / | | | | |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. An example of logical PEs is shown in figure 2 and 3. +---+ +---+ Ould-Brahim, et al. May 2002 [Page 10] draft-ouldbrahim-l2vpn-lpe-00.txt November 2001 | P |....| P | +---+ +---+ +---+ /|CE5| +---+ / \ / +---+ |CE2|\ +-----+ +-----+ +---+ +---+ \| PE1 | | |----| | /| PE2 | | PE4 | |CE6| / +-----+ VPLS/LPE | PE5 |----| | +---+ | Solution +-----+ +---+ |CE1| +-----+ | +---+ | PE7&| +-----+ +---+ /| PE3 | |PE8&6|----|CE7| +---+/ +-----+ +-----+ +---+ |CE3| | \ / \ +---+ | +---+ +---+ +---+ +---+ | P |....| P | |CE9| |CE8| +---+ +---+ +---+ +---+ Figure 2: Logical Grouping between PE Edges and PE Cores +---+ +---+ | P |....| P | +---+ +---+ +---+ /|CE5| +---+ / \ / +---+ |CE2|\ +-----+ +-----+ +---+ +---+ \| LPE1| | |----| | /| | |LPE3 | |CE6| / +-----+ VPLS | |----| | +---+ | Solution +-----+ +---+ |CE1| +-----+ | +---+ | LPE2| +-----+ +---+ /| | |LPE4 |----|CE7| +---+/ +-----+ +-----+ +---+ |CE3| | \ / \ +---+ | +---+ +---+ +---+ +---+ | P |....| P | |CE9| |CE8| +---+ +---+ +---+ +---+ Figure 3: Network reference using using logical PEs Within the LPE reference model, a CE can be attached to one or more than one PE-Edges. 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-Core is associated with only one logical PE. An LPE may contain more than one method of tunneling or switching mechanism. A single LPE alone may even implement a separate Ould-Brahim, et al. May 2002 [Page 11] draft-ouldbrahim-l2vpn-lpe-00.txt November 2001 low-scale L2VPN. PE-Edge is associated with only one logical PE. Logical PE expresses the relationship between PE-Edge devices and PE-Core devices. Note that a PE core can act as any conventional PE providing VPN services. 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. 3.2 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 4: Logical PE with PE-Edges and PE-Cores 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. Multiple PE-Edges can be connected to one or more PE-core. Ould-Brahim, et al. May 2002 [Page 12] draft-ouldbrahim-l2vpn-lpe-00.txt November 2001 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. Each PE-Edge/PE-Core is associated with a set of VPLS services. PE-Core implements a layer-2 VPN/VPLS solution and can offer layer-3 VPNs. 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. PE-Cores are connected in a fully mesh topology. PE-Edges sees 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. However, any inter-site connectivity within the logical PE need not involve other PEs. 3.3 Network Connectivity within the Logical PE 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.3.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.3.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.4 Logical PE Function Distribution Ould-Brahim, et al. May 2002 [Page 13] draft-ouldbrahim-l2vpn-lpe-00.txt November 2001 Logical PE function distribution depends on the VPLS architecture model used. In most cases, the PE-Edge manages the SLA including bandwidth policing, traffic classification and, QoS, customer Ethernet frame encapsulation and MAC and VLAN learning. The PE-Core maintains membership information and performs VPN membership determination and dissemination 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 LPEs. Such distribution can be constrained to only the LPEs that have VPLS membership in common. Following are a list of PE functions that can be distributed in forming a LPE: o MAC learning o Participation in customer Spanning Tree Protocol (if needed). o Tunneling within LPE. o Service label de-multiplexing within LPE. o PE-Edge/PE-Core auto-discovery protocol (LPE-AD). o Customer traffic policing and shaping (if necessary) o Customer VLAN processing. o Customer traffic priority handling. o VPLS configuration 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 (when required). 3.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 o Participation in customer Spanning Tree Protocol (if needed). o VPLS membership determination o PE-Edge/PE-Core auto-Discovery protocol (LPE-AD). o Tunneling within the LPE. o Service label de-multiplexing within LPE. o Customer traffic policing and shaping (if necessary) o Customer VLAN processing. o Customer traffic priority handling. o VPLS configuration (depending on the configuration model). 3.4.2 PE-Core Functions Ould-Brahim, et al. May 2002 [Page 14] draft-ouldbrahim-l2vpn-lpe-00.txt November 2001 A PE-Core being attached to an IP/MPLS network and providing other VPN service than just VPLS should provide the following functions: o VPLS membership determination. o Tunneling between PEs (MPLS/IP based). o Service label de-multiplexing between PEs. o VPLS Configuration. o VPLS auto-discovery between PEs. o VPLS signaling between PEs (when required). o PE-Edge/PE-Core auto-discovery protocol (LPE-AD). 3.5 Logical PE Auto-Discovery Protocol (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 at the LPE level. o Addition/Deletion/Modification of PE-Edges. 3.6 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. 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.7 Logical PE Forwarding and Auto-Discovery A Logical PE can be applied to a fully meshed point-to-point, virtual switching model, or a hybrid VPLS models. VPLS or VPLS endpoints can be reflected on the PE-Core. For a full mesh point to point, VPLS endpoints defined on each PE-Edge will have a logical representation "virtual endpoint" within the PE- Core. Therefore a given PE-Core will reflect multiple VPLS services where each service has multiple endpoints configured on multiple PE-Edges. Each virtual endpoint on the PE-Core is Ould-Brahim, et al. May 2002 [Page 15] draft-ouldbrahim-l2vpn-lpe-00.txt November 2001 fully meshed with other virtual endpoints on the remote PE- Cores. Another approach similar to [KOMP-DTLS]is to consider the PE-Edge connectivity as site connectivity and the endpoint is associasted with the site (PE-Edge) connectivity. 3.7.1 VPN Auto-Discovery on the Core Network On the core network, point-to-point circuits can be created using either [L2VPN-KOMP], or [Martini-TRANSP] type architectures (e.g., [L2VPN-ROSEN]). For example, [MARTINI- TRANSP] 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]). This draft doesn't preclude other VPN auto-discovery mechanisms (e.g., LDP based). 3.7.2 LPE Forwarding Algorithm for [MARTINI-TRANSP] on the Core The following algorithm can be used to forward Unicast Ethernet frames to the remote PE-Edges. It is assumed that MPLS labels are used as de-multiplexing scheme at the PE-Edge and PE-Core. Tunneling is used on the PE-Core (can be IP or MPLS based). Ethernet/MPLS optionally be used between PE-Edge and PE-Core. The LPEs are connected through a full mesh of tunnels (e.g., traffic engineered tunnels, RSVP-TE/CR-LDP traffic engineered tunnels). 1. A VPLS is created on the PE-Edge. 2. Each VPLS endpoint is mapped to a virtual endpoint on the PE-Core. 3. Each PE-Core VPLS virtual endpoint is associated with its membership scheme. 4. LPE-AD mechanism is run between the PE-Edge and PE-Core. 5. LDP-DU signaling is used by PE_Cores to establish VC LSP between VPLS virtual endpoints across the core. 6. A customer frame is received on a given VPLS port on the PE-Edge. 7. The packet is labeled to reach the virtual endpoint on the PE-Core. 8. The local PE-Core received the packet swap the service label with the remote egress VC LSP label. 9. The labeled packet is then tunneled to the remote PE-Core. 10. The remote PE-Core performs a lookup on the service label, Ould-Brahim, et al. May 2002 [Page 16] draft-ouldbrahim-l2vpn-lpe-00.txt November 2001 identifies the egress port where the PE-Edge is attached 11. The PE-Core swaps the corresponding PE-Edge service label and forward the packet. 12. Once the packet is received by the PE-Edge it will then be forwarded to the egress port. 3.7.3 LPE Forwarding Algorithm using [L2VPN-KOMP] on the Core The following algorithm can be used to forward unicast Ethernet frames to the remote PE-Edges when [KOMP-L2VPN] solution is used in the core network (PE-Cores). The LPEs are connected through a full mesh of point to point tunnels (e.g., traffic engineered tunnels using RSVP-TE/CR-LDP). 1. A VPLS is created on the PE-Edge. 2. Each VPLS endpoint is mapped to a virtual endpoint on the PE-Core. 3. The virtual endpoint is considered private site attachment to the logical PE. 4. An auto-discovery mechanism is run between the PE-Edge and PE-Core. 5. Each PE-Core VPLS virtual endpoint is associated with its [KOMP-L2VPN] configuration information (e.g., CE_ID, CE_range, label_base, route-target export and import list for the VPLS virtual forwarding table. 5. BGP auto-discovery is used on the core network informing all the PE-Core about the virtual endpoints. 6. A customer frame is received on a given VPLS port on the local PE-Edge. 7. The packet is labeled with a VPLS service label to reach the virtual endpoint on the PE-Core. 8. The local PE-Core look up the label, identify the virtual endpoint, lookup the virtual forwarding table and push the two labels onto the packet (the top label for the LSP to reach the egress PE-Core and the inner label is for reaching the virtual endpoint interface). 10. The remote PE-Core performs a lookup on the service label, and identify the egress virtual endpoint. If the endpoint is located on the PE-Edge, the PE-Core swaps the service label with the remote PE-Edge VPLS service label. 11. The labeled packet is then tunneled to the remote PE-Edge. 12. Once the packet is received by the PE-Edge it will then be forwarded to the egress port. Another approach with [KOMP-L2VPN] is to consider the PE- Edge/PE-Core connectivity as a site connectivity. This approach avoids configuring/learning about virtual endpoints (assuming only Ethernet frames are traversing this link). Example of such scheme can be found in [KOMP-DTLS]. Decouple Transparent LAN model (DTLS) extends the [KOMP-L2VPN] architecture to Ould-Brahim, et al. May 2002 [Page 17] draft-ouldbrahim-l2vpn-lpe-00.txt November 2001 accommodate a VPLS service using the LPE network reference model. 3.7.4 Virtual Switch Proxy (VSP) A virtual switch proxy can be created on the PE-Core for each VPLS defined on the PE-Edge. Virtual switch proxies are fully meshed within the core network. Traffic destined to sites across the core network will traverse the virtual switch proxy. VSP LSPs can be established based on the VPLS/VS membership. MAC learning is still achieved at the PE-Edge level. The model can also extend to create virtual switches at the granularity of PE-Edge connectivity, and treats each PE-Edge connectivity as site connectivity. LPE Forwarding for user Unknown Unicast, Broadcast, and Multicast Packets using VSP type approach (with no link layer forwarding): In the case of unknown unicast, broadcast and multicast packet a VSP type approach can be used as described below: 1. PE-Edge forward the packet to the PE-Core. 2. The PE-Core identifies the VPLS membership of the packet, and finds that it needs to identify the set of PE-Cores members of the same VPLS (i.e., having at least one port member of that VPLS). 3. Pe-Core broadcast/multicast the packet to this set of PE-Cores. 4. PE Core then appends the service label associated with the membership scheme (i.e., VC GROUP) and tunnel the packet to the far end LPEs. 5. When the egress PE-Core receives the MPLS encapsulated packet, it will examine the service label and since it is related to a set of VPLS members, it will map the service label to a set of destination PE-Edges/PE-Edge endpoints. 6. When the packet reaches the egress PE-Edge, the PE-Edge learns the binding between source MAC address and the PE-Core within the LPE. 3.8 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 Ould-Brahim, et al. May 2002 [Page 18] draft-ouldbrahim-l2vpn-lpe-00.txt November 2001 used to maintain unique VPLS membership across the service provider network. 3.9 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 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. 3.10 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. 3.11 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. 4. References Ould-Brahim, et al. May 2002 [Page 19] draft-ouldbrahim-l2vpn-lpe-00.txt November 2001 [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. [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", Ould-Brahim, et al. May 2002 [Page 20] draft-ouldbrahim-l2vpn-lpe-00.txt November 2001 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. [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 5. Acknowledgments. 6. 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. 7. 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 Ould-Brahim, et al. May 2002 [Page 21] draft-ouldbrahim-l2vpn-lpe-00.txt November 2001 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 22] draft-ouldbrahim-l2vpn-lpe-00.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 23]