Provider Provisioned VPN Working Group Oded Bergman Internet Draft Eran Mann Expiration Date: January 2005 MRV Scott Kotrla MCI July 2004 VPLS Node Auto Auto-Discovery Using IGP draft-bergman-vpls-igp-auto-discovery-00.txt 1. 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 2. Table of Contents 1. Status of this Memo...........................................1 2. Table of Contents.............................................1 3. Specification of Requirements.................................2 4. Abstract......................................................2 5. Overview......................................................2 6. VPLS discovery procedure......................................3 6.1. VPLS auto discovery procedural overview.....................3 6.2. Node Discovery Using IGP protocol...........................3 6.2.1. OSPF VPLS PE Node Opaque LSA Format.......................3 6.2.2. LSA type..................................................3 6.2.3. LSA ID....................................................3 6.2.4. LSA Header................................................4 6.2.5. TLV Header................................................4 6.3. Node Auto discovery procedure...............................7 7. VPN and VC Auto discovery.....................................8 7.1. LDP signaling for VPN service and VC discovery..............8 7.1.1. VPN Auto Discovery........................................8 7.1.2. VC Label Signaling........................................8 7.2 VPN service and VC discovery using IGP additional LSA TLV ...8 8. Intellectual Property.........................................9 9. Full Copyright Statement......................................9 10. References...................................................9 11. Authors' Addresses..........................................10 O.Bergman, et al. [Page 1] Internet Draft draft-bergman-vpls-igp-auto-discovery-00.txt July 2004 3. Specification of Requirements 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 4. Abstract This Internet Draft describes a method for automatic discovery of Virtual Private LAN Service (VPLS) PE nodes and services, in order to establish VPLS networks. The node discovery is done using new Interior Gateway Protocol (IGP) link-state advertisements (LSA), and service discovery is done by using targeted-LDP address messages as was suggested by previous drafts. In previous drafts VPLS PE nodes discovery was made via unsolicited LDP and required establishment of hop by hop LDP sessions across the network. This memo suggests the removal of the need for hop by hop unsolicited LDP advertisements in order to discover the VPLS PE nodes. It enables carriers to use any desired protocol to signal the MPLS LSP tunnels underlying the VPLS(VPLS (for example [RSVP-TE] Or [LDP]). This memo also describes a method that enables carriers to establish a partial VPLS mesh according to a new VPLS group advertisement in the IGP LSA. The goal is to create VPLS networks with a minimum amount of configuration, while maintaining (and improving when possible) network scalability. 5. Overview As L2 VPN services are being deployed in carriers' networks to serve the growing demand for multipoint L2 VPNs, more Virtual Private LAN Services (VPLS) networks are being established to provide these services. The creation and configuration of these VPLS networks has still not been standardized, although several Auto discovery approaches have been suggested. Some require an external RADIUS server as [RADIUS] describes, and some use an expensive provisioning system. Others execute the Auto discovery by using unsolicited LDP signaling as described in [VPLS DISCOVER] and [VHLS DISCOVER] drafts. This document describes a method for VPLS PE node Auto discovery using IGP protocols (such as OSPF and ISIS) link-state advertisements (LSA) mechanism, and service discovery using targeted-LDP. The new IGP LSA includes information on the PE router service capabilities. Optional additional information enables VPLS services to be part of 32 service groups in order to reduce the number of MPLS tunnels and targeted LDP sessions. Based on the IGP LSA information, targeted-LDP sessions are set for service discovery and MPLS tunnels are built between all the VPLS PE routers within the same group. This method enable carriers to use any desired MPLS signaling protocol as RSVP-TE or LDP, according to the carrier requirements. O.Bergman, et al. [Page 2] Internet Draft draft-bergman-vpls-igp-auto-discovery-00.txt July 2004 The service discovery can be done in several ways, this draft propose to use [VHLS DISCOVER] Service discovery. In [VHLS DISCOVER], address messages in targeted LDP sessions are used to advertise the VPLS services. Other VPLS service discovery methods can also use the VPLS nodes discovery that is described in this memo. 6. VPLS discovery procedure 6.1. VPLS auto discovery procedure overview - Discover the VPLS PE routers using OSPF [OPAQUE LSA] and create the VPLS capable PE routers list. - Build MPLS LSP tunnels to all the PE routers in the list,according according to the advertised VPLS protocol capabilities. - Use the list to create targeted-LDP sessions for VPLS services discovery. - Use the VPLS services discovery to build VC PWE connections to each supported service. 6.2. Node Discovery Using IGP protocol Since MPLS is using an IGP protocol to create the network topology and find all the PE routers, it can also be used to find which PE router supports VPLS and what capabilities are available in each router. This memo explains in more details how OSPF [OPAQUE LSA] option can be used for this purpose. The same principle can be applied when using ISIS, and it will be described in a future release of this memo. 6.2.1. OSPF VPLS PE Node Opaque LSA Format Using OSPF Opaque LSA to discover VPLS PE routers can be done by defining a new type of LSA or using an existing LSA with an additional Type/Length/Value (TLV) type, both options are valid. This Memo suggest the use of a new Opaque LSA type, however the existing Traffic Engineering (TE) Opaque LSA defined in [OSPF-TE] or the Router Information Opaque LSA defined in [OSPF-CAP], can be also used with an additional TLV type for VPLS PE router. 6.2.2. LSA type This extension makes use of the OSPF Opaque LSA. Three types of Opaque LSAs exist, each of which has a different flooding scope. This proposal uses only Type 10 LSAs, which have an area flooding scope. A new LSA type needs to be defined (subject to IANA approval), VPLS PE node LSA. This LSA describes VPLS PE routers and advertises their capabilities. 6.2.3. LSA ID The LSA ID of an Opaque LSA is defined as having eight bits of type data and 24 bits of type-specific data. The VPLS PE node LSA will use a previously un-used type, which could currently be 5 (subject to IANA approval). The remaining 24 bits are the Instance field, as follows: O.Bergman, et al. [Page 3] Internet Draft draft-bergman-vpls-igp-auto-discovery-00.txt July 2004 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Instance field is an arbitrary value used to maintain multiple VPLS PE node LSAs. A maximum of 16777216 VPLS PE node LSAs may be sourced by a single system. The LSA ID has no topological significance. 6.2.4. LSA Header The VPLS PE node LSA starts with the standard LSA header: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.2.5. TLV Header A new type of top level TLV is needed to support VPLS advertisement. 1 - VPLS service capabilies (new) A VPLS PE router advertises the following TLV format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPLS Router-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Type | Service Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Signaling capabilities | Control Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPLS Group bitmap mask (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Service Parameters (variable length) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ O.Bergman, et al. [Page 4] Internet Draft draft-bergman-vpls-igp-auto-discovery-00.txt July 2004 - VPLS Router-id: VPLS Router-id field. This is a 32 bit VPLS router-id, which will be used by the MPLS signaling protocols as router-id. - Service Type: Service Type field. This has the following values: Value Node Type ----------------- 0 Undefined 1 VPLS core node 2 VHLS PE (proposed) A node may support multiple service types, in which case it will advertise multiple Service Capabilities TLVs. - Service Instance: Service Instance field. This field contains a 16-bit index used as an instance identifier for the service. This enables, for example, one Service Provider to create multiple sets of VPLS nodes providing different grades of service. Note that a node may have multiple service instances, in which case it will advertise multiple Service Capabilities TLVs. Note also that in the case of VPLS, one service instance may contain multiple VPLS services. This field must have a value of 0 when advertising a VHLS capable PE node. - LSP Signaling Capabilities: LSP Signaling Capabilities field. Each VPLS capable PE router specifies which tunnel signaling protocol it can use for negotiating and exchanging of labels. This is a 16 bit bitmap field. This has the following values: 0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |C|S|R|D|U| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bit Node Type ----------------- 15 (U) Unsolicited LDP 14 (D) Downstream on demand LDP 13 (R) RSVP-TE 12 (S) LDP Proxy server 11 (C) LDP Proxy client 0-10 Reserved O.Bergman, et al. [Page 5] Internet Draft draft-bergman-vpls-igp-auto-discovery-00.txt July 2004 Bit 15: Unsolicited LDP. The router indicates that it is capable of signaling LSP tunnels using unsolicited LDP. Bit 14: Down stream on demand LDP. The router indicate that it is capable of signaling LSP tunnels using LDP downstream on demand. Bit 13: RSVP-TE. The router indicate that it is capable of signaling LSP tunnels using RSVP-TE. Bit 12: LDP Proxy server. The router indicate that it functions as an LDP Proxy server [LDP PROXY] for all the VPLS groups which are set in the VPLS Group bitmap mask field. Bit 11: LDP Proxy client. The router indicate that it negotiates VPLS Thought LDP Proxy server to the all the VPLS groups which are set in the VPLS Group bitmap mask field. Bit 0-10: Reserved. - Control Flags 0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |G| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bit 0-14 (reserved) : Reserved for future use- must be set to zero on transmit and ignored on receive. Bit 15 (G): VPLS Group bitmap mask option, this bit must be set if VPLS Group bitmap mask is present and unset otherwise. - VPLS Group bitmap mask: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ VPLS Group bitmap mask. This field is a 32 bits bitmap mask of VPLS groups. Each bit of the 32 indicates wether or not a VPLS service belonging to the corresponding group is configured on the advertising router. This bitmap optimizes the VPLS service discovery and connections mesh. Each VPLS router will negotiate the VPLS services only with other routers that have the same bit set in the VPLS Group bitmap. This field in combination with other capabilities fields can be used for discovery of other common services such as LDP Proxy server or client. O.Bergman, et al. [Page 6] Internet Draft draft-bergman-vpls-igp-auto-discovery-00.txt July 2004 - Service Parameters: Optional Service Parameters. Some service types may have additional parameters that must be discovered for correct operation of the service. This field is not required for VPLS. Note that for a given service type and instance a node will only advertise one Service Capabilities TLV, with one set of Service Parameters. 6.3. Node Auto discovery procedure Each VPLS capable PE router MUST advertise a VPLS PE node [OPAQUE LSA] with exactly one VPLS router-id TLV for each pair of configured on it. The advertising router MAY include the VPLS Group bitmap mask in the VPLS router-id TLV, in which case it MUST set the G bit in the Control Flags. Upon every configuration change, which changes the data in any of the VPLS PE node LSAs advertised by a PE router, the router MUST regenerate the LSA with the new data. Whenever a pair ceases to be configured on the router, the router MUST withdraw the corresponding VPLS PE node LSA. Upon receiving the VPLS information from another VPLS PE router, a verification and initialization process begins. The Control Flags field of the VPLS router-id TLV is checked. If the (G) bit is set then the VPLS Group bitmap mask bit is in use, the receiving router tests if the sending router belongs to any VPLS Group to which the receiving router belongs. If the (G) flag bit is not set then the receiving router considers the sending router to be part of all the VPLS groups. If there is at least one group to which both routers belong, then the receiving PE router adds the sending router-id to a list of VPLS routers. Adding a router-id to a list of VPLS routers triggers the following: - The receiving PE router initiates the signaling of a MPLS LSP to the senderÆs router-id (if one doesnÆt already exist). - A VPLS service discovery procedure is initiated. According to the advertised MPLS protocol capabilities in the LSP Signaling protocol field of the TLV the receiving router initiates an MPLS tunnel LSP in the following order: If the RSVP-TE bit is set the PE routers will prefer it to the other LDP options and use RSVP-TE to setup the MPLS LSP tunnel. If the RSVP-TE bit is not set then the preferred option is LDP downstream on demand. In case this bit is set to zero then unsolicited LDP is used. O.Bergman, et al. [Page 7] Internet Draft draft-bergman-vpls-igp-auto-discovery-00.txt July 2004 Note: It is the carrier's responsibility to make sure that all of the MPLS signaling protocols will have a viable path. The other process that the receiving router starts is the VPLS service discovery. If service discovery is performed according to [VHLS-DISCOVERY] the receiving router initiates a Targeted-LDP session to the sending router-id for this purpose. The VPLS service discovery procedure is described in paragraph (7.). Whenever a VPLS PE node LSA is readvertised or withdrawn, the receiving router initiates removal of all the services and the MPLS tunnels to the sender which are no longer necessary, and removes the sender form the VPLS routers list if they do not share a common service group anymore. 7. VPN and VC Auto discovery 7.1. LDP signaling for VPN service and VC discovery This part is described in detail in [VHLS DISCOVER] 7.1.1. VPN Auto Discovery The VPN service discovery uses targeted LDP peers to all the known VPLS PE routers that are within the same group (as discovered by IGP). A new address message TLV is used to advertise the VPLS services. This mechanism is described in [VHLS DISCOVER] paragraph 6.2 7.1.2. VC Label Signaling The VC Label Signaling uses targeted LDP peers and the information collected by the VPN service discovery. This mechanism is described in [VHLS DISCOVER] paragraph 6.3 7.2 VPN service and VC discovery using IGP additional LSA TLV An alternative way to perform the services auto discovery is to create another TLV type for IGP LSA that will be advertised by each PE router in a separate LSA that includes all the VPN services. In this case the only protocol that will be used for VPLS discovery will be the IGP which will dramatically reduce the number of targeted-LDP sessions. This method is especially useful for PE routers which participate only in a small number of services. This option may be defined in future versions of this Memo. 8. Intellectual Property MRV is filing Intellectual Property rights for the technology in this document. O.Bergman, et al. [Page 8] Internet Draft draft-bergman-vpls-igp-auto-discovery-00.txt July 2004 9. 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. 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. 10. References [LDP] "LDP Specification." L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas. January 2001. RFC 3036. [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RSVP] Braden et al, "Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997. [OSPF-TE] Katz, D., D. Yeung and K. Kompella, "Traffic Engineering Extensions to OSPF", RFC 3630, September 2003. [OPAQUE LSA] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998. [VPLS] M. Lassere, V. Kompella, (eds.), "Virtual Private LAN Services over MPLSö, Work in progress, draft-ietf-ppvpn-vpls-ldp-03.txt, April 2004. [RADIUS] J. Heinanen, G. Weber, ôUsing RADIUS for PE-Based VPN Discoveryö, Work in progress, draft-ietf-l2vpn-radius-pe-discovery-00.txt, February 2004. [VPLS DISCOVER] O. Stokes et al, ôDiscovering Nodes and Services in a VPLS Networkö, Work in progress, draft-stokes-ppvpn-vpls-discover-00.txt, June 2002. O.Bergman, et al. [Page 9] Internet Draft draft-bergman-vpls-igp-auto-discovery-00.txt July 2004 [VHLS DISCOVER] A. Sodder et. Al., ôVirtual Hierarchical LAN Servicesô, Work in progress, draft-sodder-ppvpn-vhls02.txt, April 2003. [PWE3-CTL] L. Martini et al, Pseudowire Setup and Maintenance using LDP, Work in progress, draft-ietf-pwe3-control-protocol-05.txt, December 2003. [OSPF-CAP] A. Lindem, ôExtensions to OSPF for Advertising Optional Router Capabilitiesö, Work in progress, draft-ietf-ospf-cap-03.txt, July 2004. [LDP PROXY] V. Kompella, "An LDP Proxy for Non-Adjacent LDP Sessions" draft-vkompella-mpls-ldp-proxy-00.txt, Work in progress 11.Author's Addresses Oded Bergman MRV 20415 Nordhoff Street Chatsworth, CA USA 91311 Phone:+1-818-465-4450 Email:obergman@mrv.com Eran Mann MRV 20415 Nordhoff Street Chatsworth, CA USA 91311 Phone: +818-773-0900, +972-4-9936297 Email:emann@mrv.com Scott Kotrla MCI 400 International Pkwy Richardson, TX 75081 Phone: +1-972-729-3407 Email:scott.kotrla@mci.com O.Bergman, et al. [Page 10]