VPLS/LPE L2VPNs: Virtual Private LAN Services using Logical PE Architecture
draft-ouldbrahim-l2vpn-lpe-02

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