Provider Provisioned VPN WG Dinesh Mohan [Editor] Internet Draft Michael Chen draft-ouldbrahim-l2vpn-lpe-02.txt Vasile Radoaca Expiration Date: August 2002 Hamid Ould-Brahim Nortel Networks Pascal Menezes Terabeam Networks March 2002 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 Ould-Brahim, et al. Expires August 2002 [Page 1] draft-ouldbrahim-l2vpn-lpe-02.txt March 2002 Service Providers offer Virtual Private LAN Service (VPLS), also known as Transparent LAN Service (TLS), as part of their Layer 2 VPN offering. VPLS simulates an Ethernet Virtual 802.1d bridge for given set of customers across metro or wide area networks. From an end-user's perspective, a VPLS ties geographically separate customer sites together as if they share a common LAN segment. A VPLS service 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 metro or wide area network. Such providerÆs edge devices store information related to customer VPLS domains and are responsible for making forwarding decisions related to customers VPLS traffic. A problem arises when there is need to provide a network-based VPLS solution that scales to a large number of VPLSs, each with potentially a large number of customer ports while at the same time providing a solution that is cost-effective and reliable for the Service ProvidersÆ access infrastructure. This draft introduces the "Logical PE" architecture to effectively address the scalability of VPLS services. Table of Contents Abstract 1. Conventions used in this document........................3 2. Introduction.............................................3 2.1 What is VPLS Service?...................................4 2.2 VPLS/L2VPN Reference Model..............................4 2.3 VPLS Functions..........................................4 2.3.1 VPLS Control Plane Functions..........................5 2.3.1.1 VPLS Membership Auto-discovery......................6 2.3.1.2 VPLS Transport Tunnel Signaling.....................6 2.3.1.3 VPLS Topology & Loop Prevention.... ................6 2.3.1.4 Service Label Signaling.............................7 2.3.2 VPLS Forwarding Plane Functions.......................7 2.3.2.1 MAC Learning........................................7 2.3.2.2 Customer VLAN Processing............................7 2.3.2.3 Customer Packet Replication/Flooding................7 2.3.2.4 Virtual Bridging/Switching..........................8 2.3.2.5 Customer Packet Encapsulation.......................8 2.3.2.6 Service Label De-multiplexing.......................8 2.3.2.7 VPLS Resiliency.....................................8 2.3.2.8 VPLS QoS............................................9 2.3.3 VPLS Management Plane & OAM&P Functions..............10 2.3.3.1 VPLS Configurations................................10 2.3.3.2 Operations and Maintenance Functions...............10 3. VPLS Deployment & Scaling Issues........................10 4. Logical PE (LPE) Architecture...........................11 4.1 LPE Definition.........................................11 4.2 LPE Functional Elements................................13 4.2.1 LPE VPLS Configurations..............................13 Ould-Brahim, et al. Expires August 2002 [Page 2] draft-ouldbrahim-l2vpn-lpe-02.txt March 2002 4.2.2 LPE VPLS Auto-discovery..............................13 4.2.3 LPE VPLS Topology & Loop Prevention..................14 4.2.4 LPE MPLS MAC Learning................................14 4.2.5 LPE Customer Packet Encapsulation....................14 4.2.6 LPE Service Label De-multiplexing....................15 4.2.7 LPE VPLS Resiliency..................................15 4.2.8 LPE VPLS QoS.........................................15 5. LPE VPLS Reference Model................................16 6. LPE Functional Distribution Example.....................17 6.1 PE-Edge Functions......................................18 6.2 PE-Core Functions......................................18 7. Security Considerations.................................19 8. References..............................................19 9. Acknowledgments.........................................21 10. Intellectual Property Considerations...................21 10. Author's Addresses.....................................21 Full Copyright Statement...................................22 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 Service Providers offer Virtual Private LAN Service (VPLS), also known as Transparent LAN Service (TLS), as part of their Layer 2 VPN offering. VPLS simulates an Ethernet Virtual 802.1d bridge for given set of customers across metro or wide area networks. From an end-user's perspective, a VPLS ties geographically separate customer sites together as if they share a common LAN segment. A VPLS service 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 metro or wide area network. Such providerÆs edge devices store information related to customer VPLS domains and are responsible for making forwarding decisions related to customers VPLS traffic. A problem arises when there is need to provide a network-based VPLS solution that scales to a large number of VPLSs, each with potentially a large number of customer ports while at the same time providing a solution that is cost-effective and reliable for the Service ProvidersÆ access infrastructure. This draft introduces the "Logical PE" architecture to effectively address the scalability of VPLS services. Ould-Brahim, et al. Expires August 2002 [Page 3] draft-ouldbrahim-l2vpn-lpe-02.txt March 2002 2.1 What is VPLS Service? 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 multi-protocol transport and for regulatory reasons in the Service Provider context. 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/L2VPN Reference Model The VPLS service reference model follows the models 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 (PE). PEs are connected to providerÆs internal devices (P) which are considered VPLS unaware. P devices participate in providing tunnels/LSP between PE devices across the providers packet switched IP/MPLS core network infrastructure. This reference model is similar to existing layer-3 and point-to- point reference models. 2.3 VPLS Functions It is possible to describe the VPLS functions based on a functional model as shown in Figure 1. +----------------------+--------------------------------+ | Service Quality | Quality of Service | |----------------------+--------------------------------| | | Resiliency | Ould-Brahim, et al. Expires August 2002 [Page 4] draft-ouldbrahim-l2vpn-lpe-02.txt March 2002 |----------------------+--------------------------------| | Provisioning | Static Configurations | |----------------------+--------------------------------| | | Dynamic Configurations | |----------------------+--------------------------------| | Auto-Discovery | Node | |----------------------+--------------------------------| | | VPLS membership | |----------------------+--------------------------------| | Signaling | Transport tunnel | |----------------------+--------------------------------| | | Service Multiplexing | |----------------------+--------------------------------| | Encapsulation | Tunneling | |----------------------+--------------------------------| | | Service Multiplexing | |----------------------+--------------------------------| | Reachability | MAC Learning | |----------------------+--------------------------------| | | VLAN Processing | |----------------------+--------------------------------| | Management | OAM | +----------------------+--------------------------------+ Figure 1: VPLS/L2VPN Functional Model This section describes the functional elements based on the model in Figure 1 for a VPLS solution that can be classified under control plane, forwarding plane and Management/OAM&P plane. These functional elements are: o VPLS membership auto-discovery o Transport tunnel signaling o VPLS Topology & Loop Prevention o Service label signaling o VPLS Configurations o MAC learning o Customer VLAN processing o Packet Replication/Flooding o Virtual Bridging/Switching o Customer packet encapsulation o Service label de-multiplexing o Resiliency o Customer traffic prioritizing, policing, and shaping o Operations and Maintenance 2.3.1 VPLS Control Plane Functions 2.3.1.1 VPLS Membership Auto-discovery Ould-Brahim, et al. Expires August 2002 [Page 5] draft-ouldbrahim-l2vpn-lpe-02.txt March 2002 Auto-discovery function (e.g., [BGP-AD]) is necessary for any network-based VPNs in order to meet network scalability requirements. For VPLS, auto-discovery allows a VPLS aware device to find all other VPLS aware devices that contain the same VPLS membership. It may happen that the auto-discovery mechanism extends to also provide other VPLS information such as encapsulation/multiplexing scheme to be used to forward private frames across the tunnels (e.g., [L2VPN-KOMP]). BGP based auto-discovery mechanism can also be used in the core to inform each VPLS aware device about VPLS membership information (e.g., described in [BGP-AD], and [L2VPN-KOMP]). 2.3.1.2 VPLS Transport Tunnel Signaling VPLS traffic between VPLS aware devices can be tunneled across Service Provider IP/MPLS packet switched core using tunneling mechanism such as MPLS, Qtag, GRE, L2TP, and IPSec etc. In the core network, point-to-point tunnels can be created using either [L2VPN-KOMP], or [MARTINI-TRANSP] type architectures (e.g., [L2VPN-ROSEN]). It is possible that the transport tunnel signaling might be integrated with auto- discovery mechanism or decoupled with auto-discovery mechanisms. When using MPLS as the tunneling mechanism, bi- directional LSPs need to be established between each VPLS endpoint. 2.3.1.3 VPLS Topology & Loop Prevention In order to preclude the need for traffic between two VPLS aware devices to transit through another VPLS VPLS aware device, which would then require the use of the Spanning Tree protocol; fully meshed point-to-point VPLS topology between VBs can be used. 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). Another topology that can be used is virtual bridge/switch model that is similar to layer-3 VPN virtual router/VRF models except that each VPLS edge device 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 Ould-Brahim, et al. Expires August 2002 [Page 6] draft-ouldbrahim-l2vpn-lpe-02.txt March 2002 addressing information. Care must be taken to avoid formation of forwarding loops. 2.3.1.4 Service Label Signaling Signaling is required to distribute the Service Label in a VPLS solution. Service Label is used at VPLS aware egress device to multiplex multiple VPLS services over the VPLS transport tunnels and at VPLS aware egress device to distinguish individual emulated VPLS Ethernet frames within a single VPLS transport tunnel and the source VPLS aware device. Service Label signaling can be carried out using mechanism specified in [MARTINI-TRANSP], [L2VPN-KOMP] etc. 2.3.2 VPLS Forwarding Plane Functions 2.3.2.1 VPLS MAC Learning 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 broadcast/multicast flooding can be used to inform every other PE device in the same VPLS 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 path (i.e., PE/tunnel) at each PE member of the VPLS. One mechanism is to bind 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 a VC LSP that can be used to forward the packet to the proper egress PE device. 2.3.2.2 Customer VLAN Processing A customer VLAN identification, using some scheme such as IEEE 802.1q tags, customers port configurations or other means, allow for separate broadcast domain within the same customer network. A VPLS service can be extended to recognize customer VLAN identification in context of the VPLS that the VLAN is part of. Each of these customer domains needs to appear as a separate broadcast domain within the VPLS solution. However the VPLS service should not constrain the customerÆs ability to configure VLAN topologies, VLAN tags etc. 2.3.2.3 Customer Packet Replication/Flooding Ould-Brahim, et al. Expires August 2002 [Page 7] draft-ouldbrahim-l2vpn-lpe-02.txt March 2002 A VPLS needs to have a broadcast capability. This is needed both for broadcast and multicast frames, and for link layer packet flooding, where a unicast frame is flooded because the path to the destination link layer address may be unknown. 2.3.2.4 Virtual Bridging/Switching The three functions listed under the Sections 2.3.2.1, 2.3.2.2 and 2.3.2.3, essentially allow the VPLS to offer Virtual 802.1d Bridging/Switching capabilities. It is called Virtual since bridging/switching occurs on across a core IP/MPLS network infrastructure. 2.3.2.5 Customer Packet Encapsulation To forward an Ethernet frame, a VPLS aware device must be able to associate a destination MAC address with a VPLS emulated circuit in the transport tunnel. To allow dynamic learning and association of destination MAC addresses with VPLS emulated circuits in transport tunnels across the core IP/MPLS network infrastructure, Ethernet frames need to be encapsulated at the VPLS aware ingress device. For example, such encapsulation can be carried out as per [MARTINI-ENCAPS] that defines a dual label stack. One label is needed to transport the frame across the IP/MPLS core while the other contains demultiplexing information about the enclosed frame that is necessary in order to properly emulate the layer 2 services. 2.3.2.6 Service Label De-multiplexing Service Label De-multiplexing is required to distinguish individual emulated VPLS Ethernet frames within a single VPLS transport tunnel. Such de-multiplexing is to be carried out at the VPLS aware egress device. The service label de-multiplexing can be based on VPLS transport tunneling protocol e.g., an MPLS label (e.g. in [MARTINI-ENCAPS]) or a GRE key field. 2.3.2.7 VPLS Resiliency VPLS resiliency is an important consideration to ensure service availability in presence of failures. Indeed, VPLS, like any other layer-2 scheme is subject to failures like link, trunk and node failures. Besides the Service Provider core network infrastructure resiliency, considerations of access network resiliency are also important. Upon the occurrence of failure, Ould-Brahim, et al. Expires August 2002 [Page 8] draft-ouldbrahim-l2vpn-lpe-02.txt March 2002 it is desirable that the failure be detected immediately and protection mechanisms allow fast restoration times to make VPLS service almost transparent to these failures to the extent possible, based on the level of resiliency. Essential aspects of providing resiliency are: - Link/Node failure detection û Mechanisms within the VPLS service should allow for link or node failures that impact the Service, and should be detected immediately. - Resiliency policy û Depending upon the VPLS service specification in associated SLA, the detected failure be handled based on restoration policy. It may need to be handled immediately, or handled only if no other critical failure needs protection resources or completely ignored if the VPLS service being offered allows acceptable downtimes. This could also determine if the resiliency is revertive or non-revertive. - Restoration Mechanisms û The VPLS solutions could allow for physical level protection, logical level protection or both. For example, through dual homing of customer connections to provider customer-facing devices, one connection can be maintained as active while the other could be marked as a backup and upon the failure detection across the primary connection, the backup could become active. 2.3.2.8 VPLS QoS Based on the customer VPLS SLA, traffic from customer can be prioritized, policed and shaped for Quality of Service requirements. The queuing and forwarding policies can preserve the packet order and QoS parameters of customer VPLS traffic. Combining the bandwidth flexibility of Ethernet with the sophisticated traffic engineering tools of MPLS enables Service Providers realistic opportunities to offer differentiated class of services. The class of services can be mapped from customer Ethernet priority information e.g. 802.1p or it can be independent of it. QoS functions can be listed as follows: - Customer Traffic Prioritization û VPLS service could be best effort or QoS guaranteed. Traffic from one customer might need to be prioritized over others when sharing same network resources. This requires capabilities within the VPLS solution to classify and mark priority to QoS guaranteed customer traffic. - Policing û This ensures that a user of VPLS service uses VPLS network resources within the limits of the agreed SLA. Any excess VPLS traffic can be rejected or handled differently based on provider policy. Ould-Brahim, et al. Expires August 2002 [Page 9] draft-ouldbrahim-l2vpn-lpe-02.txt March 2002 - Shaping û Under some cases the random nature of VPLS traffic might lead to sub-optimal utilization of network resources. Through queuing and forwarding mechanisms the traffic can be shaped without altering the packet order. 2.3.3 VPLS Management Plane & OAM&P Functions 2.3.3.1 VPLS Configurations It is desirable that a VPLS is designed to need minimal configuration when adding or deleting customer-facing ports to, or from, a given VPLS where several disjoint instances of VPLS within same network infrastructure could exist. To associate a PE level customer-facing port to the VPLS, a common mechanism used is to associate a VPN membership scheme to the VPLS. Thereby any port member of a given VPLS will be assigned the same VPN membership ID. A common VPN membership scheme is to use the VPN-IDs format [RFC-2685]. The topology of the VPLS could be manipulated by controlling the configuration of peer devices at each VPLS edge device combined with an auto-discovery mechanism. 2.3.3.2 Operations and Maintenance Functions A VPLS solution can provide mechanisms to manage and monitor different VPLS components. From a Service Level Agreement (SLA) perspective, VPLS solution could allow monitoring of VPLS service characteristics and offer mechanisms used by Service Providers to report such monitored statistical data. Trouble-shooting and verification of operational and maintenance activities of VPLS service are essential requirements for Service Providers. 3. VPLS Deployment and Scaling Issues A Service Provider access/metro network might have small low- cost provider provisioned devices at the customer premises connected to a device at the providerÆs central office. The devices at the central office tend to have more functional capabilities compared to the low-cost devices at customer premises. The provider provisioned low-cost devices typically interface with the customer edge devices. VPLS Service deployment has operational, cost and scalability considerations. While cost and operational overhead for a service needs to be minimal, it should be highly scalable. Ould-Brahim, et al. Expires August 2002 [Page 10] draft-ouldbrahim-l2vpn-lpe-02.txt March 2002 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, VPLS contains some unique properties. Layer-2 VPN solutions extend the concept of traditional layer-2 circuits to accommodate VPN constructs like membership, auto- discovery, tunneling, and topology discovery. VPN Scalability is addressed mostly through 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 solution meets the scaling requirement where the PEs facing customer devices and attached to a core network need to perform MAC learning for all VPLS instances. Besides providing VPLS services, these PEs may also be used to provide other VPN services e.g. layer-3 VPNs or point to point L2VPNs. One way of achieving scaling, reliability and cost objectives is to distribute VPLS and VPN functional elements like MAC learning, auto-discovery, aggregation etc among multiple provider devices. This concept is manifested by "Logical PE" architecture that distributes the functional elements between providerÆs customer-facing edge devices, called "PE-Edges", and providerÆs core-attached edge devices, called "PE-Cores". Another objective of the Logical PE approach besides scaling is to be able to fit nicely with all existing VPN technologies supported in the service provider networks e.g. [VPN-VR], [VPN- RFC2547bis], [L2VPN-KOMP], [L2VPN-ROSEN] and [OVPN], thus preventing Service Providers from vendor lock-ins. 4. Logical PE (LPE) Architecture As discussed in Section 3, Logical PE architecture fits nicely with Service ProviderÆs typical access network. This section describes the LPE architecture with its related building blocks and functions. 4.1 LPE Definition The LPE addresses VPLS scalability and reliability by distributing VPLS functional elements among providerÆs customer-facing edge devices, called ôPE-Edgesö and providerÆs Ould-Brahim, et al. Expires August 2002 [Page 11] draft-ouldbrahim-l2vpn-lpe-02.txt March 2002 core-attached edge devices, called ôPE-Coresö, as shown in Figure 2. The concept of separate PE-Edge and PE-Core edge devices does not prevent the distributed VPLS functional elements from being implemented within the same physical device. PE-Edge devices are not mandatory for building Service ProviderÆs VPLS access network. However, the value addition to the VPLS services for a Service Provider are reasons enough for large scale VPLS service to be preferably implemented across low-cost Ethernet- based ôPE-Edgeö devices and high capacity core-attached ôPE- Coreö edge devices, as explained later in Section 4.2 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 PE-Edges and PE-Cores can be interconnected by switched Ethernet transport network(s) or directly connected links within a LPE. Note that the PE-Core device might also need to support PE-Edge functions when some customer sites might be directly connected to them, for example as shown in Figure 2 where CE-3 is directly connected to a PE-Core. The customer-facing Ethernet ports on PE-Edge and PE-core, when connected directly to customer site, are called LPE endpoints. These LPE endpoints can be logical when LPE supports customer VLAN processing and represent the customer demarcation point for VPLS service. PE-Edges will interoperate with other PE-Edges in the same LPE or different LPEs. PE-Edges connected to the same Switched Ethernet Transport can inter-operate without involvement of a Ould-Brahim, et al. Expires August 2002 [Page 12] draft-ouldbrahim-l2vpn-lpe-02.txt March 2002 PE-Core. A network consists of only PE-Edges can deliver a subset of VPLS services. The PE-Cores provide intermediary functions to enable PE-Edges to interoperate with PEs outside their local Switched Ethernet Transport domain. PE-Cores can also offer VPLS services to CEs directly connected to PE-Core and can also communicate with conventional PE devices that implement VPLS functions on a single device. PE-Cores are connected in a fully mesh topology of transport tunnels across the core network. PE-Edges are only aware of PE-Cores and other PE-Edges in the same-switched Ethernet transport domain; therefore there is no direct full mesh signaling between PE-Edges across the core network. Any inter-site connectivity between PE-Edges across different switched Ethernet transport domains traverses the PE- Cores. 4.2 LPE Functional Elements Following sections describe a list of PE functions that can allow the distribution of functions described in Section 2.3 in forming a LPE: 4.2.1 LPE VPLS Configurations An LPE-based VPLS service can be created either at the PE-Edge or the PE-Core or both. It is also possible to use a service provider network management system to provide these configurations. A VPLS solution is a port-based VPN type architecture. Therefore, configuring LPE endpoints, physical or logical customer-facing ports defined in Section 4.1, and associating these LPE endpoints to VPLS membership scheme accomplishes the VPLS membership. It may happen that a different membership scheme is used for intra-LPE than the membership scheme used for inter-LPE. In this case a mapping function is needed at LPE level to maintain unique VPLS membership across the service provider network. 4.2.2 LPE VPLS Auto-discovery A lightweight protocol similar to [LPE-AD] is recommended between PE-Edge and PE-Core to exchange VPLS related information e.g. membership, tunneling, encapsulation schemes etc. for the purpose of auto-discovery of LPE endpoints belonging to the same VPLS. Example of functions provided by an [LPE-AD] include: Ould-Brahim, et al. Expires August 2002 [Page 13] draft-ouldbrahim-l2vpn-lpe-02.txt March 2002 o Notification of LPE endpoint Addition, Deletion, and Modification within any VPLS. o Service Label/Tunnel information exchange within any LPE. o Addition/Deletion/Modification of PE-Edge devices. 4.2.3 LPE VPLS Topology and Loop Prevention LPE is quite flexible and various network configurations can be implemented, some of them being: - PE-Edges and PE-Cores implemented within a single device - PE-Edge connected directly to PE-core devices through physical links - PE-Edge connected to PE-Core through virtual point-to-point link (e.g. FR, ATM). - Multiple Broadcast/Switched Ethernet Transport domains When implemented within a single PE device, LPE behaves similar to conventional VPLS solutions that exhibit scaling and reliability constraints. PE-Edges can be directly connected to PE-Cores via Ethernet trunks. When the same PE-Edge is connected to same PE-Core via more than one Ethernet trunk, it introduces reliability, as discussed in Section 4.2.6, and potential for load sharing. PE-Edges and PE-cores can also be connected via multiple broadcast or Switched Ethernet Transport domains e.g. Resilient Packet Rings (RPR). In such cases, Ethernet header can be used as a form of transport header between PE-Edge and PE-Core devices. This connectivity offers specific advantages e.g. provide direct PE-Edge-to-PE-Edge connectivity on the same Switched Ethernet Transport domain without requiring PE-Core. 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. 4.2.4 LPE VPLS MAC Learning 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. Ould-Brahim, et al. Expires August 2002 [Page 14] draft-ouldbrahim-l2vpn-lpe-02.txt March 2002 4.2.5 LPE Customer Packet Encapsulation Within the LPE, the Ethernet frame encapsulation scheme can be different than the Ethernet frame encapsulation scheme across the IP/MPLS core network infrastructure. In such a case, the PE- Core carries out the translation/mapping between LPE encapsulation scheme to the core encapsulation scheme. 4.2.6 LPE Service Label De-multiplexing De-multiplexing header can used to identify the VPLS service within a transport tunnel. Mechanisms analogous to the "VC label" stated in [MARTINI-ENCAPS] can be used. 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). 4.2.7 LPE VPLS Resiliency To be able to offer resiliency along the access of the VPLS service network, it is preferable to implement the service using clusters of service elements. This helps to prevent single failures from disrupting large-scale services. LPE-based access network are more tightly coupled than PE-based access networks due to additional signaling required when formulating the LPE. 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. When using more than one PE-Core, one will need mechanisms to blend those PE-Cores into LPE. When PE-Edges are directly connected to PE-Cores via multiple Ethernet trunks, where the PE-Core connected via multiple trunks can be used for load sharing and for recovery from link and device failures. 4.2.8 LPE VPLS QoS 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 Ould-Brahim, et al. Expires August 2002 [Page 15] draft-ouldbrahim-l2vpn-lpe-02.txt March 2002 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. Function includes ingress classification, metering, policing, and egress shaping of customer traffic at the provider boundary. 5. LPE VPLS Reference Model VPLS customers typically connect to providerÆs VPLS aware devices, which could be fully functional PE devices just like any other layer 2 scheme, or low-cost edge Ethernet devices. These edge devices could be themselves attached to either switched Ethernet networks or through uplinks to other provider edge devices, which are attached to a packet switched core IP/MPLS network infrastructure. In the example illustrated in Figure 3, from a conceptual view, PEs facing customer equipment (and not attached to the core network) combined with PE attached to the core network represent a "logical PE" construct where many VPLSs along with other layer-2 and layer-3 VPN services can be offered. +---+ +----+ +---+ +---+ |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 3: Example of VPLS service Ould-Brahim, et al. Expires August 2002 [Page 16] draft-ouldbrahim-l2vpn-lpe-02.txt March 2002 To highlight the case described in Figure 3, 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. Using Figure 3, 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]. 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. Ould-Brahim, et al. Expires August 2002 [Page 17] draft-ouldbrahim-l2vpn-lpe-02.txt March 2002 6. LPE Functional Distribution Example 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-Edges provide 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. While, 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 LPE 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. 6.1 PE-Edge Functions Typically a PE-Edge, being a bridge, a routing switch, or a router, will perform regular Ethernet based functions. These functions are: o MAC learning o Packet Replication/Flooding o Loop Prevention [e.g. participation in customer SPT](OPTIONAL) o Transport tunnel within LPE o Service label de-multiplexing within LPE o Auto-discovery within LPE [e.g. [LPE-AD]] o Customer traffic prioritizing, policing, and shaping o Customer VLAN processing o Packet Encapsulation o VPLS configuration (depending on the configuration model) 6.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 Packet Replication/Flooding o Transport tunnel within LPE o Service label de-multiplexing within LPE o Auto-discovery within LPE [e.g. [LPE-AD]] o VPLS Configuration (depending on the configuration model) o VPLS Auto-discovery between PEs Ould-Brahim, et al. Expires August 2002 [Page 18] draft-ouldbrahim-l2vpn-lpe-02.txt March 2002 o Transport tunnel signaling o Service Label signaling between PEs o Service Label de-multiplexing between PEs o VPN Membership mapping from within LPE domain to core domain (OPTIONAL) 7. Security Considerations VPLS security needs to be considered within the LPE and inter- LPEs. Within the LPE, Customer traffic needs to be separated. Ethernet Qtag, MPLS/IP based tunneling can be used for customer VPLS traffic separation. The level of data path security is same as ATM or FR networks. This document does not 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. 8. References [BGP-AD] Ould-Brahim, H. et al., "Using BGP as an Auto- discovery Mechanism for network-based VPNs", draft-ietf- ppvpn-bgpvpn-auto-02.txt, 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., "Layer 2 VPNs Over Tunnels ", draft-kompella-ppvpn-l2vpn-01.txt, work in progress. [MARTINI-ENCAPS] Martini, L., et al. " Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS Networks", draft-martini-l2circuit-encap-mpls-04.txt, work in progress. [MARTINI-TRANSP] Martini, L., et al., "Transport of Layer-2 Frames over MPLS", draft-martini-l2circuit-trans-mpls- 08.txt, work in progress. [PPVPN-REQ] Carugi, M., et al., "Service requirements for Provider Provisioned Virtual Private Networks", work in Ould-Brahim, et al. Expires August 2002 [Page 19] draft-ouldbrahim-l2vpn-lpe-02.txt March 2002 progress. [PPVPN-FRAME] Callon, R., et al., "A Framework for Provider Provisioned Virtual Private Networks", work in progress. [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. [VPLS-REQ] Waldemar, A., et al., "Requirements for Virtual Private LAN Services (VPLS)", draft-augustyn-vpls requirements-01.txt, work in progress. [VPN-RFC2547bis] Rosen, E., et al., "BGP/MPLS VPNs", draft- ietf-ppvpn-rfc2547bis-01.txt, January 2002, work in progress. [VPN-VR] Ould-Brahim H., et al., "Network-based IP VPN using Virtual Routers", draft-ietf-ppvpn-vpn-vr-01.txt, November 2001, work in progress. [LPE-AD] Knight, P., et al., "Logical PE Auto-Discovery Mechanism", draft-knight-l2vpn-lpe-ad-00.txt, work in progress, November 2001. 9. 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 Hui, Hesham Elbakoury, Paul Knight and many other people who contributed to the concept of logical PE. 10. 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. 11. Author's Addresses Ould-Brahim, et al. Expires August 2002 [Page 20] draft-ouldbrahim-l2vpn-lpe-02.txt March 2002 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 Dinesh Mohan Nortel Networks P O Box 3511 Station C Ottawa ON K1Y 4H7 Canada Phone: +1 (613) 763 4794 Email: mohand@nortelnetworks.com Pascal Menezes Terabeam Networks www.terabeam.com Chief Technology Officer IP Internetworking 2300 Seventh Ave Seattle, WA, USA 98121 Access Line and Fax : 206 686-2001 email: pascal.menezes@terabeam.com 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 Ould-Brahim, et al. Expires August 2002 [Page 21] draft-ouldbrahim-l2vpn-lpe-02.txt March 2002 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. Expires August 2002 [Page 22]