Network Working Group Internet Draft K. Kumaki, Ed. Category: standard track KDDI R&D Labs Created: November 12, 2007 T. Murai Expires: May 12, 2008 FURUKAWA NETWORK SOLUTION CORP. BGP protocol extensions using attribute for Path Computation Element (PCE) Discovery draft-kumaki-pce-bgp-disco-attribute-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract It is highly desirable for Path Computation Clients (PCCs) to be able to dynamically discover a set of Path Computation Elements (PCEs) when PCCs/PCEs request a path computation to PCEs across ASes. In such a scenario, it is advantageous to use BGP to distribute PCE K.Kumaki, et al. [Page 1] draft-kumaki-pce-bgp-disco-attribute-00 November 2007 information. This document defines a new attribute and describes how PCE information can be carried using BGP. 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]. Table of Contents 1. Introduction..................................................2 2. Terminology...................................................3 3. PCE Information...............................................4 3.1 BGP PCE Discovery Attribute..............................4 4. BGP Specific Procedure........................................5 5. Security Considerations.......................................6 6. IANA Considerations...........................................6 7. Normative References..........................................6 8. Informative References.........................................6 9. Acknowledgments................................................7 10.Author's Addresses.............................................7 11.Intellectual Property Statement................................7 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]. In order for a PCC and PCE to communicate, the PCC must know the location of the PCE. Also, in order for PCEs to communicate, the PCE must know the location of another PCE as well. Actually, a number of PCEs may be contained in multiple areas/domains. In that sense, it is highly desirable to have a mechanism for dynamic PCE discovery. In this case, PCCs can automatically discover a set of PCEs with additional information that may be used by a PCC to perform PCE selection. Detailed requirements for such a PCE discovery mechanism are described in [RFC4674]. [PCE-DISCO-OSPF] and [PCE-DISCO-ISIS] describe the method to discover PCE in the IGP domain. PCE capability information is flooded to IGP K.Kumaki, et al. [Page 2] draft-kumaki-pce-bgp-disco-attribute-00 November 2007 domain using OSPF and IS-IS. Here, it is assumed that a PCC within an AS wants to establish TE LSPs to a destination in a lot of remote different ASes across domains. In this case, a static configuration for PCE discovery is fine. However, in order to discover a set of PCEs across domains (i.e., ASes), it is highly desirable to use BGP for carrying PCE information and to discover a set of PCEs automatically from the service provider perspective. Specifically, a PCE address for a destination is required. Then, PCCs/PCEs discover the PCE address or some PCE addresses automatically and send PCReq messages to them. As described in [PCE-DISCO-BGP], PCE discovery information consists of PCE location, PCE inter-domain functions, PCE domain visibility, PCE destination domains and a set of general PCECP capabilities. The PCE discovery information is described in [PCE-DISCO-OSPF] and [PCE- DISCO-ISIS], and the same TLVs can be used for BGP. Therefore, in order to establish a BGP session, a BGP speaker needs to have this capability. However, if RRs are deployed in an MPLS network, service providers need to upgrade all RRs to recognize this capability. From the service provider perspective, it is not desirable to upgrade all RRs in order to add only one function (i.e., PCE function). Therefore, BGP PCE discovery attribute is defined in this document. In this case, needless to say, RRs are not required to upgrade and only PEs which speaks PCE protocol are required to upgrade. 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. 2. 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). K.Kumaki, et al. [Page 3] draft-kumaki-pce-bgp-disco-attribute-00 November 2007 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. 3. PCE Information The PCE discovery information as described in [PCE-DISCO-BGP] consists of PCE location, PCE inter-domain functions, PCE domain visibility, PCE destination domains and a set of general PCECP capabilities. The PCE discovery information is described in [PCE- DISCO-OSPF] and [PCE-DISCO-ISIS], and the same TLVs can be used for BGP. Here, the PCE discovery attribute for PCE in the Path Attributes of BGP is defined. 3.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 non-transitive. However, it is a future work though the transitive bit can be defined as 1 (transitive). The Attribute Flags will be set as follows: The Optional bit set to 1(optional). The Transitive bit set to 0(non-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: K.Kumaki, et al. [Page 4] draft-kumaki-pce-bgp-disco-attribute-00 November 2007 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 PCE Discovery TLV. The encoding of the PCE discovery TLV and its sub-TLVs will be the same as that of the corresponding OSPF PCE TLVs described in [PCE- DISCO-OSPF] and [PCE-DISCO-ISIS]. 4. 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: 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. K.Kumaki, et al. [Page 5] draft-kumaki-pce-bgp-disco-attribute-00 November 2007 5. 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] 6. IANA Considerations IANA will assign BGP PCE Discovery Attribute type. 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4271] Rekhter, Y. and T. Li, "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. 8. Informative References [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "Path Computation Element (PCE) Architecture", RFC 4655, August 2006. [RFC4657] Ash, J., Le Roux, J.L., "PCE Communication Protocol Generic Requirements", RFC4657, September 2006. [RFC4674] Le Roux, J.L., et al. "Requirements for PCE discovery", RFC4674, October 2006. [PCEP] Vasseur, J.-P., et al., "Path Computation Element(PCE) communication Protocol (PCEP) - Version 1", Work in Progress, February 2007. [PCE-DISCO-OSPF] J.L. Le Roux, J.P. Vasseur, Y. Ikejiri, Raymond Zhang, "OSPF protocol extensions for Path Computation Element (PCE) Discovery", Work in Progress, October 2007. [PCE-DISCO-ISIS] J.L. Le Roux, J.P. Vasseur, Y. Ikejiri, Raymond Zhang, "IS-IS protocol extensions for Path Computation Element (PCE) Discovery", Work in Progress, October 2007. [PCE-DISCO-BGP] Vijayanand, Somen Bhattacharya, Prasanna Kumar, "BGP Protocol extensions for PCE Discovery across Autonomous systems", Work in Progress, June 2007. K.Kumaki, et al. [Page 6] draft-kumaki-pce-bgp-disco-attribute-00 November 2007 9. Acknowledgments The author would like to express thanks to Makoto Nakamura for his 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 11.Intellectual Property Statement The IETF 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 this 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. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR 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 this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein 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 K.Kumaki, et al. [Page 7] draft-kumaki-pce-bgp-disco-attribute-00 November 2007 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. K.Kumaki, et al. [Page 8]