Network Working Group Internet Draft K. Kumaki, Ed. Category: standards track KDDI R&D Labs Created: March 8, 2009 T. Murai Expires: September 8, 2009 FURUKAWA NETWORK SOLUTION CORP. BGP protocol extensions for Path Computation Element (PCE) Discovery in a BGP/MPLS IP-VPN draft-kumaki-pce-bgp-disco-attribute-03.txt 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." 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 In order to provide an end-to-end MPLS TE LSP between customer sites within a BGP/MPLS IP-VPN, it is highly desirable for a Path Computation Element (PCE) to be able to dynamically discover a set of Path Computation Elements (PCEs) that know VPN routes. In BGP/MPLS IP-VPNs, it is advantageous to use BGP to distribute PCE information. This document defines a new attribute and describes how PCE information can be carried using BGP. Conventions used in this document K.Kumaki, et al. [Page 1] draft-kumaki-pce-bgp-disco-attribute-03 March 2009 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]. Table of Contents 1. Introduction..................................................2 2. Problem Statement.............................................3 3. Terminology...................................................3 4. PCE Discovery Information.....................................4 4.1 BGP PCE Discovery Attribute..............................4 4.1.1 The BGP PCE Discovery TLV...............................4 4.1.1.1 PCE-ADDRESS Sub-TLV...................................5 5. BGP Specific Procedure........................................6 6. Security Considerations.......................................7 7. IANA Considerations...........................................7 8. References....................................................7 8.1 Normative References......................................7 8.2 Informative References....................................7 9. Acknowledgments...............................................8 10. Author's Addresses...........................................8 1. Introduction [RFC4655] describes the motivations and architecture for a Path Computation Element (PCE)-based path computation model for Multi Protocol Label Switching (MPLS) / Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs). In this model, path computation requests are issued by a PCC to PCE that may be composite or external. In case the PCC and PCE are not composite, a request/response communication protocol is required to carry the request and return the response. The requirements for such a communication protocol are described in [RFC4657]. The communication protocol between PCC and PCE, and between PCEs, is defined in [PCEP]. Requirements for PCE in BGP/MPLS IP-VPNs [E2E-RSVP-TE] are described. In such a case, PCEs are quite useful to establish an end-to-end MPLS TE LSP between customer sites. As described above, it is highly desirable for a Path Computation Element (PCE) to be able to dynamically discover a set of Path Computation Elements (PCEs) that know VPN routes within a BGP/MPLS IP-VPN. In BGP/MPLS IP-VPNs, it is advantageous to use BGP to distribute PCE information. This document defines BGP PCE Discovery Attribute and describes how PCE information can be carried in the Path Attributes of the UPDATE message described in [RFC4271]. The BGP PCE discovery attribute is defined in section 3 and BGP specific procedure is described in section 4. K.Kumaki, et al. [Page 2] draft-kumaki-pce-bgp-disco-attribute-03 March 2009 2. Problem Statement In order to establish an end-to-end MPLS TE LSP between customer sites within a BGP/MPLS IP-VPN, our goal is for a PCE to discover a set of PCEs that know VPN routes selectively and automatically. The point here is that only specific PCEs that know VPN routes should be discovered automatically. Consider that a service provider offers customers an end-to-end MPLS TE LSP within a BGP/MPLS IP-VPN. Also, it is assumed that all PEs are PCE. In such a case, a tail-end address to establish the end-to-end MPLS TE LSP is included in VPN routes, and the VPN routes are carried by MP-BGP [RFC4760]. Actually, a PE that includes the VPN membership receives the VPN routes and a BGP next hop (i.e., a PE address that advertises the VPN routes). In that sense, it is natural for MP-BGP to carry PCE addresses (PE addresses) that know the VPN routes. In this document, therefore, BGP PCE Discovery Attribute is defined to discover PCEs in the context of BGP/MPLS IP-VPNs. 3. Terminology LSP: Label Switched Path TE LSP: Traffic Engineering Label Switched Path MPLS TE LSP: Multi Protocol Label Switching TE LSP AS: Autonomous System RR: Route Reflector IGP: Interior Gateway Protocol. Either of the two routing protocols Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (ISIS). PCC: Path Computation Client: any client application requesting a path computation to be performed by a Path Computation Element. PCE: Path Computation Element: an entity (component, application or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. PE: Provider Edge: Provider Edge Equipment that has direct connections to CEs from the Layer3 point of view. K.Kumaki, et al. [Page 3] draft-kumaki-pce-bgp-disco-attribute-03 March 2009 4. PCE Discovery Information The PCE discovery information consists of the PCE location, an IPv4 and/or IPv6 address that are used to reach the PCE. Here, the PCE discovery attribute for PCE in the Path Attributes of BGP is defined. 4.1 BGP PCE Discovery Attribute The PCE information is carried in the Path Attributes of the UPDATE message described in [RFC4271]. Here, the Transitive bit is defined as transitive. The Attribute Flags will be 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 will be set to some value. The Path Attributes will be encoded as < Length, List of TLV >. +---------------------------+ | Length (2 octets) | +---------------------------+ | List of TLVs(variable) | +---------------------------+ The meaning of the fields is described as follows: a) Length : The length in bytes of the list of TLVs carried in the Path Attribute. b) List of TLVs : This contains a list of TLVs each of which can be a BGP PCE Discovery TLV. 4.1.1 The BGP PCE Discovery TLV The BGP PCE Discovery TLV (PCED TLV) contains a non-ordered set of sub-TLVs. K.Kumaki, et al. [Page 4] draft-kumaki-pce-bgp-disco-attribute-03 March 2009 The format of the BGP PCED TLV That is composed of 2 octets for the type, 2 octets specifying the TLV length, and a value field. The Length field defines the length of the value portion in octets. 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 // | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1 Length: Variable Value: This comprises one or more sub-TLVs Two sub-TLVs are defined: Sub-TLV type Length Name 1 variable PCE-ADDRESS sub-TLV 2 4 PATH-SCOPE sub-TLV The PCE-ADDRESS and PATH-SCOPE sub-TLVs MUST always be present within The PCED TLV. The following sub-sections describe the sub-TLVs that may be carried within the PCED TLV. 4.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 make use of 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 twice, when the PCE has both an IPv4 and IPv6 address. 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. 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 | | K.Kumaki, et al. [Page 5] draft-kumaki-pce-bgp-disco-attribute-03 March 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | address-type | Reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | // PCE IP Address // | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PCE-ADDRESS sub-TLV format 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. 5. BGP Specific Procedure The PCE Discovery Attribute can be carried in the Path Attribute of BGP update messages. It can be handled regardless of IPv4/IPv6 and VPNv4/VPNv6 routes in BGP update message. Transmission processing: BGP speakers advertise the PCE address with routes. The PCE address is included in Path Attribute of BGP update message as BGP PCE Discovery attribute. It can be configurable whether to advertise the PCE address or not. PCE address decision: If a BGP speaker is PCE capable, the PCE address is the same as an assigned address for BGP speaker itself. It may be a vrf interface address or a loopback address. If a BGP speaker is not PCE capable, it is decided by configuration or another method. This method is out of scope of this document. Receiving processing: BGP speakers that receive PCE Discovery Attributes register in their RIB with routes. Procedure at path computation request: K.Kumaki, et al. [Page 6] draft-kumaki-pce-bgp-disco-attribute-03 March 2009 This part describes an inner process within a router between BGP process and path computation process. If the inquiry of a PCE address is received from path computation process, the BGP process retrieve the pertinent route of RIB, and returns the address of PCE Discovery Attribute. Path computation process transmits path computation request to this address. If this attribute is not in RIB, the BGP process notify path computation process error. If two or more PCE addresses of PCE Discovery Attribute exists, all the addresses are returned to path computation process. 6. 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. The security issues are described in the existing BGP. [RFC2385] 7. IANA Considerations IANA will assign BGP PCE Discovery Attribute type. 8. References 8.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", RFC2385, August 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2 Informative References [RFC4760] Bates, T., Rekhter, Y., Chandra, R., and Katz, D., "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [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", RFC4657, September 2006. [PCEP] Vasseur, J.-P., et al., "Path Computation Element(PCE) communication Protocol (PCEP) - Version 1", Work in K.Kumaki, et al. [Page 7] draft-kumaki-pce-bgp-disco-attribute-03 March 2009 Progress, 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", Work in Progress, October 2008. 9. Acknowledgments The author would like to express thanks to Makoto Nakamura, Adrian Farrel and JP Vasseur for their helpful and useful comments and feedback. 10. Author's Addresses Kenji Kumaki (Editor) KDDI R&D Laboratories, Inc. 2-1-15 Ohara Fujimino Saitama 356-8502, 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 Intellectual Property Statement The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. K.Kumaki, et al. [Page 8] draft-kumaki-pce-bgp-disco-attribute-03 March 2009 The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. Disclaimer of Validity All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Full Copyright Statement Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. K.Kumaki, et al. [Page 9]