Provider Provisioned VPN WG Dinesh Mohan Vasile Radoaca Nortel Networks Internet Draft draft-chen-ppvpn-dvpls-compare-01.txt Expiration Date: April 2003 November 2002 VPLS solutions: Commonalities and Differences 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 obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The scope of this draft is regarding the VPLS solutions - it describes commonalities and differences among different VPLS solutions in terms of distributed and non-distributed access topologies. The metrics used for comparison are derived from [L2VPN- METRICS] and [L2VPN-FRMK]. The current VPLS solutions that are taken in consideration are: GVPLS [GVPLS], DTLS [DTLS], and VPLS/HVPLS [VPLS-MPLS]. This list of solutions is not exhaustive; other solutions may be taken into account in future versions of this draft. Table of Contents Status of this Memo................................................1 Chen, et. al Expires: April 2003 [Page 1] Internet Draft draft-chen-ppvpn-dvpls-compare-01.txt November 2002 Abstract...........................................................1 1. Conventions used in this document...............................2 2. Introduction....................................................2 2.1 Terminology....................................................3 2.2 Comparison Criteria............................................3 3. Functions to support VPLS.......................................4 3.1 Control Plane functions........................................5 3.2 Forwarding Plane functions.....................................5 4. Control Plane Architecture......................................5 4.1 Auto-discovery and Signaling: Core and Access..................5 4.1.1 Core Network.................................................5 4.1.2 Access Network...............................................7 4.2 Tunnel Architecture "Core"/öAccessö Devices....................8 4.2.1 Core Network.................................................8 4.2.2 Access Network...............................................9 4.3 Information Model/End-Point data model........................10 5. Forwarding Plane Architecture..................................11 5.1 VSI...........................................................12 5.1.1 VSI-u.......................................................12 5.1.2 VSI-n.......................................................13 5.2 Customer packet encapsulation [see above section].............13 5.3 Packet replication/Flooding...................................14 6. Other Comparison Metrics.......................................15 6.1 Scalability...................................................15 6.2 Provisioning cost/complexity..................................16 6.3 Integration and migration (Interworking)......................16 6.4 Resiliency....................................................16 6.5 OAM...........................................................16 7. Security Considerations........................................16 8. References.....................................................17 9. Acknowledgments................................................17 10. Author's Addresses............................................17 Full Copyright Statement..........................................18 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 2. Introduction The objective of this draft is to provide a set of tools to the vendors and Service Providers to better understand different solutions, and their applicability against different requirements. Chen, et. al Expires: April 2003 [Page 2] Internet Draft draft-chen-ppvpn-dvpls-compare-01.txt November 2002 The current VPLS solutions that are taken in consideration are: GVPLS [GVPLS], DTLS [DTLS], and VPLS/HVPLS [VPLS-MPLS]. This list of solutions is not exhaustive; other solutions may be taken into account in future versions of this draft. This draft is not an attempt to endorse any single solution over the other solutions. Differences in customer requirements may allow for different solutions to be designed and implemented. However, from standard point of view, it is acknowledged that solutions space must be limited to one or few solutions. In case of more than one solution, interoperability may become a key requirement. 2.1 Terminology The terminology used in the draft is mostly derived from the [L2VPN- FRMK], [GVPLS], [DTLS], [VPLS-MPLS]. EndPoint is used to represents the destination where a customer packet is to be forwarded, or from where the packet enters as the originating source. 2.2 Comparison Criteria Some comparison criteria taken in considerations for this draft are: - Control plane aspects - Data plane aspects - Management plane aspects - Extensions to standard protocols - Provisioning and auto-discovery - Flexibility and interoperability - Supporting legacy network infrastructure in terms of network devices and protocols - Inter-working and supporting add-value services [IP VPN] - Scalability in terms of VPNs, Multicast traffic, and EndPoints. VPLS solutions are aimed towards providing connectivity across geographically distributed customer sites across MAN/WAN networks. Some objectives have been to retain key value of simplicity of Ethernet as technology of choice for enterprise networks, improve customer MAC address management on the provider core network and reduce the number of control and transport connections needed between service aware devices by introducing levels in the network. Recent debate has also pointed to a need to clarify the VPLS model that these solutions provide. VPLS can be viewed as an emulation of bridging and/or emulation of LAN segment. While LAN segment emulation provides connectivity across geographically distributed customer sites, it does not mandate the service provider network to implement/participate in enterprise STP [IEEE 802.1g] etc. which is required by [IEEE 802.1D] bridge emulation. While the former model has been followed by many proposed solutions in the PPVPN WG, the latter model represents a view of the IEEE 802.1. This draft steers Chen, et. al Expires: April 2003 [Page 3] Internet Draft draft-chen-ppvpn-dvpls-compare-01.txt November 2002 clear of this debate and is an attempt to describe commonalities and differences among the different proposed VPLS solutions. Proposed solutions considered in this draft include [GVPLS], which supports both distributed and non-distributed VPLS and is based on [LPE-ARCH] architecture, [VPLS-MPLS], which supports non-distributed VPLS including hierarchal architecture, and [DTLS], which supports distributed VPLS architecture. These solutions are aimed towards improving customer MAC address management on the provider core network and reducing the number of control and transport connections needed between service aware devices by introducing levels in the network. This draft references the [L2VPN-METRICS] to identify the metrics and attributes to describes commonalities and differences among distributed and non-distributed (including hierarchical) VPLS solutions. Updates to the proposed solutions in future versions of the architecture/solutions may require this draft to be updated. As discussed later, the differences among the three solutions are not critical and this draft could facilitate discussion towards merging and enhancing the current distributed/hierarchical VPLS proposals. Figure 1 illustrates a general distributed/hierarchical VPLS architecture. +------+ +------+ +----------------+ +------+ +------+ |"Edge"| û |"Core"| û |Backbone Network| û |"Core"| û |"Edge"| +------+ +------+ +----------------+ +------+ +------+ Figure 1 Typically customer LANs across different sites will connect through the ôEdgeö devices in a Service Provider Network. These are typically identified as Provider Edge (PE) as described in [L2VPN-FRMK]. In distributed and hierarchal architectures, the PE can be seen as consisting of ôEdgeö (U-PE) and ôCoreö (N-PE) devices, where ôEdgeö devices are user facing devices and ôCoreö devices are core/backbone network facing devices. This document will first describe the functions required to support VPLS. In section 4, a description of the commonalities and differences among the solutions in the control plane will be given. In section 5, a description of the commonalities and differences among the solutions in the forwarding plane will be given. 3. Functions to support VPLS Some functions needed to create VPLS are described in Section 3.1 and 3.2. [LPE-ARCH] describes most of these functions in more detail. Chen, et. al Expires: April 2003 [Page 4] Internet Draft draft-chen-ppvpn-dvpls-compare-01.txt November 2002 3.1 Control Plane functions o VPLS membership auto-discovery o Transport tunnel signaling o Service label signaling o VPLS Configurations 3.2 Forwarding Plane functions o MAC learning o Customer VLAN processing o Customer traffic prioritizing, policing, and shaping o Customer packet encapsulation o Packet replication/Flooding o Service label de-multiplexing 4. Control Plane Architecture 4.1 Auto-discovery and Signaling: Core and Access 4.1.1 Core Network This focuses on auto-discovery and signaling mechanisms between PEs, for a non-distributed model, or among N-PEs, for a distributed model. Auto-discovery refers to the ability to automatically learn: 1) topology, and 2) VPN membership. Topology refers to: 1) other PEs or N-PEs that belong to same VPLS instance, 2) local and remote U-PEs (for a distributed model) that belong to same VPLS instance. For example in context of a N-PE X, ôlocalö refers to U-PEs connected to X [directly or indirectly (e.g. through a Ethernet Access Network)] while ôremoteö refers to U-PEs connected to other N-PEs. VPN membership refers to: endpoints on service provider network where VPN service instance is provisioned. Auto-discovery can be facilitated by control mechanisms. When auto- discovery is not supported, the information needs to be provisioned. Signaling mechanisms allow PEs (in non-distributed model) or U-PEs and N-PEs (in distributed model) to establish service multiplexed PWs over tunnels connecting them to realize VPLS over SP network. This allows the service label (also called as demultiplexor) for PWs to be distributed across the SP devices to instantiate VPLS. The auto-discovery and service label signaling mechanisms can be point-to-point and point-to-multipoint. Point-to-point control mechanism implies that every device has a control session to all its peer devices. An example of point-to-point mechanism is targeted LDP. Point-to-Multipoint control mechanism implies that a device may Chen, et. al Expires: April 2003 [Page 5] Internet Draft draft-chen-ppvpn-dvpls-compare-01.txt November 2002 have only a few control sessions to some entity. The entity then relays the information to all the other peers of that device. An example of point-to-multipoint mechanism is BGP with Route Reflectors (RR). Note: In the tables, N-PE is same as a PE when referring to a non- distributed model/deployment of the VPLS solution. This table highlights the information on an N-PE/PE. GVPLS DTLS VPLS/HVPLS Auto-discovery Topology Remote N-PE Provisioned; Supported by BGP Provisioned. devices Enable also the BGP and LDP. Auto-discovery Membership VPLS end- Local end-points Local end-points Transparent points are provisioned. are provisioned. through VSI-u Remote end-point Remote end-point (Virtual are auto- are auto- Bridge) discovered using discovered using LDP or BGP BGP using Route Targets Signaling Support for LDP Support for BGP Support for Mechanism and BGP LDP Signaling <= n, where n is <= n, where n is =N, where n is Control number of other number of other number of Sessions N-PEs. N-PEs. other N-PEs. For full-mesh For full-mesh Full-mesh, between N-PEs, between N-PEs, number for N- number of control number of control PE is same as sessions on an N- sessions on an N- number of PE is same as PE is same as other N-PEs number of other number of other belonging to N-PE belonging to N-PE belonging to same VPLS. same VPLS. For same VPLS. For partial mesh, partial mesh, e.g. using RR, e.g. using RR, number of control number of control sessions may be sessions may be less. less. Supporting Yes, when using Yes (BGP) Unspecified auto-discovery BGP or LDP for via signaling both topology and [only one membership. (In phase process] GVPSL with Control Word, the Auto-discovery of membership and signaling happen Chen, et. al Expires: April 2003 [Page 6] Internet Draft draft-chen-ppvpn-dvpls-compare-01.txt November 2002 at the same time) 4.1.2 Access Network This section focuses on the auto-discovery and signaling mechanisms between N-PE and its local U-PEs. This table is not applicable to non-distributed solutions. GVPLS DTLS VPLS/HVPLS Auto- discovery Topology Local and Local U-PE Local U-PE is Local U-PE remote U- information is provisioned. information PE devices provisioned on Remote U-PE is N-PE and information is provisioned. distributed to learned by BGP. Remote U-PE the local access Prior knowledge is network via LDP. about remote U- transparent. Remote is PE is assumed. learned by BGP or LDP Membership End-points Local membership Local membership Local provisioned on provisioned on membership N-PE and N-PE and provisioned signaled to U- signaled to on U-PE and PE. Remote local U-PE. signaled to membership Remote N-PE. Remote signaled from N- membership membership PE to U-PE. signaled from N- information PE to local U- limited to PE. N-PE. Signaling LDP Unspecified LDP Mechanism between U- PE and N- PE. Signaling At least one At least one At least one Control between N-PE and between N-PE and between N-PE Sessions each local U-PE each local U-PE and each local U-PE Is auto- Yes (LDP) Unspecified Yes (LDP) discovery and signaling integrated Chen, et. al Expires: April 2003 [Page 7] Internet Draft draft-chen-ppvpn-dvpls-compare-01.txt November 2002 End-to-End control sessions refer to control sessions between devices hosting the customer demarcation, e.g. U-PE for distributed model while PE for non-distributed models. It is also possible for N-PE devices to host the customer demarcation, when the customer sites are connected directly to an N-PE in a distributed model. N-PE device may serve as signaling mediators between its subtending U-PE devices and rest of the provider network. The following table captures the attributes of end-to-end control architecture from auto-discovery and signaling point of view. GVPLS DTLS VPLS/HVPLS End to End Split between U- Split between U- Split between U-PE control PE and N-PE, PE and N-PE, and N-PE, i.e. U- Session i.e. U-PE-to-U- i.e. U-PE-to-U- PE-to-U-PE control PE control PE control sessions are sessions are sessions are mediated by N-PEs. mediated by N- mediated by N- PEs. PEs. 4.2 Tunnel Architecture "Core"/öAccessö Devices The tunnel topology determines if there is full-mesh of point-to- point (p2p) tunnels or partial-mesh of p2p or multi-point (mp) tunnels (including p2mp, mp2p and mp2mp). Tunnels may not be unique per VPLS instances. Tunnel technology determines the mechanisms used to create these tunnels. PWs are created within the tunnels to identify the VPLS instance and are therefore unique to VPLS instances. The number of tunnels and PWs presented here represent the minimal numbers that are needed. Such minimal numbers are needed for best effort VPLS services. However, if value-add functionality, e.g. QOS, resiliency, etc is required, these numbers may be higher. These are further discussed in Section 6. 4.2.1 Core Network This section describes the tunnel architecture among the core devices. N-PE devices can be connected through the WAN network via p2p or mp tunnels. GVPLS DTLS VPLS/HVPLS Tunnel P2p full mesh P2p full-mesh P2p full-mesh topology Tunnel MPLS, GRE, etc. MPLS, GRE, etc. MPLS, GRE, etc. technology Chen, et. al Expires: April 2003 [Page 8] Internet Draft draft-chen-ppvpn-dvpls-compare-01.txt November 2002 Number of O(n*n) per SP O(n*n) per SP O(n*n) per SP tunnels network, where n is network, where network, where number of N-PEs. n is number of n is number of N-PEs. N-PEs. PW topology Unidirectional Mp2p Bi-directional Bi-directional (when CW used) P2p full mesh P2p full mesh OR Bi-directional p2p full mesh Service MPLS Label, GRE key, MPLS Label, GRE MPLS Label, GRE Label etc. key, etc. key, etc. technology Number of O(n) per VPLS, where O(n*n) per O(n*n) per PWs n is number of N-PEs VPLS, where n VPLS, where n when using control is number of N- is number of N- word PEs PEs OR O(n*n) per VPLS when control word is not used. 4.2.2 Access Network N-PE can be connected via point-to-point links to local U-PEs. However, these point-to-point links can be either physical or virtual (e.g. FR, ATM, etcà). With physical links, transport tunnel are not needed between N-PE and U-PE devices. However, tunnels may become necessary for creating and maintaining point-to-point virtual links, where each point-to-point virtual link is identified in the tunnel through a service label. This service label may be associated to the tunnel technology, e.g. DLCI for FR. It is also possible to use multipoint links, e.g. switched Ethernet transport (SET), as the mechanism to move traffic between N-PE and local U-PE devices. This scheme, similar to MPLS-in-IP [MPLS-IN-IP], may not require a transport tunnel to exist. The following table is not applicable to distributed solutions. GVPLS DTLS VPLS/HVPLS Tunnel P2p tree, mp p2p tree P2p tree, topology Tunnel MPLS, Ethernet Unspecified MPLS and Q-in-Q technology (e.g. MAC-in- MAC) Number of O(l) per SP O(l) per SP O(l) per SP tunnels network, where network, where l network, where l l is number of is number of local is number of local U-PE U-PE local U-PE PW topology P2p and Mp2p P2p P2p Service MPLS Label, MPLS Label, VLAN MPLS Label, VLAN Label VLAN tag, etc. etc. tag Chen, et. al Expires: April 2003 [Page 9] Internet Draft draft-chen-ppvpn-dvpls-compare-01.txt November 2002 technology Number of O(r) per VPLS, O(r) per VPLS, 1 per VPLS PWs where r is where r is number number of of remote U-PEs remote U-PEs End-to-End tunnels and PWs refer to tunnels and PWs between devices hosting the customer demarcation, e.g. U-PE for distributed model while PE for non-distributed models. It is also possible for N-PE devices to host the customer demarcation, when the customer sites are connected directly to an N-PE in a distributed model. N-PE device may provide splicing between the PWs connecting that N-PE to U-PEs in access side and other N-PEs in the core side. GVPLS DTLS VPLS/HVPLS End to End No No No tunnels End to End Spliced at N-PE Spliced at N-PE No. PWs 4.3 Information Model/End-Point data model This section provides an overview of the informational model used in VPLS solutions that influences the provisioning and signaling aspects as discussed in earlier sections. Different entities involved in the VPLS solutions include CE, U-PE, N-PE and Endpoints. A CE is the customer site device that connects to the SP network. U- PE is the SP device that connects to the CE on the customer facing ports and to N-PE devices on the core facing ports. N-PE is a SP device that connects to U-PE devices on access side and other N-PE devices in SP core network. N-PE devices may also allow connectivity directly to CE devices. Endpoints refer to the customer and SP demarcation. This may refer to the ports on U-PE and/or N-PE and may also refer to virtual ports, e.g. port + VLAN, when customer VLAN handling is supported. Type of algorithm for provisioning refers to the technique used for providing VPLS configurations. These can be done manually, also called as provisioning, or can be made automatic, through provisioning algorithms. Some examples include the colored pool PW provisioning model as explained in [L2VPN-FRMK]. Single point provisioning refers to the capability of a VPN member, provisioned in a given End-Point, to be automatically discovered by the remote End-Points in the same VPLS. GVPLS DTLS VPLS/HVPLS CPE Ids Transparent Transparent Transparent N-PE Ids N-PE-id unique in N-PE router id, N-PE-id unique SP network unique in SP in SP network Chen, et. al Expires: April 2003 [Page 10] Internet Draft draft-chen-ppvpn-dvpls-compare-01.txt November 2002 network U-PE-ids U-PE-id may be U-PE IP address U-PE IP address unique per VPLS is unique in SP is unique in SP OR network. Another network. U-PE-id Unique per N-PE provisioned Site is transparent. Id is unique per VPLS. Type of Provisioned N-PE Provisioned U-PE Core tunnels are provisioning information Site Ids, VPLS provisioned. algorithm allows automatic Ids etc allow VPN-id allows PW signaling automatic PW automatic signaling signaling. Access tunnels are provisioned Single point Allowed through Allowed through Double sided and provisioning provisioning at provisioning at support N-PEs & single N-PEs and Single- indicated for sided signaling. sided signaling. single sided. Integrates Auto- discovery with LDP Signaling Flexibility Requires changes Requires changes Requires changes in adding/ to U-PE only to U-PE only to U-PE only removing end-points Flexibility Provisioning Provisioning Provisioning in adding or required at required at required at removing U- connected N-PE. connected N-PE. connected N-PE PE Requires over- provisioning to limit changes to N-PE connected to the U-PE. Else provisioning is also required at other N-PEs. Flexibility Provisioning Provisioning Provisioning in adding or required in required in required in removing N- establishing establishing establishing PE tunnels. tunnels. tunnels. 5. Forwarding Plane Architecture The forwarders implemented across different VPLS devices in the SP network characterize forwarding plane. The forwarders implement a Virtual Switching Instance (VSI) per VPLS instance, which emulates Ethernet LAN/Bridge characteristics, e.g. MAC Learning, forwarding, flooding etc. The learning and forwarding involved in the VSI may allow the U-PE/N-PE device to associate a customer packet to appropriate service multiplexed PW in the SP network. Chen, et. al Expires: April 2003 [Page 11] Internet Draft draft-chen-ppvpn-dvpls-compare-01.txt November 2002 Another characteristic of the VSI is the encapsulation technique and corresponding source learning that influences the need for PWs in a VPLS. Typically the VSI on the U-PE, that performs learning and forwarding between locally attached customer end-points and PWs between U-PE and N-PE, is called as VSI-u while the VSI on N-PE, that performs learning and forwarding between PWs between U-PE and N-PE and PWs between N-PEs, is called as VSI-n. It is also possible to realize VSI-u and VSI-n on the same device, e.g. when learning and forwarding needs to be repeated or when N-PE allows directly connected customer end-points. This section highlights the VSI characteristics for U-PE and N-PE devices with an assumption that customer-end points are connected to only U-PEs. When it is possible to connect customer end-points to N- PEs, some characteristics of U-PE may apply to N-PEs. 5.1 VSI 5.1.1 VSI-u GVPLS DTLS VPLS/HVPLS Required on Required Required Required U-PE? Required on Not-required Not-required Required N-PE? Local SA MAC in SA MAC in SA MAC in Source incoming customer incoming customer incoming customer learning packet is packet is packet is associated with associated with associated with customer end- customer end- customer end- points. points. points. Remote SA MAC in SA MAC in SA MAC in Source encapsulated encapsulated encapsulated learning customer packet, customer packet, customer packet, from incoming from access PW, from access PW, access PW, is is associated to is associated to associated to remote U-PE-id. local N-PE-id. remote U-PE-id. Remote U-PE-id is Local N-PE-id is Remote U-PE-id is derived from derived from derived from service label service label service label semantics. semantics semantics. Remote DA MAC in DA MAC in DA MAC in Forwarding incoming customer incoming customer incoming customer towards N- packet is packet is packet is PE associated to associated to associated to PW outgoing access access PW for for local N-PE-id PW for remote U- remote U-PE-id PE-id Local Customer DA MAC Customer DA MAC Customer DA MAC Chen, et. al Expires: April 2003 [Page 12] Internet Draft draft-chen-ppvpn-dvpls-compare-01.txt November 2002 Forwarding looked up and looked up and looked up and from access packet forwarded packet forwarded packet forwarded PW towards to customer end- to customer end- to customer end- customer point. point. point. end-point 5.1.2 VSI-n GVPLS DTLS VPLS/HVPLS Required on Not-required Not- Not-required U-PE? required Required on Required Required Required N-PE? Local No learning No learning Learning performed. Source performed. Inserts performed SA MAC in learning local U-PE-id in CW, since full encapsulated when used, before mesh of PW customer packet, sending out the exists. from access PW, is flooding packets associated to U-PE- across core PWs. id, connected to access PW. Remote Learning not required Learning SA MAC in Source since full mesh not encapsulated learning exists [when not required customer packet, using CW] since full from core PW, is OR mesh exists associated to When using control remote N-PE-id, word and receiving connected to core flooded packet, PW. learns remote U-PE-id from CW Remote Splices access PW Splices Customer DA MAC Forwarding corresponding to access PW associated to core towards remote U-PE to core to core PW PW for remote N-PE- remote N-PE PW corresponding to id the same remote U-PE [local U-PE-id is added to control word, when used] Local Splices core PW Splices Customer DA MAC Forwarding corresponding to core PW to looked up, forwards towards U- local U-PE to access access PW. packet along PE PW corresponding to associated access same local U-PE PW. 5.2 Customer packet encapsulation [see above section] [GVPLS]: For distributed, "Edge" devices only. For non-distributed, ôCoreö device only. [DTLS]: "Edge" devices only Chen, et. al Expires: April 2003 [Page 13] Internet Draft draft-chen-ppvpn-dvpls-compare-01.txt November 2002 [VPLS-MPLS]: Both "Edge" and "Core" devices 5.3 Packet replication/Flooding A key VPLS functionality is to perform source learning and support for broadcast, multicast traffic. Flooding is also required to determine the forwarding characteristics for unknown Unicast addresses. In a typical bridge, the flooding is performed across all the bridge ports, however, in VPLS applications, it is required that flooding, broadcast and multicast are performed within the VPLS domain, i.e. only to those customer end-points, that belong to the VPLS instance. For the purposes of multicast packets, flooding mechanisms may be deployed though these are inefficient. Flexibility of any solution to support multicast may be determined in terms of number of packets that get replicated. Also the type of the multicast may be described in terms of multicast tree types: hierarchal or source-based. Hierarchal is when the replication is optimized and distributed across U-PE and N-PE devices such that overall replication is minimized. On the other hand, source-based tree, also called as broadcast, performs the replication at the source U-PE device resulting in non-optimal replication. GVPLS DTLS VPLS/HVPLS Replication for Supported Supported Supported Flooding/broadcast Support for Supported Not Supported Not supported, Multicast through FFS use of multicast labels Multicast Tree Hierarchal Source- Source- types based/broadcast based/broadcast Number of packets None, the O(r), where r None, the replicated by U-PE packet is is the number packet is sent sent to of remote U-PEs to local N-PE multicast access PW to local N-PE Number of packets O(n), None O(n), where n replicated by where n is is number of local N-PE number of remote N-PEs remote N- PEs Number of packets O(l), None O(l), where l replicated by where l is is number of remote N-PE number of local U-PEs local U- PEs Chen, et. al Expires: April 2003 [Page 14] Internet Draft draft-chen-ppvpn-dvpls-compare-01.txt November 2002 6. Other Comparison Metrics Besides the comparison aspects discussed above, some other metrics that can be used to further evaluate and compare the proposed solutions have been discussed in this section. 6.1 Scalability Scalability is compared on the basis of the following parameters: o Number of VPLS instances that may be supported. E.g. [VPLS-MPLS] when using the Q-in-Q mechanism of encapsulation of customer packets can support only 4K (i.e. 4094) VPLS instances in the service provider network. o Number of sites per VPLS that may be supported o Number of customers addresses/ports per site that may be supported o Number of PWs and/or Service Labels o Replication mechanism and its associated overhead LetÆs suppose a network with ôkö N-PE devices each with ônö EndPoints that belong to the same VPLS instance. The total number of EndPointPs for this particular VPLS instance is n*k. Based on these: In GVPLS the number of VC-Labels in the core is n*k*(k-1). In DTLS the number of VC-Labels in the core is n*k*(n*k -1). In HVPLS the number of VC-Labels in the core is k*(k-1). LetÆs take a concrete scenario [this scenario is for illustrative purposes only, it may not represent a real network] û a network with 50 N-PEs. Assumptions - all customers are accessing the network through U-PE devices - each VPLS has at most one customer port at an U-PE device - # of CustomerÆs MAC per site: 100 - # of sites per VPLS: 40 - # of VPLSs per U-PE: 20 - # of U-PEs per N-PE: 50 - # of N-PEs in a metro area: 20 - # of sites per VPLS per N-PE: 4 (10 N-PEs are involved in each VPLS) - # of sites per VPLS per U-PE: 1 - # of VPLSs in a metro: 2000 - # of VPLSs per N-PE: 1000 - # of end hosts per VPLS: 40*100 = 4,000 - Using the above notations, we can say the followings: k = 10; n = 4; # of VPLSs = 2000 GVPLS DTLS VPLS/HVPLS Chen, et. al Expires: April 2003 [Page 15] Internet Draft draft-chen-ppvpn-dvpls-compare-01.txt November 2002 Max.# of Learned 80,000 80,000 80,000 [4,000*20] MACs per U-PE Max.# of Learned 0 0 4,000,000 MACs per N-PE #of Nodes involved 20 20 20 in IGP routing Max # of Tunnel 190 190 190 LSPs # of VCs per VPLS 360 1560 90 # of VCs in the 720,000 3,120,000 180,000 [10*(10- Metro 1)*2000] # of Copies Sent 1 39 1 between local U-PE and N-PE for Multicast # of Copies Sent 4 4 50 between remote N- PE and U-PE for Multicast MAC Aging Per U- Per U-PE Per N-PE (handle PE 4,000,000) 6.2 Provisioning cost/complexity One of the critical factors for any architecture/solution is the provisioning cost/complexity incurred by the service provider. An approach of manually provisioning the network for deploying a given VPLS solution may result in large provisioning costs and complexity. This is for further study. 6.3 Integration and migration (Interworking) This is for further study. 6.4 Resiliency This section talks about the proposed use of dual homing and/or other mechanisms. It also takes into consideration the possible use of STP, RSTP mechanisms. This is for further study. 6.5 OAM This section is for further study. 7. Security Considerations This document describes commonalities and differences between distributed and hierarchical architectures to support Virtual Private Chen, et. al Expires: April 2003 [Page 16] Internet Draft draft-chen-ppvpn-dvpls-compare-01.txt November 2002 LAN Service (VPLS). Implementations of the architectures may have their own set of security issues. However, the architectures themselves do not contain security issues. 8. References [L2VPN-METRICS] Andersson, et al. "Parameters and related metrics to compare PPVPN Layer 2 solutions", draft-andersson-ppvpn-metrics- 01.txt, work in progress, June 2002. [L2VPN-FRMK] Andersson, et al. "PPVPN L2 Framework", draft-ietf- ppvpn-l2-framework-01.txt, work in progress, August 2002. [GVPLS] Radoaca et al. "GVPLS/LPE û Generic VPLS Solution based on LPE Frameworkö, draft-radoaca-ppvpn-gvpls-00.txt, work in progress, October 2002. [DTLS] Kompella, K., et al. "Decoupled Transparent LAN Services", draft-kompella-ppvpn-dtls-01.txt, work in progress, October 2001. [VPLS-MPLS] Lasserre, M., et al., "Virtual Private LAN Services over MPLS", draft-lasserre-vkompella-ppvpn-vpls-02.txt, work in progress, June 2002. [LPE ARCH] Ould-Brahim, H., et al., "VPLS/LPE L2VPNs: Virtual Private LAN Service using Logical PE architecture", draft- ouldbrahim-l2vpn-lpe-02.txt, work in progress, March 2002. [MARTINI-SIG] Martini, L., et al., "Transport of Layer 2 Frames Over MPLS", draft-martini-l2circuit-trans-mpls-08.txt, work in progress, November 2001. [MPLS-IN-IP] Worster, T., et al., "MPLS Label Stack Encapsulation in IP ", draft-worster-mpls-in-ip-05.txt, work in progress, July 2001. 9. Acknowledgments Many thanks to Michael Chen who contributed into this draft and helped to refine its content. 10. Author's Addresses Dinesh Mohan Nortel Networks P O Box 3511 Station C Ottawa ON K1Y 4H7 Canada Phone: +1 (613) 763 4794 Email: mohand@nortelnetworks.com Vasile Radoaca Chen, et. al Expires: April 2003 [Page 17] Internet Draft draft-chen-ppvpn-dvpls-compare-01.txt November 2002 Nortel Networks 600 Technology Park Billerica, MA 01821 Phone: +1 (978) 288 6097 Email: vasile@nortelnetworks.com Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Chen, et. al Expires: April 2003 [Page 18]