Provider Provisioned VPN Working Group Paul Knight Internet Draft Dinesh Mohan draft-knight-l2vpn-lpe-ad-00.txt Hamid Ould-Brahim Expires: April 2002 Vasile Radoaca Nortel Networks, Inc. November 2001 Logical PE Auto-Discovery Mechanism Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026, except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes a lightweight protocol for VPLS information exchange between Logical PE components, consisting of the PE-Edge and PE-Core. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Conventions used in this document...............................2 2. Overview........................................................2 3. Logical PE Architecture.........................................3 4. Logical PE Auto-Discovery Protocol (LPE-AD).....................3 4.1 Terminology....................................................3 4.2 LPE-AD - Provisioning and Distribution.........................4 4.3 One LPE-AD Model: Provision PE-Edges and Distribute to PE-Cores5 4.3.1 LPE-AD Messages..............................................6 Knight, et al Expires May 2002 [Page 1] draft-knight-l2vpn-lpe-ad-00.txt November 2001 4.3.2 PE-Core Actions..............................................6 4.3.3 Summary of PE-Edge to PE-Core Auto-Discovery Protocol........7 5. LPE-AD Protocol Implementation Concepts.........................7 6. Security Considerations.........................................8 7. References......................................................9 8. Acknowledgements................................................9 9. Intellectual Property Considerations............................9 10. Authors' Addresses.............................................9 Full Copyright Statement..........................................10 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. Overview Within the "Logical PE" architecture described in [LPE-ARCH], the functionality of the Provider-Edge devices (PEs) is distributed between low-cost Ethernet-based devices called "PE-Edges" and high- capacity core devices, labeled "PE-Cores." This distribution of functionality improves PE scalability and decreases costs to the service provider. The logical PE (LPE) architecture supports Virtual Private LAN Services (VPLS) as described in [RFC-2764]. It can be adapted to a core network running either [L2-MART] based l2vpn architecture or [L2-KOMP] architecture, or even a core network running both architectures. In order to support the LPE architecture, a lightweight protocol needs to exchange the VPLS-related information (membership, end- point identification, etc.) between the PE-Edges and PE-Cores. It should be simple enough to be implemented in low-cost PE-Edge devices. The Logical PE Auto-Discovery (LPE-AD) protocol described in this draft is intended to perform these functions. LPE-AD allows a group of distributed PE-Edges and PE-Cores to exchange the VPLS information necessary to function as a unified Logical PE device within a service provider's network. The basic functions provided by LPE-AD include: o Notifying PE-Cores within the LPE of addition, deletion, or modification of VPLS membership on customer-facing interfaces (LPE endpoints) of the PE-Edges o Notifying PE-Cores of the addition, deletion, or modification of PE-Edges Knight, et al. Expires May 2002 [Page 2] draft-knight-l2vpn-lpe-ad-00.txt November 2001 3. Logical PE Architecture A detailed architecture and reference model of the "Logical PE" is presented in [LPE-ARCH]. This draft uses much of the terminology and definitions developed in that document. The LPE model offers a way of achieving both scaling and cost objectives by distributing the PE's VPLS functions among low-cost Ethernet-based customer-facing devices and high capacity devices attached to the Service Provider's core network. The LPE model defines devices containing customer-facing interfaces, called "PE- Edges", and core provider edge devices, labeled as "PE-Cores". (The architecture does not preclude the PE-Core from containing customer- facing interfaces. In this case the PE-Core contains all the functions of a "normal" PE.) In general, the PE-Edge manages the Service Level Agreement (SLA), including bandwidth policing, traffic classification and Quality of Service (QoS). It also manages customer Ethernet frame encapsulation and MAC learning. The PE-Core maintains membership information. It communicates VPLS membership information to all the other PE-Core members of the same VPLS. 4. Logical PE Auto-Discovery Protocol (LPE-AD) This section describes the requirements for LPE-AD, describes the requirements for messages used by the protocol, describes a simple LPE-AD protocol, and provides operational scenarios explaining the use of the protocol. 4.1 Terminology The following terminology is used in this draft: Customer Site - An entity connected to the Service Provider's network through a Customer Edge (CE) device. The purpose of Virtual Private LAN Service (VPLS) is to interconnect multiple Customer Sites associated with a single Customer. Multiple Customer Sites within one LPE should use the same CSM-ID in order to belong to a common VPLS. A single Customer Site may belong to multiple VPLSs. Customer Site Member Identifier (CSM-ID) - A local VPN identifier within the LPE. All LPE endpoints belonging to the same VPLS within a specific LPE will be configured with the same CSM-ID. It can be exactly the same as a VPN-ID, or it may be an identifier with significance only within the LPE. A CSM-ID instance is associated with a LPE Endpoint through provisioning. More than one CSM-ID can be provisioned on a given LPE Endpoint, if VLAN tagging is used on the CE-to-LPE Endpoint link to distinguish traffic for different Knight, et al. Expires May 2002 [Page 3] draft-knight-l2vpn-lpe-ad-00.txt November 2001 VPLSs. Each CSM-ID is associated with a VPN-ID. Every instance of a specific CSM-ID MUST be associated with the same Customer VPLS (i.e., be associated with the same VPN-ID) within a single LPE. A state transition of a CSM-ID should be signaled via the LPE-AD protocol. LPE Endpoint - Identifies a CE-facing Ethernet port in a PE-Edge or PE-Core, where VPLS instances can terminate. It acts as the demarcation to a CE device. It is associated with the actual physical interface. A state transition of the LPE Endpoint with active CSM-IDs should be signaled via the LPE-AD protocol. PE-Edge-ID - A PE-Edge is defined within the LPE by a PE-Edge-ID, which is provisioned. The PE-Edge-ID value is an IP address. SET domain - A Switched Ethernet Transport domain; a single Ethernet broadcast domain, within a single Service Provider's network. It may also refer to a single 802.1Q VLAN broadcast domain. The LPE-AD protocol described in this draft is designed specifically to use a SET as the transport between PE-Edge and PE-core within a LPE. VPN-ID - VPN Identifier, is a unique identifier of a VPN within a service provider context. This can be a standard VPN-ID for the core VPN technology used by the service provider, as in [RFC 2685]. Within a LPE, a CSM-ID is mapped one-to-one to a VPN-ID. 4.2 LPE-AD - Provisioning and Distribution LPE-AD facilitates the auto-discovery and distribution of the VPLS membership information inside the LPE. Although other mechanisms such as Edge LDP (using LDP Downstream Unsolicited label advertisements [RFC 3036]) or BGP extensions (BGP Auto-Discovery, in [BPG-AD]) have been discussed as possible methods to accomplish this, they may require functionality beyond the capability of low- cost PE-Edge devices described in the LPE model. A key requirement for LPE-AD is to be as simple as possible while fulfilling the basic functions needed, and preferably allowing for future extensions. The purpose of Auto-Discovery in general is to minimize the requirements for device configuration by the operators of the Service Provider network. Ideally, a specific customer VPLS connection should be provisioned one time, on one device, and that device should be able to initiate the distribution of the information to all other devices that need it. The LPE-AD protocol is used to accomplish this distribution within the LPE. There are three major models for provisioning customer connectivity within a Logical PE architecture: o Provision a customer connection on the PE-Edges and use an LPE Auto-Discovery mechanism to distribute the information to the PE- Core (and thence to the other VPLS members) Knight, et al. Expires May 2002 [Page 4] draft-knight-l2vpn-lpe-ad-00.txt November 2001 o Provision the PE-Core and distribute the information to the PE- Edges through a mechanism like SNMP or LPE Auto-Discovery o Use a Network Management System (NMS) to define the customer connectivity and distribute the provisioning information to both the PE-Core and PE-Edges, without Auto-Discovery between the PE- Core and PE-Edges The first model has the attraction of simplicity. The other two models place heavier demands on the PE-Core (to act almost as an NMS in provisioning other devices) or the NMS (to understand and act on the specific LPE element capabilities). In order to focus on the LPE Auto-Discovery function as a means to simplify the Service Provider's operations, in this draft we will describe the use of LPE-AD to distribute the PE-Edge provisioning information to the PE- Core, as in the first model. The following elements will typically be provisioned by the Service Provider when establishing a Logical PE. These elements may be provisioned on the PE-Edges or the PE-Cores. They will generally be activated one time, and changed infrequently: o PE-Edge-IDs (one IP address per PE-Edge) o VPN-IDs (one per VPLS) along with mapping to CSM-IDs The following elements will typically be provisioned by the Service Provider when creating a specific Customer VPLS connection: o CSM-ID (one CSM-ID for all members of a VPLS within a LPE) o Policy - associated with a VLAN tag or physical interface o LPE Endpoint - (unique ID within SET) The LPE Auto-Discovery protocol provides the mechanism for distributing these provisioned identifiers within the LPE. Devices that are neither PE-Edges or PE-Core within the SET SHOULD NOT participate in the LPE-AD protocol. LPE-AD messages MUST NOT be propagated into Customer Sites. 4.3 One LPE-AD Model: Provision PE-Edges and Distribute to PE-Cores The PE-Edges and PE-Cores within a LPE are interconnected via a Switched Ethernet Transport (SET) domain, as described in [LPE- ARCH]. A key consideration is to minimize the amount of traffic generated on the SET domain by LPE-AD. This is accomplished primarily by bundling VPLS Membership information per physical interface (LPE Endpoint) on the PE-Edge (i.e., including the information for all CSM-IDs on a LPE Endpoint in a single message). When provisioning is performed at the PE-Edges, a minimal LPE-AD may consist of messages broadcast or multicast by the PE-Edges, in a given LPE. However, a more general LPE-AD protocol could include provisions for acknowledgements, or other two-way communication. There may be multiple SET domains per PE-Core (and LPE). When an LPE is composed of more than one SET domain, then LPE-AD messages Knight, et al. Expires May 2002 [Page 5] draft-knight-l2vpn-lpe-ad-00.txt November 2001 originating from a PE-Edge device must be restricted only to its SET domain. More generally, LPE-AD messages MUST NOT be propagated into Customer Sites. Upon receiving the LPE-AD messages, the PE-Core may do the following: o Set up the proper LPE to LPE connectivity (e.g., generate a VC- Label for each new CSM-ID) o May send acknowledgements to the PE-Edges Whenever there is a state change of an LPE Endpoint or CSM-ID (due to provisioning or link/port failure, etc.) the PE-Edge will send a LPE-AD Message for each LPE Endpoint involved in the change. When a LPE-AD Message is sent after a change, it is transmitted several times, a few seconds apart. During a period with no changes, a LPE-AD Message is sent as a keep-alive every few minutes. There is no difference in the format or content of the LPE-AD Message, in either case. The keep-alive LPE-AD Messages allow PE-Cores to learn the state of the PE-Edges in a relatively short period of time, without adding any complications to the simple protocol. For example, PE-Cores do not need to request updates, or notify the PE-Edges of their state. 4.3.1 LPE-AD Messages The LPE-AD Message is used by a PE-Edge device to communicate the following indications: o add a new CSM-ID or a new LPE Endpoint o remove a CSM-ID or LPE Endpoint o keep-alive _ this should indicate that the VPLS Membership is active A LPE-AD Message may group the VPLS Membership information (CSM-IDs) per LPE Endpoint, in order to minimize flooding in the LPE SET and processing in the PE-Edge. In most cases, the LPE-AD Message should fit in a single packet, but since this may not be possible in every case, there should be a provision for splitting the message across multiple packets. In its simplest form, the LPE-AD Message will have the following information: o LPE Endpoint Identifier o The set of CSM-IDs for that LPE Endpoint o The PE-Edge-ID (may be implicit in the LPE-AD packet's source address) 4.3.2 PE-Core Actions The PE-Cores in all LPEs within a Service Provider's network are connected in a fully meshed topology across the core. They perform Knight, et al. Expires May 2002 [Page 6] draft-knight-l2vpn-lpe-ad-00.txt November 2001 all of the inter-PE communications. The PE-Core will perform actions described in this section, based on the information it has received in the LPE-AD Messages. Upon receiving a LPE-AD Message, the PE-Core will perform the following actions: o If the LPE-AD Message is valid, the PE-Core will check the list of CSM-IDs, otherwise it should silently discard the message. o If there is a new LPE Endpoint/CSM-ID tuple in the message, then it will determine or generate the VC-Label(s) associated with that LPE Endpoint/CSM-ID. It may communicate with other PE-Cores. For example, it might send an LDP Mapping Message. o If there is a missing LPE Endpoint/CSM-ID tuple in the message (relative to the previous LPE-AD Message), then local information regarding this CSM-ID is cleared. If the VC-Label has been issued, then it may send an appropriate message (e.g., LDP Withdraw Message) to its PE-Core peers. If no LPE-AD Message is received from a PE-Edge for a specific LPE Endpoint within the keep-alive period, then the PE-Core will consider the VPLS connections on that LPE Endpoint closed. It will remove all the CSM-ID associations with that LPE Endpoint from its internal tables, and may send withdraw messages (e.g., LDP Withdraw Messages) to other PE-Cores (or other PE peers) in the affected VPLSs, for all the VC-Labels representing the CSM-IDs for this specific LPE Endpoint. There should be a long timer to allow for multiple dropped LPE-AD Messages. It should be at least three times the keep-alive interval. 4.3.3 Summary of PE-Edge to PE-Core Auto-Discovery Protocol To summarize the protocol in simple terms: o There is one type of message involved, the LPE-AD Message. The LPE-AD Message is either triggered by a change in the LPE Endpoint association with CSM-IDs (adding/removing VPLS membership, etc.) or is a keep-alive message, which is sent at a regular interval and simply repeats the current information. The message content is the same in either case. o The PE-Core will use one timer per LPE Endpoint. Under any failure of the PE-Edge such that no message is sent, the PE-Core relies on these timers to delete VPLS memberships for that LPE Endpoint. 5. LPE-AD Protocol Implementation Concepts The LPE-AD protocol should be based on the UDP protocol [UDP]. The UDP Port Number should identify the UDP/LPE-AD type messages. The Port number should be configurable, and it should have a default value assigned. Knight, et al. Expires May 2002 [Page 7] draft-knight-l2vpn-lpe-ad-00.txt November 2001 6. Security Considerations The LPE Auto-Discovery protocol is a lightweight protocol intended for use within a network managed by a Service Provider, in a Logical PE architecture. It does not contain explicit security mechanisms. If an attacker can gain access to the links within the LPE, then LPE-AD may be vulnerable to a variety of attacks, including interception, spoofing, and replay. Knight, et al. Expires May 2002 [Page 8] draft-knight-l2vpn-lpe-ad-00.txt November 2001 7. References [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [LPE-ARCH] Ould-Brahim, H., et al., "VPLS/LPE L2VPNs: Virtual Private LAN Services Using Logical PE Architecture", draft-ould- brahim-l2vpn-lpe-00.txt, November 2001, work in progress. [RFC-2764] Gleeson, B., et al., "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000. [L2-MART] Martini, L., et al., "Transport of Layer-2 Frames over MPLS", draft-martini-l2circuit-trans-mpls-07.txt, work in progress, July 2001. [L2-KOMP] Kompella, K., et al., "MPLS based Layer-2 VPNs", draft- kompella-ppvpn-l2vpn-00.txt, June 2001, work in progress. [RFC 2685] Fox, B. et al., "Virtual Private Networks Identifier", RFC 2685, September 1999. [RFC 3036] Andersson, L., et al., "LDP Specification", RFC 3036, January, 2001. [BPG-AD] Ould-Brahim, H., et al., "Using BGP as an Auto-Discovery Mechanism for Network-Based VPNs", draft-ietf-ppvpn-bgpvpn-auto- 00.txt, work in progress. [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August, 1980. 8. Acknowledgements We would like to acknowledge the helpful comments and contributions of the following individuals: Liam Casey, Michael Chen, Hesham Elbakoury, Marc Holness, Amita Patil. 9. Intellectual Property Considerations Nortel Networks may seek patent or other intellectual property protection for some of all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Nortel Networks, Nortel Networks intends to disclose those patents and license them on reasonable and non-discriminatory terms. 10. Authors' Addresses Paul Knight Nortel Networks 600 Technology Park Drive Phone: +1 (978) 288 6414 Billerica, Ma. USA Email: paknight@nortelnetworks.com Dinesh Mohan Nortel Networks 3500 Carling Avenue Phone: +1 (613) 763 4794 Nepean, ON K2H 8E9 Canada Email: mohand@nortelnetworks.com Knight, et al. Expires May 2002 [Page 9] draft-knight-l2vpn-lpe-ad-00.txt November 2001 Hamid Ould-Brahim Nortel Networks P O Box 3511 Station C Phone: +1 (613) 765 3418 Ottawa ON K1Y 4H7 Canada Email: hbrahim@nortelnetworks.com Vasile Radoaca Nortel Networks 600 Technology Park Phone: +1 (978) 288 6097 Billerica, MA, 01803 Email: vasile@nortelnetworks.com 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 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. Knight, et al. Expires May 2002 [Page 10]