[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

            PPVPN Working Group                                         Ali Sajassi
            Internet Draft                                                  Dan Lee
            Expiration Date: September 2002                            Jim Guichard
                                                                      Cisco Systems
                                                                  February 20, 2002
          
          
                                   VPLS Architectures
          
                         draft-sajassi-vpls-architectures-00.txt
          
            Status of this Memo
          
            This document is an Internet-Draft and is in full conformance with all
            provisions of Section 10 of RFC2026.
          
            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 obsolete 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
          
            This document defines a reference architecture for a VPLS system. It
            describes possible VPLS architectures based on this reference
            architecture and the merits of each. Each VPLS architecture is
            described in terms of its logical components and their relationship to
            each other, as well as the mapping of these logical components to
            physical network elements. By understanding these logical components,
            which are fundamental building blocks for any VPLS system, one can
            easily compare different VPLS architectures and understand the pros and
            cons of each. A VPLS system may support one or more of these
            architectures simultaneously.
          
          
                                                                          [Page 1]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
            Having described each VPLS architecture, we explore the different
            logical components of the reference architecture, and describe how they
            relate to a Service Provider backbone (whether MPLS enabled or not).
            Finally, we examine the operation of each VPLS architecture.
          
          Table of Contents
          
          1. Boilerplate for Sub-IP Area Drafts.................................2
          2. Introduction.......................................................3
          2.1. Reference Architecture...........................................6
          2.2. Single-PE Model..................................................9
          2.3. Distributed-PE Model:...........................................10
          2.3.1. Ethernet-based PE-CLE.........................................12
          2.3.2. MPLS/IP-based PE-CLE..........................................14
          3. Emulated VCs......................................................15
          4. Emulated Tunnels..................................................17
          5. Attachment Tunnels................................................17
          5.1. Encapsulation...................................................18
          5.2. Signaling.......................................................18
          6. Extension VCs.....................................................19
          6.1. Encapsulation...................................................19
          6.2. Signaling.......................................................19
          7. Virtual Switch Instance...........................................20
          8. Auto Discovery....................................................21
          9. Auto Configuration................................................21
          10. System Operation.................................................22
          10.1. Single-PE......................................................23
          10.2. Distributed-PE with Ethernet-based PE-CLE......................23
          10.3. Distributed-PE with MPLS/IP-based PE-CLE.......................25
          11. Security Considerations..........................................25
          12. Acknowledgements.................................................26
          13. References.......................................................26
          14. Authors' Addresses...............................................27
          15. Intellectual Property Considerations.............................27
          16. Full Copyright Statement.........................................27
          
          
          1. Boilerplate for Sub-IP Area Drafts
          
            This draft is targeted at the PPVPN WG, as it defines a reference
            architecture for a VPLS system in terms of its logical components, and
            describes possible VPLS architectures that can co-exist simultaneously
            in a VPLS system.
          
            The set of related documents may be found in the "References" section.
          
          Sajassi, et al           Expires September 2002                 [Page 2]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
          
          
          2. Introduction
          
            The primary motivation behind Virtual Private LAN Services (VPLS) is to
            provide connectivity between geographically dispersed customer sites
            across MAN/WAN network(s), as if they were connected through a Local
            Area Network. Furthermore, the intended application for the end-user
            can be divided into the following two categories:
          
               . Connectivity between site routers û LAN routing application
               . Connectivity between site Ethernet switches û LAN switching
                 application
          
            The LAN routing application is intended for the interconnection of
            routers via a metro or wide area network, and for providing a broadcast
            domain among these routers. Traditionally, the interconnection of VPN
            sites over a MAN/WAN has required a mesh of overlay virtual circuits
            between routers. Adding a new router to the interconnection mesh
            potentially requires significant reconfiguration. The VPLS service is
            intended to mitigate this interconnection problem by leveraging native
            broadcast capabilities for router discovery, along with a simple point-
            to-cloud service model. This service model simplifies the task of
            configuration and provisioning for the end customer routers by
            providing a virtual LAN/bridge system. Therefore, to the routers it
            looks as if they are connected via a local LAN switch even though they
            are located in different sites.
          
            The LAN switching application as its name implies provides a virtual
            LAN switching service to its end users and it is used for
            interconnecting customer switches across a MAN/WAN network. Therefore,
            if several sites within a VPN subscribe to this service, it looks as if
            these sites are co-located within a campus, and are connected via a
            local Ethernet switch providing bridging services for them. This
            service is not anticipated to be widely deployed in large-scale
            networks because of limited scalability and lower network efficiency.
            However, for small/medium business customers, this service can be very
            viable to extend the bridging domain between VPN sites across a MAN/WAN
            network. By extending the bridging domain, the customer only needs to
            use low-cost Ethernet switches as CPEs.
          
            The underlying VPLS service for supporting these two types of
            applications is fundamentally the same. However, each application has
            different requirements in terms of control frame processing, MAC
            address usage, BPDUs handling, and so on.
          
          
          Sajassi, et al           Expires September 2002                 [Page 3]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
            The following figure shows a VPLS system with two VPLS instances û one
            for each customer, referred to as ôVPLS Aö and ôVPLS Bö. This figure
            shows that each customer CPE device (whether router or switch) connects
            to a PE device within the Service Provider POP. It should be noted that
            when the term ôa VPLSö is used by itself, it refers to a VPLS instance
            and not a VPLS system.
          
              +----+                                         +-----+
              +CE1 +--+                                  +---| CE2Æ|
              +----+  |    ........................      |   +-----+
              VPLS A  |  +------+               +-----+  |     VPLS B
                      +--| PE   |-- Service ----| PE  |--+
                         +------+   Provider    +-----+
                         / .        Backbone      .
                        /  .          |           .
              +----+   /   .          |           .
              +CE1Æ+--+    .          |           .
              +----+       .        +----+        .
              VPLS B       .........| PE |.........
                                    +----+
                                      |
                                      |
                                    +----+
                                    |CE2 |
                                    +----+
                                    VPLS A
          
          
            One of the main scenarios for the VPLS service is the delivery of an
            Ethernet service to multiple customers co-located in one or more MxUs
            over the Metro Area. MxUs can be apartments or multi-dwelling units
            (MDUs), office buildings or multi-tenant units (MTUs), and hotels or
            multi-hospitality units (MHUs). In such cases, it would be much more
            cost effective to place an aggregation device at the co-location site,
            rather than connecting each CPE directly to a PE within the Service
            Provider POP. This device would be used to aggregate all customersÆ
            traffic and carry it via an uplink to the Service ProviderÆs POP as
            opposed to having a separate uplink for each customer. Because of a
            large number of co-location sites and thus large number of aggregation
            devices in a Metro area, it is important for the aggregation device to
            be truly low cost. In such cases, the VPLS functionality is distributed
            between the aggregation device in the co-location site and the PE
            sitting in the Service Provider POP. Apart from the obvious cost
            reductions, a VPLS system based on a distributed-PE model is also able
            to provide access bandwidth efficiency and system scalability. These
            additional benefits will be described in more detail in section 2.3.
          
          Sajassi, et al           Expires September 2002                 [Page 4]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
          
            The following figure extends the VPLS system architecture to include
            distributed-PE functionality. As can be seen in the figure, the VPLS
            system can have a mix of distributed and non-distributed (single) PEs.
            In the case of a non-distributed PE, we refer to it simply as PE and it
            is typically located in the Service ProviderÆs central office or POP.
            In the case of a distributed PE, we refer to the PE located at the
            customer site as PE-CLE and the PE located in the Service ProviderÆs
            POP as PE-POP. The Service ProviderÆs Backbone network connecting
            PEs/PE-POPs can be based on either MPLS or IP.
          
            As shown in the figure, there are several different ways for CEs and
            PE-CLEs to connect to the Service ProviderÆs network. CEs and PE-CLEs
            can be either connected directly to PE-POPs via a given transport
            mechanism such as SONET, Fiber, CWDM/DWDM, and so on, or they can be
            connected via an Ethernet access network. In the later case, care must
            be taken to avoid loops in the access network using standard mechanisms
            such as STP. Furthermore, there may be cases (although not typical)
            where several customer sites are connected to the same PE-CLE. This may
            imply certain restrictions on the customerÆs network based on the
            capability of the PE-CLE as will be elaborated upon in section 10.2.
          
          Sajassi, et al           Expires September 2002                 [Page 5]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
          
              +----+                                         +------+    +----+
              +CE1 +--+                                  +---|PE-CLE|----|CE2 |
              +----+  |    ........................      |   +------+    +----+
              VPLS A  |  +------+               +------+ |      |        VPLS A
                      +--| PE   |-- Service ----|PE-POP|-+      |       +----+
                         +------+   Provider    +------+        +-------|CE2Æ|
                         / .        Backbone    . \                     +----+
                        /  .          |           .  \      +-----+      VPLS B
              +----+   /   .          |           .   \    /       \
              +CE1Æ+--+    .          |           .    +--|L2 Access|
              +----+       .        +----+        .       | Network |
              VPLS B       .........| PE |.........        \       /
                                    +----+                  +-----+
                                      |                        |
                                      |                        |
                                    +----+                  +------+   +----+
                                    |CE3 |                  |PE-CLE|---|CE3Æ|
                                    +----+                  +------+   +----+
                                    VPLS A                     |        VPLS B
                                                               |
                                                               |      +----+
                                                               +------|CE4Æ|
                                                                      +----+
                                                                      VPLS B
          
          
          
          
          2.1. Reference Architecture
          
            The reference architecture described in this section is based on the
            model defined in [L2ARCH] with several extensions. The model defined in
            [L2ARCH] is primarily intended for non-VPLS systems with non-
            distributed PEs (e.g., a single PE is used to connect a CE device to
            the Service ProviderÆs network).
          
            A non-VPLS L2VPN can be described in terms of its components as defined
            in [L2ARCH]. These components are:
          
               . Attachment VCs
               . Emulated VCs
               . Emulated Tunnels
               . Auto Discovery
               . Auto Configuration
          
          
          Sajassi, et al           Expires September 2002                 [Page 6]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
            We introduce three additional components as follows for a VPLS system
            that will be described in subsequent sections of this draft. The first
            component is mandatory for a VPLS system (along with the first three
            non-VPLS components described above) and the other two components are
            needed for a distributed-PE model (and more specifically for a
            particular distributed-PE model).
          
               . Virtual Switch Instances (VSI)
               . Attachment Tunnels
               . Extension VCs
          
            The only components that are dependent on network type (MPLS vs. IP)
            are Emulated VCs and Emulated Tunnels. In [L2ARCH] an Attachment VC is
            defined as the virtual circuit between a CE and its associated PE, and
            an Emulated VC is defined as the virtual circuit between two PEs.
            Therefore, an end-to-end virtual circuit between two CEs can be defined
            as an ordered triple <Attachment VC, Emulated VC, Attachment VC>. The
            mapping between Attachment VC and its corresponding Emulated VC is one-
            to-one and is performed on each side by its associated PE. Furthermore,
            the mapping between the Attachment VC and its corresponding Emulated VC
            is fixed and is established at the time of end-to-end circuit
            establishment. The Attachment and Emulated VCs are always terminated in
            the PEs and thus L2VPN processing is only limited to PE nodes and
            transparent to P nodes.
          
            In a VPLS system, the Attachment VCs can be considered as connected to
            a Virtual Switch (referred to as a Virtual Switch Instance û VSI)
            corresponding to that VPLS instance at each PE. Furthermore, the
            Emulated circuits can be considered as the virtual circuits connecting
            these Virtual Switches located at each PE.
          
            A VPLS for a given customer can be defined as a set of Virtual Switches
            (one in each PE that is part of the VPLS) connected to each other via
            Emulated VCs and to CEs via Attachment VCs. This means that for a VPLS
            system, the relationship between the Attachment and Emulated VCs is no
            longer fixed. The dynamic mapping of these entities (which is sometimes
            one-to-one for unicast and sometimes one-to-many for multicast or
            broadcast) is provided by each Virtual Switch through the use of the
            destination MAC address, and is performed on a frame-by-frame basis.
          
            Given the above description of a VPLS system, a customer VPLS instance
            can be defined in terms of its Attachment VCs, its Emulated VCs, and
            its set of Virtual Switches as follows: < Ingress Attachment VCs,
            Ingress VSIs, Emulated VCs, Egress VSIs, Egress Attachment VCs>. The
            following figure depicts the Attachment and the Emulated VCs and their
          
          Sajassi, et al           Expires September 2002                 [Page 7]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
            relationship for a given L2VPN with three sites via a) non-VPLS network
            and b) VPLS network.
          
          
                           PE1                           PE2
              +----+      +-----+                       +-----+      +----+
              |CE1 |------+--X--+-----------------------+--X--+------+ CE2|
              |    |------+--X--+-----------------------+--X  |      |    |
              +----+      +-----+                       +--|--+      +----+
                                                           |
                                                           |         +----+
                                                           +---------+ CE3|
                                                                     |    |
                                                                     +----+
          
                <Attachment VCs>     <Emulated VCs>       <Attachment VCs>
          
                           PE1                           PE2
              +----+      +-------+                      +-------+     +----+
              |CE1 |      | +---+ |                      | +---+ |     | CE2|
              |    |------+-|VSI+-+----------------------+-|VSI+-+-----+    |
              +----+      | +---+  |                     | +|--+ |     +----+
                          +-------+                      +--|----+
                                                            |          +----+
                                                            +----------+ CE3|
                                                                       |    |
                                                                       +----+
          
             <Attachment VCs>       <Emulated VCs>        <Attachment VCs>
          
            What differentiates the VSI from a typical Ethernet switch is its
            ability to do MAC address learning, flooding, forwarding, and so on,
            based on virtual circuits (e.g., based on Emulated VCs) per broadcast
            domain. For example, if a physical port of a PE carries several
            Emulated VCs, then the VSI can replicate packets (for flooding or
            broadcasting) across these Emulated VCs over the same physical port.
            This is in contrast to a typical switch that may only perform packet
            replication across physical ports for a given broadcast domain.
          
            A VPLS-capable PE shall have one VSI per VPLS instance and it can
            either be transparent to a customerÆs VLANs or it can recognize the
            customerÆs VLANs. If the PE is transparent to the customer VLANs, then
            the associated VSI will handle customerÆs VLANs transparently; however,
            if the PE needs to recognize customersÆ VLANs and to provide isolation
            among them, then separate VSIs for each customer VLAN should be
            maintained. Each VSI corresponds to a separate broadcast domain and may
          
          Sajassi, et al           Expires September 2002                 [Page 8]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
            be shared between customer sites for the creation of Extranet or
            Internet connectivity. The requirement for maintaining a separate
            broadcast domain per VPLS instance is identified in [VPLS-REQ].
          
            Since customersÆ VLANs can be overlapping, the PE should have the
            capability of associating customers VLANs with a unique identifier for
            identification of the VSIs. Therefore, the ability to a) map customers
            VLANs into unique identifiers (for VLAN-aware PE) and b) to perform VSI
            functionality with Emulated VCs, constitutes major data-plane
            requirements for a VPLS capable PE.
          
            For a PE that needs to recognize customersÆ VLANs and to maintain
            isolation among them, if each customer assigns their VLANs
            independently, then overlapping VLANs can occur within that PE.
            Therefore, the PE is required to provide additional capability so as to
            map customersÆ VLANs into unique VSI identifiers. However, if the
            Service Provider assigns the VLANs to its customers, then assignment
            can be done such that customersÆ VLANs are unique within a PE and thus
            the VLAN-id itself can be used as the VSI identifier thus simplifying
            the requirement for the PE or the PE-CLE (in the case of the
            distributed-PE model). However, this simplification at the PE comes at
            the expense of the customer loosing the flexibility of assigning his or
            her own VLANs (which maybe acceptable for certain deployment models).
          
            The next few sections describe different VPLS architectures. A VPLS
            system may support one or more of these architectures simultaneously.
          
          
          2.2. Single-PE Model
          
            In the single-PE model, each PE is capable of performing the full set
            of VPLS functions and it can be either located in a customer premise or
            at the Service Provider POP. If the PE is located in the customer
            premise, then the link between the CE and the PE is local and many CEs
            can be aggregated via the upstream Service Provider link. However, it
            may cost too much to place a PE in the customer premise or the number
            of customer located PEs may present some system scalability issues. If
            the PE is located in the Service Provider POP, then one MAN link is
            required per customer which may in turn result in an increase cost of
            facilities and thus an increase in operational costs. Section 2.3 shows
            how the use of a distributed-PE can address these issues effectively
            when a single-PE environment is not desirable.
          
            In a single-PE model, all VPLS functionality is performed within a
            single PE. In terms of the data-plane operation, these functions
            constitute:
          
          Sajassi, et al           Expires September 2002                 [Page 9]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
          
               . Attachment VCs termination
               . Emulated VCs termination
               . Tunneling of Emulated VCs
               . Maintaining a VSI per VPLS instance (for bridging among
                 Attachment and Emulated VCs)
          
            In terms of the control-plane operation, these functions constitute:
          
               . Signaling of Emulated Tunnels (if needed)
               . Signaling of Emulated VCs
               . Auto-discovery of peer PEs per VPLS instance
               . Auto-configuration of a VPLS instance
          
            As mentioned previously the PE needs to perform VSI functionality (such
            as MAC address learning, flooding, and unicasting/broadcasting on a per
            Emulated VC basis). In addition to this, if the PE is required to
            recognize customerÆs VLANs and to provide isolation among these
            different VLANs (by using a separate broadcast domain per VLAN), then
            it also needs to have the capability of mapping customersÆ VLANs into
            unique VSI identifiers if each customer assigns his or her VLANs
            independently.
          
          2.3. Distributed-PE Model:
          
            Some of the main motivations behind a distributed-PE model include:
          
               . The ability to deploy a low-cost edge device at the customer
                 premise
               . Improving access bandwidth efficiency by multiplexing different
                 customer traffic (in contrast to a single-PE model located at the
                 Service ProviderÆs POP)
               . Improving access bandwidth efficiency by avoiding packet
                 replication on the access uplink for multicast/broadcast traffic
               . Improving system scalability Vs. single-PE functionality within
                 the customer premise in terms of a) number of BGP peers, b)
                 number of IGP peers, c) number of routes in the edge device, d)
                 number of MPLS labels in the edge device, e) number of MPLS or IP
                 tunnels among PEs (only a subset of routes and MPLS labels need
                 to installed in PE-CLEs; whereas, in a single-PE model all routes
                 and MPLS labels are installed in PEs û whether located at
                 customer sites or Service Provider POP)
          
            As mentioned previously, the most important data-plane functionality of
            a VPLS-capable PE is the ability to perform VSI functionality. In the
            case of the distribute-PE model, there are two cases that should be
          
          Sajassi, et al           Expires September 2002                [Page 10]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
            considered - either the PE-POP is capable of performing such
            functionality or it is not. If the PE-POP is capable of such
            functionality, then a true low-cost Ethernet switch based PE-CLE can be
            used.
          
            If the PE-POP doesnÆt have the ability to perform VSI functionality
            (e.g., it is a router), then this functionality needs to be performed
            by the PE-CLE. It should be noted that if a PE-CLE needs to perform
            such functionality, then it must have similar capability as MPLS/IP
            switches so as to support multiple virtual circuits per physical
            interface, and to treat these VCs as logical ports of a VSI, so that it
            can do flooding and broadcasting across these VCs per broadcast domain.
            As mentioned before, existing Ethernet switches may not perform these
            functions on a per VC basis. If their data-planes need to be modified
            for such functionality, then one can easily extend them to use MPLS
            labels or IP information as well.
          
            Based on the above discussion, we define two types of PE-CLE. The first
            type is an Ethernet-based PE-CLE which requires the PE-POP to perform
            VSI functionality. The second type is an MPLS/IP-based PE-CLE, which
            does VSI functionality and thus the PE-POP can be just an MPLS or an IP
            router.
          
            Based on which type of PE-CLE is used in a distributed-PE model,
            different sets of data-plane and control-plane functions are required
            at the PE-CLE and PE-POP. Another way of categorizing a distributed-PE
            model, is based on control plane functionality û more specifically in
            terms of Emulated signaling and auto-discovery. Based on these two
            functions, there can be four categories of distributed-PE models as
            follows:
          
               1. Emulated signaling and auto-discovery are both performed at the
                 PE-POP
               2. Emulated signaling at PE-CLE and auto-discovery at PE-POP
               3. Emulated signaling at PE-POP and auto-discovery at PE-CLE
               4. Emulated signaling and auto-discovery are both performed at the
                 PE-CLE
          
            The third category does not offer any real benefits in terms of system
            scalability and thus is not considered further. The fourth option can
            be considered as a degenerate case for a single-PE model since the PE-
            CLE is capable of terminating and signaling Emulated VCs and performing
            auto-discovery, it can basically perform all other functions required
            for a VPLS service. Therefore, only the first two options are examined
            further.
          
          
          Sajassi, et al           Expires September 2002                [Page 11]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
            As one might have guessed, a distributed-PE model based on Ethernet-
            based PE-CLE uses the first control-plane category (e.g., both Emulated
            signaling and auto-discovery are performed at the PE-POP). In contrast,
            a distributed model based on an MPLS/IP-based PE-CLE can use either the
            first or second control-plane category. As will be shown later in
            section 2.3.2, for an MPLS/IP-based PE-CLE, the second control-plane
            category offers additional benefits over the first one. An example of a
            distributed-PE model using an MPLS-based PE-CLE and the first control-
            plane category (e.g., Emulated signaling and auto-discovery both
            performed at the PE-POP) is described in [DTLS].
          
            In the following two sections, reference architectures for Ethernet-
            based and MPLS/IP-based PE-CLE are described and their relationship in
            terms of signaling/auto-discovery categorization is further examined.
          
          2.3.1. Ethernet-based PE-CLE
          
            A distributed-PE model with Ethernet-based PE-CLE provides a true low-
            cost edge device and at the same time it provides all the benefits of a
            distributed model in terms of motivational factors considered above.
            This model provides a natural migration in offering VPLS services for
            carriers with an existing Ethernet access network. An Ethernet-based
            PE-CLE not only provides access bandwidth efficiency by multiplexing
            different customers traffic but also it provides bandwidth efficiency
            by not replicating frames over its access uplink connected to the PE-
            POP (which is not the case for MPLS/IP-based PE-CLEs). Also, since in
            this model, the PE-POP performs both Emulated VC signaling and auto-
            discovery, all the signaling and routing scalability issues are
            addressed as well.
          
            Now lets examine the reference architecture for this model with respect
            to its components. Since Ethernet-based PE-CLEs donÆt support VSI
            functionality (e.g., MAC address learning, flooding, forwarding, etc.)
            based on virtual connections per broadcast domain, Emulated VCs must be
            terminated in the PE-POP. Also, since Emulated VCs signaling is
            performed at the PE-POP, the auto-discovery should also be performed
            there as well (auto-discovery is used for end-point identification in
            setting up Emulated VCs). This means that the Ethernet-based PE-CLE
            model fits very naturally into the first control-plane categorization
            of Emulated signaling and auto-discovery being performed at the PE-POP.
          
            Now that the Emulated VCs are terminated at the PE-POP and the VSIs are
            also located at the PE-POP, the question is how to get to the
            Attachment VCs that come into the PE-CLE (it should be noted that
            Emulated VCs are always terminated at the node that has the VSI
            functionality). There are two possible options:
          
          Sajassi, et al           Expires September 2002                [Page 12]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
          
               1. To tunnel the Attachment VCs from the PE-CLE to the PE-POP and do
                 further processing of the Attachment VCs at the PE-POP
               2. To extend the Attachment VCs from the PE-CLE into the PE-POP
                 using Extension VCs (e.g., by mapping Attachments VCs into
                 Extension VCs at the PE-CLE)
          
            The tunneling of the Attachment VCs can be performed by placing an
            outer .1q tag over a given customer traffic. This is also referred to
            as .1q-in-.1q encapsulation or for short QinQ. The provision of an
            Ethernet switch for this functionality is rather simple and a number of
            vendors currently provide such functionality in their Ethernet
            switches. The main advantage of this approach is that it requires no
            modifications to Ethernet switches that can support QinQ encapsulation
            and so these switches can be readily used as PE-CLEs. If the Service
            Provider is required to recognize customersÆ VLANs, then the PE-POP
            requires the capability of creating a unique VSI identifier per
            customerÆs VLAN by looking at both the outer and the inner .1q tags
            which is referred to as double-tag lookup. However, if the Service
            Provider is not required to recognize customersÆ VLANs, then no double-
            tag lookup functionality is needed at the PE-POP and the PE-POP can
            simply use the outer .1q tag as the VSI identifier since the outer tag
            has been assigned to ensure uniqueness at each PE-POP.
          
            The second option of extending the Attachment VCs into the PE-POP
            requires additional functionality in the PE-CLE that may not be
            currently available in Ethernet-based switches. This functionality
            allows the mapping of a customer VLAN (e.g., Attachment VC) into an
            internal VLAN (Extension VC), which is unique within the PE-CLE. This
            mapping is needed when separate VPLS instances need to be maintained
            per customer VLANs in order to provide isolation among customerÆs VLANs
            (e.g., customersÆ VLANs can overlap with each other and the Service
            Provider does not impose any restriction in customersÆ VLAN assignment
            per [VPLS-REQ]). It should be noted that this option is not needed if
            the Service Provider doesnÆt need to recognize customersÆ VLANs and
            thus the first option without double-tag lookup at the PE-POP is
            sufficient.
          
            In summary, in a distributed-PE model based on Ethernet-based PE-CLE,
            the VPLS functions are distributed between the PE-CLE and the PE-POP,
            with the following functions being performed at the PE-CLE:
          
               . Tunneling of Attachment VCs to the PE-POP OR;
               . Attachment VC termination and origination of Extension VCs toward
                 the PE-POP
          
          
          Sajassi, et al           Expires September 2002                [Page 13]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
            And the following VPLS functions are performed in the PE-POP:
          
               . Attachment Tunnels termination (if used)
               . Attachment VC termination OR Extension VC termination
               . Emulated VCs - signaling and termination
               . Emulated Tunnels û signaling and termination
               . Maintaining a VSI per VPLS instance
               . Auto-discovery
               . Auto-configuration
          
          
          2.3.2. MPLS/IP-based PE-CLE
          
            In cases where the PE-POP is an MPLS or an IP router without switching
            capability, the task of performing VSI functionality reside in the PE-
            CLE. The Emulated VCs can be setup at the PE-CLE using either MPLS or
            IP encapsulation - thus the name MPLS/IP-based PE-CLE.
          
            In this distributed-PE model, the Emulated VCs are terminated at the
            PE-CLE and the bridging functionality between a customerÆs Attachment
            VCs and the corresponding Emulated VCs are provided using a VSI per
            VPLS at the PE-CLE. Unlike the Ethernet-based PE-CLE, there is no need
            for Attachment tunnels or Extension VCs since the VSIs are located in
            the PE-CLEs.
          
            As mentioned previously, there are two types of control-plane options
            for this distributed-PE model: a) to have both Emulated signaling and
            Auto-discovery performed at the PE-POP and b) to have Emulated
            signaling at the PE-CLE and Auto-discovery at the PE-POP. It should be
            noted that in both options, the termination of the Emulated VCs is
            performed at the PE-CLE (Emulated VCs are terminated in the same node
            that has the VSI functionality). However, in the first option, the
            signaling of Emulated VCs is done among the PE-POPs and then the
            relevant information is conveyed to the PE-CLEs; whereas, in the second
            option, the signaling of Emulated VCs is done directly between the PE-
            CLEs (e.g., using directed LDP).
          
            The advantage of performing the signaling for Emulated VCs at the PE-
            CLE is that the Emulated VC gets setup as a single segment VC between
            the two PE-CLEs and furthermore, the Emulated VC is transparent to the
            PE-POP (e.g., only Emulated Tunnels would be visible to the PE-POPs and
            therefore, there is less overhead in terms of configuration, state
            information and processing for the PE-POP). However, if the signaling
            of Emulated VCs is performed at the PE-POP, then the Emulated VC will
            have multiple segments and multiple sets of labels (e.g., one set for
            each segment) need to be assigned as suggested by [DTLS] û one set of
          
          Sajassi, et al           Expires September 2002                [Page 14]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
            labels for the customer-facing segment at each PE and another set for
            the WAN/MAN segment.
          
            In addition to the configuration burden of maintaining multiple sets of
            labels, there is additional overhead for coordinating and installing
            routes among these different label sets. Because of the drawbacks of
            signaling of Emulated VCs at the PE-POP, this option is not considered
            any further and instead in section 10.3, the operational scenario for a
            single-segment Emulated VC (e.g., signaling of Emulated VCs at the PE-
            CLE) will be elaborated upon further.
          
            Based on the single-segment Emulated VC model (e.g., signaling of
            Emulated VCs to be done at the PE-CLE), the VPLS functions can be
            partitioned as follow with the following functions residing at the PE-
            CLE:
          
               . Attachment VCs termination
               . Emulated VCs û termination and signaling
               . Emulated Tunnels û signaling and termination
               . Maintaining a VSI per VPLS instance
          
            And the following functions residing at the PE-POP:
          
               . Auto-discovery
               . Auto-configuration
          
          
          3. Emulated VCs
          
            For a VPLS system, a set of Emulated VCs is used to connect different
            VSIs belonging to the same VPLS instance. Therefore, Emulated VCs are
            terminated at the nodes with VSI functionality.
          
            For a VPLS system over an MPLS network, the encapsulation of Emulated
            VCs are performed based on [L2ENCAP] and the corresponding signaling is
            performed based on [L2SIG].
          
            For a VPLS system over an IP network, the encapsulation and the
            signaling of the Emulated VCs can be performed based on [L2TPv3].
          
            We define two additional types of Emulated VCs for a VPLS system that
            are the counterparts of the Ethernet VCs defined in [L2SIG] for non-
            VPLS L2VPN:
          
            VC Type   Description
          
          
          Sajassi, et al           Expires September 2002                [Page 15]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
            0x000C    VLAN VPLS
            0x000D    Ethernet VPLS
          
            The reason for the definition of these two types of VCs is that the
            system operation with respect to transport of VLAN tagged and untagged
            frames, as well as handling of control packets and BPDUs, differs for
            each of these VC types.
          
            An Emulated VC, which is of type VLAN VPLS, corresponds to a single
            customerÆs VLAN. Therefore, for scenarios where the Service Provider
            needs to recognize customersÆ VLANs and provide a separate broadcast
            domain for different VLANs, then this Emulated VC type is used.
            Furthermore, only the frames with the specified tag are allowed to be
            transported over this Emulated VC. The Emulated VC of type VLAN VPLS
            corresponds to customersÆ UNI ports that are multiplexed (e.g., each
            UNI ports carries multiple Attachment VCs). A customer UNI port is a
            physical port between the customerÆs CE and the Service ProviderÆs PE.
          
            However, an Emulated VC of type Ethernet VPLS corresponds to all the
            traffic that comes through a customer UNI port û both VLAN tagged and
            untagged traffic including BPDUs. In other words, the Emulated VC acts
            as a pseudo wire corresponding to the customerÆs Ethernet port. This
            type of Emulated VC is used in applications where the Service Provider
            doesnÆt need to recognize customersÆ VLANs and thus it only provides a
            single broadcast domain (e.g., single VPLS) per customer or set of
            customerÆs ports. This type of Emulated VC can be also viewed as
            corresponding to customersÆ UNI ports that are not multiplexed (e.g.,
            each UNI ports corresponds to a single Attachment VC).
          
            In multiplex UNI scenarios for LAN bridging applications, not only
            isolation of customersÆ VLANs are needed (and different VLANs can go to
            different switches (CEs)) but also BPDUs packets need to be transported
            among these switches. For these applications, besides having a separate
            set of Emulated VCs of type VLAN VPLS for each customerÆs VLAN, another
            set of Emulated VCs of the same type is used for untagged frames
            including BPDUs. Therefore, in multiplex UNI applications, the untagged
            frames are transported over the Emulated VCs of type VLAN VPLS (e.g.,
            untagged frames can be considered as frames with special tags).
          
            It is important that these two types of Emulated VCs be differentiated
            and processed accordingly by the PEs involved in setting up a VPLS
            instance, since during the auto-configuration it provides a
            compatibility check between Attachment VCs and their corresponding
            Emulated VCs.
          
          
          
          Sajassi, et al           Expires September 2002                [Page 16]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
          4. Emulated Tunnels
          
            An Emulated Tunnel is used to carry Emulated VCs between two PEs and to
            make them transparent to the P nodes within the network. The general
            requirements for these tunnels are given in [L2ARCH]. The Emulated
            Tunnels are setup based on one of the existing methods specified for
            L3VPNs [L3ARCH] and are independent from L2VPN applications (e.g., if
            MPLS is used then tunnels can be either MPLS-TE using RSVP signaling or
            can be regular MPLS LSP using LDP signaling).
          
            In the reference architectures that we have defined for the single-PE
            and both of the distributed-PE models, the Emulated Tunnels are
            terminated at the same node where the Emulated VCs themselves are
            terminated. This means in the case of the distributed-PE model with
            Ethernet-based PE-CLE, the tunnels are terminated at the PE-POP; and in
            the case of the distributed-PE model with MPLS/IP-based PE-CLE, the
            tunnels are terminated at the PE-CLE.
          
          5. Attachment Tunnels
          
            The Attachment tunnels are used only for the distributed-PE model and
            more specifically with Ethernet-based PE-CLEs. Attachment tunnels can
            be between PE-CLEs and PE-POPs that are either directly connected or
            via a .1q access network. In the later case, these tunnels are
            transparent to the .1q access network and are treated just as regular
            VLANs with slightly larger payloads.
          
            Attachment tunnels are formed by placing an outer .1q tag in front of
            the frames (either tagged or untagged) entering a PE-CLE via a customer
            UNI port. This outer tag is referred to as a PE-VLAN (Provider Edge
            VLAN). In the case of a non-multiplexed UNI, the PE-VLAN is the same
            for all the ports of a customer belonging to the same VPLS instance,
            and in the case of a multiplexed UNI, the PE-VLAN is the same for all
            the ports of a customer that share one or more VPLS instances.
          
            The uniqueness of the PE-VLAN needs to be guaranteed within a PE-POP
            domain since there are multiple PE-CLEs per PE-POP and PE-VLANs are
            used to differentiate between different customers.  In other words, PE-
            VLAN is a local parameter that gets shared between PE-POP and its
            associated PE-CLEs and it is not transported over the Emulated VCs û
            instead it can be derived from the Emulated VCs associated with that
            VPLS instance.
          
            In the case of a multiplexed UNI, an Attachment tunnel is used to
            transport all the customerÆs VLANs (e.g., Attachment VCs) to the PE-POP
            and at the PE-POP both the PE-VLAN and CE-VLAN are used together as a
          
          Sajassi, et al           Expires September 2002                [Page 17]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
            VSI identifier (e.g., the double-tag lookup mechanism described
            previously). However, for a non-multiplex UNI, the Attachment tunnel
            degenerates into carrying only a single Attachment VC associated with
            that UNI and at the PE-POP only the PE-VLAN is used as a VSI
            identifier.
          
          
          5.1. Encapsulation
          
            The following shows the encapsulation format for customer tagged frames
            as they are carried between PE-CLE and PE-POP. The encapsulation format
            for customer untagged frames is the same as with 802.1q.
          
          
                0                   1                   2                   3
                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |                   MAC Dest. Address                           |
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |       MAC DA cont.            |   MAC Source Address          |
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |                        MAC SA cont.                           |
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |     Ether Type = 0x8100       |      PE-VLAN          |PE .1p |
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |     Ether Type = 0x8100       |      CE-VLAN          |CE .1p |
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |      Ether Type / Length      |          Payload              |
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |                           Payload                             |
               |                              "                                |
               |                              "                                |
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          
          
          
          5.2. Signaling
          
            To configure an Attachment tunnel between the PE-CLE and the PE-POP,
            the minimum piece of information that needs to be passed to the PE-CLE
            is a) Attachment tunnel ID or PE-VLAN and b) customer-ID/VPN-ID
            associated with the Attachment tunnel ID or PE-VLAN. The PE-CLE, upon
            receiving the message that contains the association between PE-VLAN and
            customer-ID/VPN-ID, looks for which of its ports are configured for
            that customer-ID/VPN-ID and then applies the PE-VLAN ID to the
            respective port(s).
          
          Sajassi, et al           Expires September 2002                [Page 18]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
          
            If in addition to the Attachment tunnel configuration, the PE-CLEÆs
            port(s) configuration is also done through the PE-POP, then the PE-POP
            can resolve the association between PE-VLAN and the associated port and
            thus sending the PE-VLAN + port-ID information along with port
            configuration information to the PE-CLE (e.g., PE-CLE does not need to
            receive customer-ID/VPN-ID info). It should be noted that if the PE-
            CLEÆs port configuration is done via the PE-POP, then this shall
            include all relevant configuration information including QoS parameters
            and thus the signaling protocol shall support it as well.
          
            Signaling of the Attachment Tunnels can be accomplished through
            extensions to an existing protocol (e.g., VLAN Trunking Protocol) and
            these extensions would only require software changes to the Ethernet-
            based PE-CLE (no hardware/ASIC changes are required). This signaling
            protocol along with its extensions will be specified in the future.
          
          6. Extension VCs
          
            Extension VCs are used in conjunction with Ethernet-based PE-CLE in the
            distributed-PE model for multiplexed UNI ports and they are used in
            lieu of the Attachment tunnels. Since Extension VCs are only used for
            multiplexed UNI ports, the PE-CLE is required to have VLAN-mapping
            capability, which may not be currently available in standard Ethernet
            switches. This capability is needed in order to map overlapping VLANs
            of different customers into unique internal VLANs (PE-VLANs) so that at
            the PE-POP, these PE-VLANs can be used as a VSI identifier.
          
          
          6.1. Encapsulation
          
            Encapsulation format for Extension VCs is exactly the same as 802.1q
            since only customersÆ VLANs are mapped to PE-VLANs and everything else
            remains the same.
          
          
          6.2. Signaling
          
            Similar to the Attachment tunnels, a signaling protocol can be used to
            configure the Extension VCs between the PE-CLE and the PE-POP. At the
            minimum, the signaling protocol needs to convey the PE-VLAN and the
            associated VPN-ID to the PE-CLE. The PE-CLE uses the VPN-ID to identify
            which VLAN under which port needs to be mapped to a given PE-VLAN.
          
            Again similar to the Attachment tunnels, if besides configuration of
            the Extension VCs, PE-CLEÆs ports and VLANs also need to be configured
          
          Sajassi, et al           Expires September 2002                [Page 19]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
            via the PE-POP, then only PE-VLAN information needs to be passed to PE-
            CLE along with customer port and VLAN configuration (e.g., no need to
            pass VPN-ID information to the PE-CLE since the PE-POP can already
            resolve the association between PE-VLAN and customer port-ID + VLAN).
          
            Signaling of the Extension VCs can also be accomplished through
            extensions to an existing protocol (e.g., VLAN Trunking Protocol) and
            these extensions would only require software changes to the Ethernet-
            based PE-CLE. This signaling protocol along with its extensions will be
            specified in the future.
          
          7. Virtual Switch Instance
          
            As mentioned previously, for a customerÆs VPLS, there exist a VSI in
            each PE associated with that VPLS. The VSI, as its name implies, is a
            virtual switch that can have logical ports (e.g., virtual circuits) as
            its interfaces. Therefore, it has the ability to do regular
            bridge/switch functionality such as MAC address learning/aging,
            flooding, forwarding (unicasting, multicasting/broadcasting), and
            running STP (if needed) per broadcast domain but based on its logical
            ports (regular Ethernet switches may only perform these functions on
            their physical ports).
          
            In the case of distributed-PE models, VSIs can be located either in PE-
            CLEs or PE-POPs based on their capabilities as described previously.
            VSIs of a VPLS are connected to each other through Emulated VCs, which
            act as pseudo wires. If all the VSIs are connected directly with each
            other through a full mesh of Emulated VCs, then one can avoid running
            STP in the PEs by disabling packet forwarding between any two Emulated
            VCs in a VSI (e.g., packets arriving from Emulated VCs have to go out
            on Attachment VCs). This is referred to as Split Horizon in [TLS].
            However, if the VSIs are not directly connected with each other, then
            loops can exist and other means for loop prevention shall be devised.
            The use of STP in such scenarios is for further study. It should be
            noted that if STP were used for loop prevention between the PEs, then
            it would be different from the customersÆ STPs (e.g., customersÆ BPDUs
            are tunneled transparently through the network).
          
            Although, customersÆ BPDUs are passed transparently through the
            providerÆs network, there can exist certain scenarios that would
            require monitoring of the customerÆs BPDUs and taking the appropriate
            action. For example, if a customer is running 802.1w and there is a
            change in their network topology, then the corresponding VSI upon
            receiving a Topology Change Notification (TCN) shall flush the MAC
            addresses learned from all other ports except the one on which it
            received the TCN. This processing is needed in order to achieve
          
          Sajassi, et al           Expires September 2002                [Page 20]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
            convergence time in the order of milliseconds provided by 802.1w. Also,
            in some other scenarios where 802.1w is not used, monitoring of
            customersÆ BPDUs may be needed for accelerating aging timeouts of all
            portsÆ MAC addresses upon receiving a TCN.
          
          
          8. Auto Discovery
          
            Auto-discovery is used to discover all the PEs associated with a VPLS
            instance for setting up Emulated VCs among the corresponding VSIs.
            There are two basic mechanisms for auto-discovery. One is based on
            Directory Services and it is described in [DIR-AUTO] and the other is
            base on BGP that is first described as part of [L3ARCH] and has been
            extended and generalized in [BGP-AUTO].
          
            In Directory-based auto-discovery, IP addresses of all participating
            PEs for a VPLS are added as records under the VPN-ID (e.g., domain
            name) in the directory. When a new Attachment VC is configured, it is
            configured with a VPN-ID and the PE queries the directory for the IP
            addresses of all other PEs for that VPLS and then tries to establish an
            Emulated VC (if one doesnÆt already exist) between its VSI and other
            VSIs within the VPLS system.
          
            In BGP-based auto-discovery, similar to the Directory-based scheme, the
            VPN-ID is associated with Attachment VCs when they are configured;
            however, in contrast with the Directory-based approach, the IP
            addresses of the member PEs need not to be entered in another server.
            Instead, each PE running the BGP protocol distributes its VPN-ID
            information along with its IP address to all other PEs through MP-BGP
            Network Layer Reachability Information (NLRI).
          
            In the case of the distributed-PE model (either Ethernet-based or
            MPLS/IP-based), the Directory query or BGP protocol is performed by the
            PE-POP. Furthermore, if the distributed-PE model is MPLS/IP-based, then
            the discovered information (e.g., IP addresses of the peer PEs) for a
            VPLS need to be conveyed to the PE-CLE since Emulated VCs are set up
            from there (e.g., single-segment Emulated VC between two PE-CLEs).
          
          
          9. Auto Configuration
          
            Auto-configuration is used to tie all the pieces of a VPLS together.
            Sometimes auto-discovery and auto-configuration are used loosely and in
            lieu of each other; however, we make a clear distinction between them
            in order to clearly define the functionality of each. Auto-discovery is
            only limited to member discovery of a VPLS instance (e.g., IP addresses
          
          Sajassi, et al           Expires September 2002                [Page 21]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
            of all the PEs participating in a VPLS). However, auto-configuration
            uses some components of a VPLS (including auto-discovery) as a
            triggering mechanism for configuring other components of that VPLS.
          
            As mentioned previously a VPLS can be defined by a quintuple set as
            follows: <ingress Attachment VCs, ingress VSIs, Emulated VCs, egress
            VSIs, and egress Attachment VCs>. When an Attachment VC is configured
            and becomes active, auto-configuration associates the Attachment VC to
            a VSI for that VPLS, and uses it to trigger auto-discovery for finding
            member PEs. Upon discovery of the member PEs, the auto-configuration
            uses the information to trigger configuration of Emulated VCs if they
            are not already setup by previous triggers.
          
            Since an Emulated VC is a full-duplex circuit and it consists of two
            uni-directional circuits, when configuring an Emulated VC, both
            circuits need to be configured. We use the single-sided signaling
            mechanism for L2VPNs as described in [SS-SIG] for this purpose, which
            basically means the setup of the return leg is triggered by the setup
            of the forward leg. The signaling of the Emulated VC also triggers the
            activation of the egress Attachment VC if it is not already activated.
            Auto-discovery in conjunction with single-sided signaling helps to
            confine the configuration changes for adding a new customer site to a
            single PE. Therefore, upon configuring the Attachment VC associated
            with the new customer site on the corresponding PE, the configuration
            of all other pieces is done automatically as described above. It should
            be noted that in the case of Directory-based auto-discovery, the
            Directory server might also need to be configured (for adding the IP
            address of the PE associated with the new site as a new record under
            the domain name if it doesnÆt exist).
          
            In the case of a distributed-PE model where the configuration of
            Attachment VCs is performed at the PE-POP, then auto-configuration
            causes the configuration of an Attachment VC to also trigger the
            signaling to the PE-CLE. In the case of an Ethernet-based PE-CLE, the
            signaling is for configuring Attachment tunnels or Extension VCs at the
            PE-CLE as well as configuring the Attachment VCs at the PE-CLE. In the
            case of an MPLS/IP-based PE-CLE, the signaling is for conveying the
            VPLS membership information (e.g., IP addresses of associated PEs) to
            the PE-CLE as well as configuring the Attachment VCs at the PE-CLE.
          
          
          10. System Operation
          
            In the following sections, we describe the system operation for
            different VPLS system architectures in terms of control and data plane
            operation.
          
          Sajassi, et al           Expires September 2002                [Page 22]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
          
          10.1. Single-PE
          
            In setting up a VPLS for a customer, first different components of the
            VPLS (Attachment VCs, Emulated VCs, and VSIs) need to be configured and
            hooked up to each other and next forwarding information needs to be
            installed in the VSIs. The former task is done within the domain of the
            control plane by use of different signaling protocols and auto-
            configuration. The later task of installing forwarding information is
            done solely in the data plane by use of MAC address learning and
            flooding (this is in contrast to L3VPN where control plane is used for
            installing prefix information).
          
            Thus, a VPLS can be considered a collection of virtual switches
            connected with each other and to customersÆ devices via logical ports
            and the control plane is used for setting up these virtual switches and
            connecting them with each other and the customersÆ devices.
          
            Lets look at the control plane operation for a VPLS in more details.
            Upon configuring an Attachment circuit at a PE (for connection to a new
            customerÆs site), the auto-configuration mechanism on that PE triggers
            auto-discovery (either using BGP or DNS) to discover other PEs
            participating in this VPLS. Then the PE tries to setup an Emulated VC
            between its VSI and every other VSI of the discovered PEs if one
            already doesnÆt exist. Once the setup of the Emulated VCs is completed,
            then the new Attachment VC is connected to the VPLS and the new CE can
            participate in data plane functionality.
          
            The operation of the data plane is the same as for regular Ethernet
            switches except that the VSIs have the capability to perform Ethernet
            functionality (MAC address learning, flooding, forwarding, and so on)
            based on logical ports as mentioned previously. Once the VSIs learn the
            MAC addresses of the new CE and associated them with the logical ports
            over which they come from, then they perform Layer-2 forwarding based
            on these MAC addresses.
          
          
          10.2. Distributed-PE with Ethernet-based PE-CLE
          
            A VPLS in this model can be considered as a collection of virtual
            switches connected with each other via Emulated VCs and connected to
            customersÆ devices via Attachment VCs and either Attachment Tunnels or
            Extension VCs. Therefore, the network-side of the VSI in this case is
            the same as the one for single-PE model, and configuration and
            operation of Emulated VCs are the same as the single-PE model and are
            not considered further.
          
          Sajassi, et al           Expires September 2002                [Page 23]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
          
            The customer-facing side of the VSI is different and it is connected to
            customersÆ devices via Attachment VCs in conjunction with Extension VCs
            or Attachment tunnels. As described previously, when configuring
            Attachment VCs via the PE-POP, the IDs for Attachment Tunnels or
            Extension VCs are allocated by the PE-POP and conveyed to the PE-CLEs
            via the appropriate signaling along with Attachment VCs configuration
            information. The PE-CLE in turn uses this information to setup its end
            of the Attachment Tunnels or Extension VCs as well as setting up the
            Attachment VCs to the CEs. Once all the pieces are setup, the VPLS is
            ready for data-plane operation.
          
            In case of the Attachment Tunnels for non-multiplexed UNI ports, all
            the customerÆs traffic on a port (either tagged or untagged) gets sent
            through the Attachment tunnel to the PE-POP and at the PE-POP based on
            the tunnel ID, the corresponding VSI associated with that VPLS is
            selected and the traffic is switched through. It should be noted that
            in the case of a non-multiplexed UNI port, the VPLS and in turn the
            associated VSIs are transparent to customerÆs VLANs. However, for the
            multiplexed UNI ports, the VPLS is associated with a given customerÆs
            VLAN and thus it is important to examine the customerÆs VLANs (e.g.,
            Attachment VCs) at the PE-POP. Since customersÆ VLANs can overlap with
            each other, in order to uniquely identify them, both Attachment Tunnel
            ID and Attachment VC ID needs to be looked at together (e.g., double-
            tag lookup) to identify the corresponding VSI. After VSI
            identification, the packets are forwarded to their destinations based
            on their destination MAC address. It should be noted that when
            Attachment Tunnels are used for multiplexed ports, the PE-CLE is
            oblivious to the Attachment VCs carried inside these tunnels.
            Therefore, if there are more than one customer site connected to the
            same PE-CLE and these sites use overlapping MAC addresses across
            different VLANs, then these VLANs are not isolated from one another at
            the PE-CLE. Although such situations are rare, itÆs worth mentioning
            that there are solutions for this scenario such as the use of sticky
            MAC addresses; however, because of the rarity of this scenario, they
            will not be discussed here.
          
            If Extension VCs are used in lieu of Attachment tunnels for multiplexed
            UNI ports, then the Extension VC ID can be used directly to identify
            the corresponding VSI. However, as mentioned previously, in order to
            use the Extension VCs, the PE-CLE must have the ability to map between
            the Attachment VCs and the Extension VCs at the ingress port. This
            mapping is needed in order to map overlapping customersÆ VLAN IDs into
            unique Extension VCs for proper identification of the VSIs. Once a VSI
            is selected, then packet forwarding is performed as before.
          
          
          Sajassi, et al           Expires September 2002                [Page 24]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
          
          10.3. Distributed-PE with MPLS/IP-based PE-CLE
          
            In this model virtual switches can be considered connected with each
            other via longer logical ports (Emulated VCs) that span across multiple
            Service Provider devices (PE-CLEs and PE-POPs). In the previous cases,
            an Emulated VC was either between two PEs or between two PE-POPs.
            However, in this case an Emulated VC is between two PE-CLEs and it
            passes through the PE-POPs transparently. The difference between this
            distributed-PE model and the single-PE model is primarily in the
            control plane and once the Emulated VCs are setup among the VSIs, then
            the data-plane operation is identical to the one for the single-PE
            model (whereas, the same thing can not be said for the distributed-PE
            model with Ethernet-based PE-CLE).
          
            Since Emulated VCsÆ setup is originated from the PE-CLE, the tunneling
            of these VCs also needs to be originated from the PE-CLE. As discussed
            before, a signaling protocol is used to pass the IP addresses of other
            PE-CLEs discovered via the auto-discovery mechanism from the PE-POP to
            the PE-CLE. Upon receiving the IP addresses, the PE-CLE installs them
            in its routing table and then uses them as /32 prefixes to establish
            the tunnels (for Emulated VCs). The tunnel establishment is done
            through one of the existing methods (e.g., downstream unsolicited LDP,
            RSVP-TE, and so on). When tunnels are established, then a directed LDP
            session is setup for Emulated VC signaling between this PE-CLE and the
            other discovered PE-CLEs for that VPLS. It should also be noted that if
            the configuration of the PE-CLE is done through the PE-POP, then the
            PE-POP can also be configured with the IP address of the PE-CLE and
            convey this IP address to the PE-CLE via the signaling protocol;
            however, if the Attachment VCs in the PE-CLE are not configured through
            the PE-POP, then a simple IGP protocol such as RIP can be used to pass
            the IP address of the PE-CLE to the PE-POP.
          
            Once the Attachment VCs are configured and the Emulated VCs are setup
            at the PE-CLE to connect the VSI to other VSIs, then the VPLS is ready
            for its data-plane operation and furthermore its data-plane operates
            exactly as the one for the single-PE model.
          
          
          11. Security Considerations
          
            The security aspects of each VPLS architecture will be discussed at a
            later time.
          
          
          
          Sajassi, et al           Expires September 2002                [Page 25]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
          12. Acknowledgements
          
            The authors would like to thank Michael Wu, Norm Finn, Eric Rosen, Eric
            Voit, Suran DeSilva, and Anush Elangovan for their helpful discussions
            and feedbacks.
          
          
          13. References
          
            [L2ARCH] "An Architecture for L2VPNs", Eric Rosen, draft-rosen-ppvpn-
            l2vpn-00.txt, May 2001
          
            [VPLS-REQ] ôRequirements for Virtual Private LAN Services (VPLS)ö,
            Waldemar Augustyn,  draft-augustyn-vpls-requirements-00.txt, April 2002
          
            [L3ARCH] ôBGP/MPLS VPNsö, Rosen, et. al., RFC2547
          
            [PPVPN-FRWK] "A Framework for Provider Provisioned Virtual Private
            Networks", R. Callon, draft-ietf-ppvpn-frammework-03.txt, January 2002
          
            [DTLS] "Decoupled Virtual Private LAN Services", K. Kompella, draft-
            kompella-ppvpn-dtls-01.txt, May 2002
          
            [L2ENCAPS] "Encapsulation Methods for Transport of Layer 2 Frames
            Over MPLS", Martini, et. al., draft-martini-l2circuit-encap-mpls-
            01.txt, 2/01.
          
            [L2SIG] "Transport of Layer 2 Frames Over MPLS", Martini, et. al.,
            draft-martini-l2circuit-trans-mpls-05.txt, 2/01.
          
            [L2TPv3] ôLayer Two Tunneling Protocol æL2TPÆ, draft-ietf-l2tpext-l2tp-
            base-01.txt
          
            [TLS] "Transparent LAN Service over MPLS", M. Lasserre, et. al., draft-
            lasserre-vkompella-ppvpn-tls-00.txt, November 2001
          
            [DIR-AUTO] " DNS/LDP Based VPLS", Juha Heinanen, draft-heinanen-dns-
            ldp-vpls-00.txt, January 2002
          
            [AUTO] "Using BGP as an Auto-Discovery Mechanism for Network-based
            VPNs", Ould-Brahim, et. al., draft-ouldbrahim-bgpvpn-auto-01.txt, 3/01
          
            [SS-SIG] "Single-sided Signaling for L2VPNs", Eric Rosen, draft-rosen-
            ppvpn-l2-signaling-00.txt, 3/01
          
          
          
          Sajassi, et al           Expires September 2002                [Page 26]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
          14. Authors' Addresses
          
            Ali Sajassi
            Cisco Systems, Inc.
            170 West Tasman Drive
            San Jose, CA  95134
            Email: sajassi@cisco.com
          
          
            Dan Lee
            Cisco Systems, Inc.
            170 West Tasman Drive
            San Jose, CA  95134
          
          
            Jim Guichard
            Cisco Systems, Inc.
            250 Apollo Drive
            Chelmsford, MA 01824
            Email: jguichar@cisco.com
          
          
          
          15. Intellectual Property Considerations
          
            Cisco Systems may seek patent or other intellectual property protection
            for some or 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 Cisco Systems, Cisco Systems intends to
            disclose those patents and license them on non-discriminatory terms.
          
          
          16. Full Copyright Statement
          
            Copyright (C) The Internet Society (2001).  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
          
          Sajassi, et al           Expires September 2002                [Page 27]


            Internet Draft   draft-sajassi-vpls-architectures-00.txt  February 2002
          
            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.
          
            This document and the information contained herein is provided on an
            ôAS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
            TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
            NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
            NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
            FITNESS FOR A PARTICULAR PURPOSE.
          
          
          Sajassi, et al           Expires September 2002                [Page 28]
          

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/