Provider Provisioned VPN WG Michael Chen Dinesh Mohan Internet Draft Nortel Networks draft-chen-ppvpn-dvpls-compare-00.txt Expiration Date: September 2002 Pascal Menezes Terabeam Loa Andersson Utfors March 2002 Decoupled/Hierarchical VPLS: 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 This draft describes commonalities and differences between decoupled and hierarchical architectures to support scalable Virtual Private LAN Services (VPLS). The need to maintain a full mesh of control connections (e.g. LDP, BGP, etcà) and transport paths between all PEs that are service aware may impose a scalability limit on the non decoupled VPLS architecture. On the other hand, a VPLS based solution Chen, et. al Expires September 2002 [Page 1] Internet Draft draft-chen-ppvpn-DVPLS-compare-00.txt March 2002 is required to meet the scaling requirement where the PEs facing customer devices and attached to a core network need to perform MAC learning for all the VPLS services Proposed decoupled and hierarchical architectures 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 is an attempt to describe commonalities and differences between these architectures. Table of Contents Abstract 1. Convention used in this document.........................2 2. Introduction.............................................2 3. Functions to support VPLS................................3 3.1 Control Plane functions.................................3 3.2 Forwarding Plane functions..............................3 4. Control Plane Architecture...............................4 4.1 Architecture Between "Core" Devices.....................4 4.2 Architecture Between "Core" and "Edge" Devices..........4 4.3 Configurations of Decoupled VPLS........................5 5. Forwarding Plane Architecture............................6 5.1 MAC learning............................................6 5.2 Customer VLAN processing................................6 5.3 Customer traffic prioritizing, policing, and shaping....6 5.4 Customer packet encapsulation...........................6 5.5 Packet replication/Flooding.............................7 5.6 Service label de-multiplexing...........................7 6. Security Considerations..................................7 7. References...............................................7 8. Acknowledgments..........................................7 9. Author's Addresses.......................................7 Full Copyright Statement....................................8 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 This draft describes commonalities and differences between decoupled and hierarchical architectures to support VPLS. In the non-decoupled and non-hierarchical VPLS architecture model, it is required that a full mesh of signaling connections (e.g. LDP) and transport paths exist between service aware devices (i.e. PE). The need to maintain a full mesh of control connections (e.g. LDP, BGP, etcà) and transport Chen, et. al Expires September 2002 [Page 2] Internet Draft draft-chen-ppvpn-DVPLS-compare-00.txt March 2002 paths between all service aware devices may impose a scalability limit on the VPLS architecture. On the other hand, a VPLS based solution is required to meet the scaling requirement where the PEs facing customer devices and attached to a core network need to perform MAC learning for all the VPLS services. Proposed decoupled and hierarchical architectures ([LPE ARCH], [DTLS], and [HVPLS]) 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 is an attempt to describe commonalities and differences between these architectures. This draft is not an attempt to endorse any single architecture over the other architectures. As discussed later, the differences among the three architectures are not critical and this draft could facilitate discussion towards merging and enhancing the current decoupled/hierarchical VPLS proposals. This draft is viewed as a step towards a unified decoupled/hierarchical VPLS solution. Figure 1 illustrates a general decoupled/hierarchical VPLS architecture. +------+ +------+ +----------------+ +------+ +------+ |"Edge"| û |"Core"| û |Backbone Network| û |"Core"| û |"Edge"| +------+ +------+ +----------------+ +------+ +------+ Figure 1 This document will first describe the functions required to support VPLS. In section 4, a description of the commonalities and differences between the architectures in the control plane will be given. In section 5, a description of the commonalities and differences between the architectures in the forwarding plane will be given. 3. Functions to support VPLS Following are some of the functions needed to create VPLS. [LPE- ARCH] describes most of these functions in more detail. 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 Chen, et. al Expires September 2002 [Page 3] Internet Draft draft-chen-ppvpn-DVPLS-compare-00.txt March 2002 o Customer traffic prioritizing, policing, and shaping o Customer packet encapsulation o Packet replication/Flooding o Service label de-multiplexing 4. Control Plane Architecture The VPN membership auto-discovery and service label signaling functions described in [LPE ARCH], [DTLS], and [HVPLS] contain both point-to-point and point-to-multipoint signaling. Point-to-point signaling connectivity implies that every device has a signaling connection to all its peer devices. An example of point-to-point signaling is targeted LDP. Point-to-Multipoint signaling refers to that there exist some mechanism where a device has only a few signaling connections to some entity. The mechanism then relays the information to all the peers of the device. An example of point-to- multipoint signaling is BGP with RR. In both decoupled and hierarchical architectures, there is a need to distinguish between the control plane functions between the "Core" devices and control plane functions between "Edge" and "Core" devices. Creating levels in control plane connections to enhance control plane scalability is the common theme in all proposed decoupled and hierarchical VPLS architectures. "Core" devices serve as signaling gateway between its subtending "Edge" devices and the rest of the provider network. 4.1 Architecture Between "Core" Devices Proposals [LPE ARCH], [DTLS], and [HVPLS] all describe a full mesh transport tunnel signaling connections between "Core" devices. [HVPLS] combines its auto-discovery signaling with service label signaling and uses point-to-point signaling connections. Targeted LDP is the mechanism described in [HVPLS]. HVPLS architecture creates a full mesh of auto-discovery/service label signaling connections between "Core" devices. [DTLS] also combines its auto-discovery signaling with service label signaling. However it can use point-to-point or point-to-multipoint signaling connections to convey auto-discovery information to its peer "Core" devices. BGP is the mechanism described in [DTLS]. [LPE ARCH] describes more of an architecture framework. The document does not describe a particular auto-discovery and service label signaling scheme. 4.2 Architecture Between "Core" and "Edge" Devices [HVPLS] and [DTLS] describes "Edge" devices connected to "Core" devices via point-to-point links. However, these point-to-point links can be either physical or virtual (e.g. FR, ATM, etcà). With physical links, it does not require any transport tunnel signaling Chen, et. al Expires September 2002 [Page 4] Internet Draft draft-chen-ppvpn-DVPLS-compare-00.txt March 2002 between "Core" and "Edge" devices. However, sets of point-to-point transport tunnel signaling connections between "Core" and "Edge" devices are required for creating and maintaining point-to-point virtual links. [LPE ARCH] uses switched Ethernet transport as the mechanism to move traffic between "Core" and "Edge" devices. This scheme is similar to MPLS-in-IP [MPLS-IN-IP] where transport tunnels do not exist thus there is no need for a transport tunnel signaling scheme. [HVPLS] combines its auto-discovery signaling with service label signaling and uses point-to-point signaling connections. There is a single auto-discovery/service label signaling connection between "Core" and every "Edge" devices. The mechanism described again is targeted LDP. [LPE ARCH] does not specifically describe a particular auto- discovery and service label signaling scheme between "Core" and "Edge" devices. However, [LPE AD] describes a point-to-multipoint mechanism utilizing the broadcast capability of the switched Ethernet transport. All "Core" and "Edge" devices in the same switched Ethernet transport domain can receive auto-discovery and service label information from other service aware devices within the same switched Ethernet transport. [DTLS] does not specifically describe a particular auto-discovery and service label signaling scheme between "Core" and "Edge" devices. 4.3 Configurations of Decoupled VPLS Proposal [HVPLS] requires Edge devices to create a single point-to- point spoke VC, for each VPLS service supported on this Edge device, to Core device using [MARTINI-SIG]. The Edge device negotiates the VC labels with the Core device. Addition of other Edge devices to add new customer sites requires configuration of the new Edge device but no configuration changes to existing Edge devices. Proposal [DTLS] describes both mechanisms where configurations can be partly carried out on Edge and Core devices and only on Core devices. However the focus is on having a protocol between Edge and Core device such that configuration information can be carried from Core device to the Edge devices. With over provisioning, addition of new Edge devices need not require additional configuration. But when not over provisioned, configuration needs to be done on Core devices and/or new Edge device. [LPE ARCH] proposes VPLS configurations to be carried out at Edge device or at Core device. The objective is to configure customer facing ports on Edge devices and associating the port/endpoints to the VPLS service. It supports use of signaling between Edge device and Core device to distribute configuration information or use of auto-discovery mechanism. [LPE AD] is an example of signaling and Chen, et. al Expires September 2002 [Page 5] Internet Draft draft-chen-ppvpn-DVPLS-compare-00.txt March 2002 auto-discovery mechanism for Edge devices to distribute information within the LPE. [LPE ARCH] also supports dual VPN membership schemes within the Edge and Core devices and among the Core devices. In such cases, VPN membership mapping function is configured at the Core devices. 5. Forwarding Plane Architecture In [DTLS], all virtual bridge (VB) instances only exist in "Edge" devices. DTLS scheme basically creates full mesh tunnels through service labels between all VBs that have membership to the same VPLS. Like [DTLS], all VB instances in [LPE ARCH] only exist in the "Edge" devices. [LPE ARCH] also creates full mesh tunnels through service labels between all VBs that have membership to the same VPLS. However, unlike [DTLS], traffic between two "Edge" devices in the same switched Ethernet transport domain does not need to go through the "Core" device. If one reduces the switched Ethernet transport to a point-to-point Ethernet connection, then [DTLS] and [LPE ARCH] have similar forwarding plane architecture. In [HVPLS], VB instances exist in both "Edge" and "Core" devices. [HVPLS] creates full mesh tunnels through service labels between all VBs in "Core" devices that have membership to the same VPLS. Each VB in the "Core" also have a hub and spoke structure to its "Edge" devices. The hub is the "Core" VB and the spokes are the "Edge" VBs. [HVPLS] basically creates a tree structure in forwarding plane where the base of the tree composes of a full mesh of "Core" VBs. Each "Core" VB then has branches to its relatd "Edge" VBs. 5.1 MAC learning [LPE ARCH]: "Edge" devices only [DTLS]: "Edge" devices only [HVPLS]: Both "Edge" and "Core" devices 5.2 Customer VLAN processing [LPE ARCH]: "Edge" devices only [DTLS]: "Edge" devices only [HVPLS]: Both "Edge" and "Core" devices 5.3 Customer traffic prioritizing, policing, and shaping [LPE ARCH]: "Edge" devices only [DTLS]: "Edge" devices only [HVPLS]: Both "Edge" and "Core" devices 5.4 Customer packet encapsulation [LPE ARCH]: "Edge" devices only [DTLS]: "Edge" devices only [HVPLS]: Both "Edge" and "Core" devices Chen, et. al Expires September 2002 [Page 6] Internet Draft draft-chen-ppvpn-DVPLS-compare-00.txt March 2002 5.5 Packet replication/Flooding [LPE ARCH]: "Edge" devices, switched Ethernet transport and "Core" devices [DTLS]: "Edge" devices only [HVPLS]: Both "Edge" and "Core" devices 5.6 Service label de-multiplexing [LPE ARCH]: "Edge" devices only [DTLS]: "Edge" devices only [HVPLS]: Both "Edge" and "Core" devices 6. Security Considerations This document describes commonalities and differences between decoupled and hierarchical architectures to support Virtual Private LAN Service (VPLS). Implementations of the architectures may have their own set of security issues. However, the architectures themselves do not contain security issues. 7. References [DTLS] Kompella, K., et al. "Decoupled Transparent LAN Services", draft-kompella-ppvpn-dtls-00.txt, work in progress, October 2001. [HVPLS] Khandekar, S., et al., "Hierarchical Virtual Private LAN Service", draft-khandekar-ppvpn-hvpls-mpls-00.txt, work in progress, November 2001. [LPE ARCH] Ould-Brahim, H., et al., "VPLS/LPE: Virtual Private LAN service using the logical PE architecture", draft-ouldbrahim- l2vpn-lpe-00.txt, work in progress, November 2001. [LPE AD] Knight, P., et al., "Logical PE Auto-Discovery Mechanism", draft-knight-l2vpn-lpe-ad-00.txt, work in progress, November 2001. [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. 8. Acknowledgments Many thanks to Hamid Ould-Brahim who contributed heavily into this draft and helped to refine the contents. 9. Author's Addresses Michael Chen Chen, et. al Expires September 2002 [Page 7] Internet Draft draft-chen-ppvpn-DVPLS-compare-00.txt March 2002 Nortel Networks 4010 E Chapel Hill-Nelson Hwy Research Triangle Park, NC 27709 USA Phone: +1 (919) 997 3840 Email: mchen@nortelnetworks.com Dinesh Mohan Nortel Networks P O Box 3511 Station C Ottawa ON K1Y 4H7 Canada Phone: +1 (613) 763 4794 Email: mohand@nortelnetworks.com Pascal Menezes Terabeam 14833 NE 87th St. Redmond, WA, USA Phone: +1 (206) 686 2001 Email: pascal.menezes@terabeam.com Loa Andersson Utfors AB Rasundavagen 12 Box 525, 169 29 Solna Sweden Phone: +46 8 5270 2000 Email: loa.andersson@utfors.se 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 September 2002 [Page 8]