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 . 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| | | +----+ PE1 PE2 +----+ +-------+ +-------+ +----+ |CE1 | | +---+ | | +---+ | | CE2| | |------+-|VSI+-+----------------------+-|VSI+-+-----+ | +----+ | +---+ | | +|--+ | +----+ +-------+ +--|----+ | +----+ +----------+ CE3| | | +----+ 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: . 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]