INTERNET DRAFT Vijayanand Expiration Date: December 2007 HCL Technologies Somen Bhattacharya Prasanna Kumar Avici Systems BGP Protocol extensions for PCE Discovery across Autonomous systems draft-vijay-somen-pce-disco-proto-bgp-04.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. This Internet-Draft will expire on December, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract It is desirable for a PCC to dynamically discover a PCE and its capabilities for computing paths which span multiple areas and autonomous systems. When the path to be computed spans across multiple IGP domains or autonomous systems, it Vijayanand, et al. [Page 1] INTERNET DRAFT BGP extensions for PCE discovery June 2007 is advantageous to use BGP to distribute information about PCEs. This document describes means to carry PCE discovery information using Multi-protocol extensions of BGP(MP-BGP). Requirements Language 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 [RFC2119]. 1. Introduction The motivation for using PCE-based model for path computation in MPLS networks is clearly detailed in [PCE- ARCH]. This model supports separation of PCC and PCE. A network may consists of a number of PCEs, spread across multiple areas and domains, each with different capabilities and scope. In such a scenario, it is highly desirable to have a dynamic and automatic means for PCE discovery. This would enable the PCC to be aware of PCE in its own domain and the PCE in a domain be aware of PCEs in other domains for computing paths spanning multiple domains, eg. as in inter-domain TE LSPs. The mechanism would also facilitate automatic detection of modification of PCE information.This discovery information would be used in selecting appropriate PCE for setting up PCEP session bwtween PCEs.Detailed requirements on PCE discovery are described in [PCE-DISC-REQ]. The means to discover PCE in the same IGP domain are described in [PCE-DISCO-IGP], wherein the IGP is used to flood information on the PCE capabilities. In order to discover PCEs across IGP domains and autonomous systems a more scalable model than IGP flooding is required. This is also relevant since operators have policies governing the import and export of routing information across their domains. An efficient way for discovering PCEs across IGP domains and Autonomous systems would be to use BGP for carrying PCE discovery information. This document describes how PCE information can be carried in MP-REACH-NLRI of BGP update messages. The PCE Discovery TLV and PCE Status TLV defined in [PCE-DISCO- IGP], which represent the state and status of PCE, will be carried in the NLRI information of the MP-REACH NLRI. Vijayanand, et al. June 2007 [page 2 ] INTERNET DRAFT BGP extensions for PCE discovery June 2007 The path-computation-capabilities TLV which is a sub- TLV of PCE discovery TLV as defined in [PCE-DISCO-IGP] has been extended to support additional capabilities.Additional sub-TLVs have also been added to the PCE discovery TLV to support alternate PCE discovery. The PCE information is described in section 3 and BGP specific procedures and interactions with IGP are described in section 4. 2. Terminology 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 [RFC-WORDS]. The reader is assumed to be familiar with the terminology in [PCE-ARCH] and [PCE-DISCO-IGP] AS : Autonomous system ASBR : Autonomous System Border Router Inter-AS TE LSP : A TE LSP whose path crosses one or more ASes or sub ASes NLRI : Network Layer Reachability Information PCC : Path Computation Client. An entity or application requesting path computation from a Path computation element PCE : Path Computation Element. An entity or application capable of computing paths over a network topology subject to constraints. TE LSPs : Traffic Engineered Label Switched Path 3. PCE Information The PCE information advertised includes PCE discovery information and PCE status information. Vijayanand, et al. June 2007 [page 3 ] INTERNET DRAFT BGP extensions for PCE discovery June 2007 This document describes extensions to the PCE discovery information that is defined in [PCE-DISCO-IGP} that is to be carried in BGP. 3.1 PCE Discovery Information The PCE discovery information consists of PCE location, PCE inter-domain functions, PCE domain visibility, PCE destination domains and a set of general PCECP capabilities. These are described in [PCE-DISCO-IGP} and the same TLVs as used for OSPF can be used for BGP. In addition to the definitions in [PCE-DISCO-IGP] we define new capability flags for PCE in the path computation capabilities TLV. We also define additional sub-TLVs to the PCE discovery sub-TLVs for redundant PCE discovery. The PCE discovery TLV carries the path computation capabilities sub-TLV which is described and extended below. 3.1.1 Path Computation Capabilities Sub-TLV The path computation capability PATH-COMP-CAP sub-TLV is carried in the PCE discovery TLV. This is used to advertise path computation specific capabilities of the PCE. It MAY include optional sub-TLVs to encode more complex capabilities. We define additional capabilities in the path computation capabilities flag of the path computation capabilities sub-TLV. Two more additional capabilities flag are defined to extend the definitions of diverse path computation capabilities to consider inter-AS paths. In general the path diversity level can be categorized as: . Intra-area diversity : the path segments are link, node or SRLG disjoint inside an IGP area. . Inter-area diversity : the end-to-end paths are link, node and SRLG disjoint across area borders. . Intra-AS diversity : the path segments are link, node, SRLG or area disjoint inside an AS. . Inter-AS diversity : the end-to-end paths are link, node, SRLG or area disjoint across AS borders. The format of the PATH-COMP-CAP sub-TLV is as follows: Vijayanand, et al. June 2007 [page 4 ] INTERNET DRAFT BGP extensions for PCE discovery October2006 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Computation Capabilities Flag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Optional sub-TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be assigned by IANA (suggested value =1) Length Variable. Value This comprises a 32 bit flag. Bits are indexed from the most significant to the least significant, where each bit represents one path computation capability. Optional TLVs may be defined to specify more complex capabilities. Three optional sub-TLVs are currently defined. IANA is requested to manage the space of the Path Computation Capabilities 32-bit flag. The following bits are to be assigned by IANA: Bit Capabilities 0 Capability to handle GMPLS link contraints 1 Capability to compute bidirectional paths 2 Capability to compute link/node/SRLG diverse Vijayanand, et al. June 2007 [page 5 ] INTERNET DRAFT BGP extensions for PCE discovery June 2007 paths 3 Capability to compute load-balanced paths 4 Capability to compute a set of paths in a synchronized Manner 5 Support for multiple objective functions 6 Support for additive path constraints (max hop count etc..) 7 Support for request prioritization 8 Support for multiple requests per message 9 Capability to compute inter-area diverse paths 10 Capability to compute intra-AS diverse paths 11 Capability to compute inter-AS diverse paths 12 Capability to handle inter-AS policy constraints 13 Capabilty to handle diff-serv aware TE requests 14-31 Reserved for future use. In addition to the capabilities defined in [PCE-DISCO-IGP] the following new capability bits are defined in this document. The bit 9 indicates the capability of the PCE to compute inter-area diverse paths that are end-to-end node-disjoint across area borders. The bit 10 indicates the capability of the PCE to compute intra-AS diverse paths in which path segments within an AS are node-disjoint but end-to-end paths across AS borders are not node-disjoint. The bit 11 indicates the capability of the PCE to compute inter-AS diverse paths in which path segments are end-to-end link, node, SRLG or area disjoint across the AS borders. The bit 12 indicates the capability of the PCE to handle inter-AS Vijayanand, et al. June 2007 [page 6 ] INTERNET DRAFT BGP extensions for PCE discovery June 2007 policy constraints in the PCC computation request. This MAY be requests containing constraints to avoid certain AS or sub-AS or certain inter-AS links or certain ASBRs. The bit 13 indicates the capability of the PCE to handle computation requests for diff-serv aware TE LSPs. These requests would contain information on the diff serv class type of the requested LSP in addition to the other TE constraints. 3.1.2 PCE Redundancy Discovery When multiple PCEs participate in the computation of an inter-domain path each PCE MAY be responsible to compute one or more path segments that span through specific domains. In such scenarios it MAY be desirable to have redundant backup PCEs that can be used in the event of failure of one or more primary PCEs. Thus the PCE discovery mechanism should allow a PCE to indicate a set of one or more alternate backup PCEs that can be chosen in case the given PCE fails.Two new sub-TLVs have been defined that can be optionally present in the PCE discovery TLV. These two sub-TLVs can be used for the discovery of such redundancy information satisfying dynamic PCE discovery requirements set forth in [PCE-DISC-REQ]. 3.1.2.1 ALTERNATE-PCES sub-TLV The ALTERNATE-PCES sub-TLV specifies the set of PCEs as an alternate to a given primary PCE for path computation purposes. One or more alternate PCE can be selected when the given primary PCE fails. It contains a set of one or more PCE-ADDRESS sub-TLVs where each sub-TLV is used to identify an alternate PCE. This is an optional sub-TLV and one or more such instances MAY be included in the PCED TLV. The ALTERNATE-PCES sub-TLV has the following 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 | Length | Vijayanand, et al. June 2007 [page 7 ] INTERNET DRAFT BGP extensions for PCE discovery June 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // PCE-ADDRESS sub-TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be assigned by IANA (suggested value=5) Length Variable. Value This comprises a set of one or more PCE- ADDRESS sub-TLVs where each sub-TLV identifies an alternate PCE that can perform the same path computational functions as a given primary PCE when the given PCEfails. The ALTERNATE-PCES sub-TLV if present MUST include at least one PCE-ADDRESS sub-TLV. 3.1.2.2 PRIMARY-PCES sub-TLV The PRIMARY-PCES sub-TLV specifies the set of primary PCEs for which the given PCE acts as an alternate PCE for path computation purposes. When any of the primary PCEs in the set fails the alternate PCE can be chosen for the same kind of path computation functions as the primaries do. It contains a set of one or more PCE-ADDRESS sub-TLVs where each sub-TLV is used to identify a primary PCE. This is an optional sub-TLV and one or more such instances MAY be included in the PCED TLV. The PRIMARY-PCES sub-TLV has the following 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // PCE-ADDRESS sub-TLVs // Vijayanand, et al. June 2007 [page 8 ] INTERNET DRAFT BGP extensions for PCE discovery June 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be assigned by IANA (suggested value=6) Length Variable. Value This comprises a set of one or more PCE- ADDRESS sub-TLVs where each sub-TLV identifies a primary PCE for which the given PCE represents an alternate PCE with the same kind of path computational capabilities as the primary. The PRIMARY-PCES sub-TLV if present MUST include at least one PCE-ADDRESS sub-TLV. 4. BGP Specific Procedures The PCE discovery TLV and PCE Status TLV will be carried in the MP-Reach NLRI of BGP update messages. BGP speakers shall encode this in a new value . The new value shall be advertised in the list of address families supported by the speaker in its open message. When the PCE is first advertised or when its capabilities, scope changes the PCE Discovery TLV and its relevant sub TLVs will be carried in the MP-REACH-NLRI. When the PCE experiences congestion or when its congestion status changes it can originate only the PCE status TLV, containing the Address sub-TLV and congestion status sub- TLV in the MP-REACH-NLRI. Since the congestion status changes more frequently than the PCE capabilities, the PCE status TLV is likely to be sent more frequently in the MP- REACH-NLRI. Multiple PCE discovery TLV and PCE status TLV may be carried in the same MP-REACH NLRI if they share the same next-hop in the Multi-protocol extensions attribute. Multiple MP-REACH-NLRI may be sent in the same update message when they share the same AS-path attributes. The PCE information can be directly injected into BGP by configuration or the PCE information carried by the IGP( OSPF or ISIS) as in [PCE-DISCO-IGP] can be redistributed into BGP through suitable configuration. Since BGP may not Vijayanand, et al. June 2007 [page 9 ] INTERNET DRAFT BGP extensions for PCE discovery June 2007 be used in all the routers the PCE information carried in BGP can be redistributed selectively into the IGP so that all the potential PCCs can discover the PCEs. When an administrator or operator deactivates the PCE the corresponding PCE information has to be withdrawn. This can be accomplished by sending the PCE discovery TLV in the MP-UNREACH-NLRI attribute of the BGP Update message. The PCE information can be distributed across AS boundaries using E-BGP sessions. BGP policy can be used to control the import and export of PCE information similar to existing controls over the distribution of normal BGP routes.The discovery information corresponding to a PCE typically needs to be distributed only to a few neighbouring ASes. The discovery information about a PCE can be uniquely identified from the Address sub-TLV which is carried in both the PCE Discovery TLV and PCE Status TLV. When the same PCE discovery information is received from multiple BGP peers the local BGP speaker shall select one of them using its local BGP decision process applied on the AS-Path attributes. This would result in consistently selecting the PCE discovery information from one of the peers for a given policy configuration, thereby any stale information would not be injected into the PCE. The BGP speaker shall store only the selected PCE discovery information and propagate it to its peers. The Nexthop carried in the MP-REACH-NLRI of the PCE discovery information MAY be used to reach the PCE if the PCE address is not advertised as a route in the BGP IPv4 update messages. 4.1 Encoding PCE TLVs in MP-REACH-NLRI The PCE information is carried in the NLRI of the Multiprotocol extensions attribute described in [MP-BGP]. The Address Family Identifier (AFI) and Subsequent Address Identifier(SAFI) will be set to . The next hop field will be filled in as per usual BGP processing rules to enable reachability to the PCE. The next hop address will belong to the same family( IPv4 or IPv6) as the address family in the PCE Discovery TLV. The Network Layer Reachability Information will be encoded as < Length, List of TLV >. Vijayanand, et al. June 2007 [page 10 ] INTERNET DRAFT BGP extensions for PCE discovery June 2007 +---------------------------+ | 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 NLRI b) List of TLVs : This contains a list of TLVs each of which can be a PCE Discovery TLV or PCE Status TLV. The encoding of the PCE discovery TLV and its sub-TLVs and the encoding of the PCE status TLV will be same as that of the corresponding OSPF PCE TLVs described in [PCE-DISCO- IGP] with the extensions proposed in this document 4.2 Encoding PCE Discovery TLVs in MP-UNREACH-NLRI The PCE information is carried in the NLRI of the Multiprotocol extensions attribute. The Address Family Identifier (AFI) and Subsequent Address Identifier(SAFI) will be set to . The Network Layer Reachability Information will be encoded as < Length, List of TLV >. +---------------------------+ | Length (2 octets) | +---------------------------+ | List of TLVs(variable) | +---------------------------+ The meaning of the fields is described as follows: c) Length : The length in bytes of the list of TLVs carried in the NLRI Vijayanand, et al. June 2007 [page 11 ] INTERNET DRAFT BGP extensions for PCE discovery June 2007 d) List of TLVs : This contains a list of PCE Discovery TLVs. The PCE discovery TLV will contain the PCE-address-sub-TLV defined in [PCE-DISCO-IGP] corresponding to the PCE whose information is withdrawn. 5. Interoperability Considerations BGP speakers which support this feature shall advertise the corresponding to the PCE Information in the list of address families supported by the speaker. This can be advertised in the Capabilities Optional parameter[BGP- CAP] of the open message sent to the peer. A BGP speaker shall not advertise PCE information to a speaker which does not support the as advertised in its capabilities. 6. Acknowledgements The authors wish to place on record their sincere gratitude for the support extended by Balaji Radhakrishnan during this work. 7. IANA Considerations IANA is requested to assign a separate SAFI number to be used in the MP-REACH-NLRI attribute for PCE discovery. 8. Security Considerations This extension to BGP does not change the underlying security issues inherent in the existing BGP [Heffernan]. 9. Authors' Addresses Vijayanand C HCL Technologies Ltd. No.184, NSK Salai, Vadapalani,Chennai -26 India. Phone : 91 44 23728366 ext:1357 Email : vijayc@hcl.in Vijayanand, et al. June 2007 [page 12 ] INTERNET DRAFT BGP extensions for PCE discovery June 2007 Somen Bhattacharya, Avici Systems. 101 Billerica Avenue N. Billerica, MA 01862 USA Phone: 1 978 964 2606 Email: somen@avici.com Prasanna Kumar, Avici Systems. 101 Billerica Avenue N. Billerica, MA 01862 USA Phone: 1 978 964 2297 Email: pkumar@avici.com 10. References 10.1 Normative References [RFC-WORDS] Bradner, S.,"Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [PCE-DISCO-IGP] J.L. Le Roux, J.P. Vasseur, Yuichi Ikejir, Raymond Zhang, "OSPF protocol extensions for Path Computation Element (PCE) Discovery", draft-ietf-pce-disco-proto-ospf-05.txt, work in progress,May 2007. [MP-BGP] T.Bates,Y.Rekhter,R.Chandra,D.Katz," Multiprotocol Extensions for BGP-4",RFC4760, January 2007. [BGP-CAP] R. Chandra, J. Scudder, "Capabilities advertisement with BGP-4", RFC3392,November 2002. Vijayanand, et al. June 2007 [page 13 ] INTERNET DRAFT BGP extensions for PCE discovery June 2007 [Heffernan] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. 10.2 Informative References [PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation Element (PCE) Architecture", RFC 4655, August 2006. [PCE-DISC-REQ] J.L. Le Roux,"Requirements for Path Computation Element (PCE) Discovery", RFC 4674,October 2006. 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. Vijayanand, et al. June 2007 [page 14 ] INTERNET DRAFT BGP extensions for PCE discovery June 2007 Full 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. 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 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. Vijayanand, et al. June 2007 [page 15 ]