Network Working Group Internet Draft K. Kumaki, Ed. Intended Status: Standards Track KDDI Corporation Created: March 8, 2010 T. Murai Expires: September 8, 2010 Furukawa Network Solutions Corp. T. Yamagata KDDI Corporation C. Sasaki KDDI R&D Labs BGP Protocol Extensions for Path Computation Element (PCE) Discovery in a BGP/MPLS IP-VPN draft-kumaki-pce-bgp-disco-attribute-06.txt Abstract Connectivity between customer sites in an IP Virtual Private Network (VPN) supported by BGP/MPLS may be achieved using MPLS Traffic Engineered (TE) Label Switched Paths (LSPs). The paths of these LSPs must be computed to provide the end-to-end connectivity desired, and the paths selected may depend upon the VPN being served, and the location and reachability of target addresses within customer sites. The Path Computation Element (PCE) is a server that can compute the paths of TE LSPs in an MPLS network. Where one or more VPNs is supported over a core network, different PCEs may serve computations for different VPNs. PCE discovery allows a Path Computation Client (PCC) to determine which PCEs are available to service its computation requests. Using an IGP to distribute PCE discovery information for VPN use would result in the information being needlessly flooded to all core nodes regardless of whether they are aware of the VPN. These nodes do not need to be aware of per-VPN PCE function. This document describes how BGP can be used to distribute PCE discovery information specifically for use in VPN path computation. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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." K. Kumaki, et al. [Page 1] draft-kumaki-pce-bgp-disco-attribute-06 March 2010 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 This Internet-Draft will expire on September 8, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 [RFC2119]. 1. Introduction [RFC4364] documents how a Service Provider could use an IP backbone to provide IP Virtual Private Networks (VPNs) to its customers. Each VPN contains at least one Customer Edge (CE) router which is attached to a Provider Edge (PE) router. It is possible for CE routers to be attached to multiple PE routers. BGP [RFC4271] can be used to exchange VPN route information between the PE routers. K. Kumaki, et al. [Page 2] draft-kumaki-pce-bgp-disco-attribute-06 March 2010 [RFC4655] describes the motivations and architecture for a PCE-based path computation model for MPLS and GMPLS Traffic Engineering (TE) Label Switched Paths (LSPs). In this model, path computation requests are issued by a Path Computation Client (PCC) to a PCE. If the PCC and PCE are not colocated, a request/response communication protocol is needed to carry the request and to return the response. The requirements for such a communication protocol are described in [RFC4657]. The Path Computation Element Communication Protocol (called PCEP) is defined in [RFC5440]. When a PCC is not colocated with the PCE, the PCC must determine the location of the PCE that will service its requests. As described in [RFC4655], the knowledge of the location of a PCE may be achieved through local configuration at the PCC or may rely on a protocol- based discovery mechanism. [E2E-RSVP-TE] lists requirements for supporting customer Resource Reservation Protocol (RSVP) and RSVP-TE over a BGP/MPLS IP VPN. Section 5.8 of that document states that a solution should support the use of per-VPN PCEs for determining the paths of end-to-end MPLS TE LSPs between customer sites. Requirements for the use of PCE to support VPNs are discussed in [PCE-VPN]. That document notes that there is likely to be a correlation between the VPN auto-discovery / membership distribution mechanism and the PCE discovery mechanism used for per-VPN PCEs. But the document sets PCE discovery as out of scope. In a VPN model as described in [E2E-RSVP-TE], CEs or PEs may be PCCs, and PEs or Provider (P) core nodes may be PCEs. There may be very many VPNs supported by a network and many customer sites within each VPN. Furthermore, manual configuration of VPN site information is burdensome and error-prone. Therefore, an automated, protocol-based solution is desirable for per-VPN PCE discovery. [RFC5088] and [RFC5089] describe IGP-based PCE discovery mechanisms. These mechanisms are ideal where all or a large percentage of the nodes in a network need to know the location of the PCE. However, in the case of per-VPN PCEs, it is only the CE and PE nodes that participate in support for the specific VPN that need to know the location of the PCE that serves that VPN. Furthermore, in a VPN environment, the IGP used in the core does not distribute information to CE nodes. Therefore, the IGP solutions are not optimal. This document leverages the use of BGP in VPNs to additionally distribute per-VPN PCE location and capabilities information. A new BGP PCE Discovery Attribute is defined and this is carried in the Path Attributes of the BGP UPDATE message. K. Kumaki, et al. [Page 3] draft-kumaki-pce-bgp-disco-attribute-06 March 2010 2. PCE Discovery Information As defined in [RFC4674], the mandatory PCE discovery information consists of: - Discovery of PCE Location This is an IPv4 and/or an IPv6 address used to reach the PCE. - Domain Visibility Information The computation domains that the PCE serves must be advertised so that PCCs know whether the PCE can satisfy their requests. In the context of per-VPN PCEs, the computation domains are the VPNs. 2.1. BGP PCE Discovery Attribute The PCE information is carried in the Path Attributes of the UPDATE message described in [RFC4271]. The Transitive bit is defined to be set as transitive. The Attribute Flags are set as follows: The Optional bit set to 1 (optional). The Transitive bit set to 1 (transitive). The Partial bit set to 0 (complete). The Extended Length bit set to 1 (2 octets). The Attribute Type is to be assigned by IANA. The Path Attributes will be encoded as < Length, List of TLVs >. +---------------------------+ | Length (2 octets) | +---------------------------+ | List of TLVs (variable) | +---------------------------+ The meaning of the fields is as follows. Length : The length in bytes of the list of TLVs carried in the Path Attribute. List of TLVs : This contains a list of TLVs each of which can be a BGP PCE Discovery TLV. 2.1.1. The BGP PCE Discovery TLV K. Kumaki, et al. [Page 4] draft-kumaki-pce-bgp-disco-attribute-06 March 2010 The BGP PCE Discovery TLV (PCED TLV) contains a non-ordered set of sub-TLVs. The BGP PCED TLV is composed of 2 octets for the type, 2 octets specifying the length of the value portion in octets, and a value field. The BGP PCED TLV has the following format: 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // sub-TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields are as follows: Type: 1 Length: Variable Value: This comprises one or more sub-TLVs One sub-TLV is defined: Sub-TLV type Length Name ------------ -------- -------------------- 1 variable PCE-ADDRESS sub-TLV The following sub-section describes the sub-TLVs that may be carried within the PCED TLV. 2.1.1.1. PCE-ADDRESS Sub-TLV The PCE-ADDRESS sub-TLV specifies an IP address that can be used to reach the PCE. It is RECOMMENDED to use an address that is always reachable, provided that the PCE is alive and reachable. The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the PCED TLV. It MAY appear more than once, when the PCE has an address from more than one address type (i.e., both IPv4 and IPv6). It MUST NOT appear more than once for the same address type. If it appears more than once for the same address type, only the first occurrence is processed and any others MUST be ignored. K. Kumaki, et al. [Page 5] draft-kumaki-pce-bgp-disco-attribute-06 March 2010 The format of the PCE-ADDRESS sub-TLV is as follows: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | address-type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // PCE IP Address // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields are as follows: Type: 1 Length: 8 (IPv4) or 20 (IPv6) Address-type: 1 IPv4 2 IPv6 Reserved: SHOULD be set to zero on transmission and MUST be ignored on receipt. PCE IP Address: The IP address to be used to reach the PCE. 3. Procedures The PCE Discovery Attribute can be carried in the Path Attribute of BGP UPDATE messages. It can be handled regardless of whether IPv4/IPv6 and VPNv4/VPNv6 routes are present in the BGP UPDATE messages. 3.1. Transmission Processing BGP speakers can advertise the address of a per-VPN PCE at the same time as it advertises routes for the VPN. The PCE address is included in the Path Attribute of BGP UPDATE message as a BGP PCE Discovery Attribute. The PCE advertised is associated with the VPN instance to which the BGP UPDATE applies. Thus, the mandatory Domain Visibility Information noted in Section 2 is distributed implicitly. It can be made a configuration choice whether to advertise the PCE address or not. K. Kumaki, et al. [Page 6] draft-kumaki-pce-bgp-disco-attribute-06 March 2010 3.1.1. Choice of PCE Address If a BGP speaker is PCE capable, the PCE address is an assigned address for the BGP speaker itself. It may be a VPN Routing and Forwarding (VRF) interface address or a loopback address. If a BGP speaker is not PCE capable, the address of the PCE may be decided by configuration or any other method; this method is out of scope of this document. 3.2. Receiver Processing BGP speakers that receive PCE Discovery Attributes store the information for use when a PCEP request needs to be sent. The PCE advertised is associated with the VPN instance to which the BGP UPDATE applies. 3.3. Procedure at Path Computation Request: When a router needs a path computed for a particular VPN and the router is not able to perform the computation itself, it looks up the address of the per-VPN PCE. If no address is found it cannot perform the path computation and returns an error. If one or more address is found it selects one according to local policy (see [RFC4655] and [RFC5440]) and acts as a PCC to send the computation request to the PCE according to [RFC5440]. 4. Security Considerations This document defines BGP extensions for PCE discovery across an administrative domain. Hence the security of the PCE discovery relies on the security of BGP within a single administrative domain. Increased information dissemination with BGP makes the network more vulnerable to any attack on BGP. Therefore the use of BGP security mechanisms is RECOMMENDED. The security issues for BGP are described in [RFC2385]. 5. IANA Considerations IANA maintains a registry of attribute types for the Path Attribute called 'BGP Path Attributes'. IANA is requested to assign a new type for the BGP PCE Discovery Attribute type defined in Section 2.1 as follows: K. Kumaki, et al. [Page 7] draft-kumaki-pce-bgp-disco-attribute-06 March 2010 Value Code Reference ----- ----------------------- --------- PCE Discovery Attribute This.ID 6. References 6.1. Normative References [RFC4271] Rekhter, Y. and Li, T., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [RFC4364] Rosen, E., Rekhter, Y., "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "Path Computation Element (PCE) Architecture", RFC 4655, August 2006. [RFC4657] Ash, J., Le Roux, J.L., "PCE Communication Protocol Generic Requirements", RFC 4657, September 2006. [RFC4674] Le Roux, J.L. (Ed.), "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006. [RFC5088] Le Roux, J.L., Vasseur, JP., Ikejiri, Y., and Zhang, R., "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008. [RFC5089] Le Roux, J.L., Vasseur, JP., Ikejiri, Y., and Zhang, R., "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008. [RFC5440] Vasseur, J.-P., et al., "Path Computation Element(PCE) communication Protocol (PCEP) - Version 1", RFC 5440, November 2008. [E2E-RSVP-TE] Kumaki, K., Zhang, R. and Kamite, Y., "Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN", draft-ietf-l3vpn-e2e-rsvp-te-reqts, work in progress. K. Kumaki, et al. [Page 8] draft-kumaki-pce-bgp-disco-attribute-06 March 2010 [PCE-VPN] Yasukawa, S. and Farrel, A. "PCC-PCE Communication Requirements for VPNs", draft-ietf-pce-vpn-req, work in progress. 7. Acknowledgments The author would like to express thanks to Makoto Nakamura, Adrian Farrel, JP Vasseur, and Daniel King for their helpful and useful comments and feedback. 8. Authors' Addresses Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Email: ke-kumaki@kddi.com Tomoki Murai Furukawa Network Solution Corp. 5-1-9, Higashi-Yawata, Hiratsuka Kanagawa 254-0016, Japan Email: murai@fnsc.co.jp Tomohiro Yamagata KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Email: to-yamagata@kddi.com Chikara Sasaki KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino Saitama 356-8502, Japan Email: ch-sasaki@kddilabs.jp K. Kumaki, et al. [Page 9]