INTERNET DRAFT Vijayanand Expiration Date: March 2007 HCL Technologies Somen Bhattacharya Avici Systems BGP Protocol extensions for PCE Discovery across Autonomous systems draft-vijay-somen-pce-disco-proto-bgp-01.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 March, 2007. Copyright Notice Copyright (C) The Internet Society (2006). 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 C [Page 1] INTERNET DRAFT BGP extensions for PCE discovery September 2006 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. 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 C September 2006 [page 2 ] INTERNET DRAFT BGP extensions for PCE discovery September 2006 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 C September 2006 [page 3 ] INTERNET DRAFT BGP extensions for PCE discovery September 2006 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 C September 2006 [page 4 ] INTERNET DRAFT BGP extensions for PCE discovery September2006 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 G bit: Capability to handle GMPLS link contraints 1 B bit: Capability to compute bidirectional paths 2 D bit: Capability to compute link/node/SRLG diverse Vijayanand C September 2006 [page 5 ] INTERNET DRAFT BGP extensions for PCE discovery September 2006 paths 3 L bit: Capability to compute load-balanced paths 4 S bit: Capability to compute a set of paths in a synchronized Manner 5 O bit: Support for multiple objective functions 6 P bit: Capability to handle path constraints (e.g. hop count, metric bound) 7 DRA bit: Capability to compute inter-area diverse paths 8 DAS bit: Capability to compute intra-AS diverse paths 9 DRS bit: Capability to compute inter-AS diverse paths 10 C bit: Capability to handle inter-AS policy constraints 11 T bit: Capabilty to handle diff-serv aware TE requests 9-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 DRA bit indicates the capability of the PCE to compute inter-area diverse paths that are end-to-end node-disjoint across area borders. The DAS bit indicates the capability of the PCE to compute intra-ASdiverse paths in which path segments within an AS are node-disjoint but end-to-end paths across AS borders are not node-disjoint. The DRS bit indicates the capability of the PCE to compute inter-ASdiverse paths in which path segments are end-to-end link, node, SRLG or area disjoint across the AS borders. The C bit indicates the capability of the PCE to handle inter-AS Vijayanand C September 2006 [page 6 ] INTERNET DRAFT BGP extensions for PCE discovery September 2006 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 T bit 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 C September 2006 [page 7 ] INTERNET DRAFT BGP extensions for PCE discovery September 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // 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 C September 2006 [page 8 ] INTERNET DRAFT BGP extensions for PCE discovery September 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 C September 2006 [page 9 ] INTERNET DRAFT BGP extensions for PCE discovery September 2006 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 normal BGP decision process will not be applied to the received PCE information. 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 >. +---------------------------+ | 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 : Vijayanand C September 2006 [page 10 ] INTERNET DRAFT BGP extensions for PCE discovery September 2006 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 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 Vijayanand C September 2006 [page 11 ] INTERNET DRAFT BGP extensions for PCE discovery September 2006 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 Somen Bhattacharya, Avici Systems. 101 Billerica Avenue N. Billerica, MA 01862 USA Phone: 1 978 964 2606 Email: somen@avici.com 10. References 10.1 Normative References Vijayanand C September 2006 [page 12 ] INTERNET DRAFT BGP extensions for PCE discovery September 2006 [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-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation Element (PCE) Architecture", draft-ietf-pce-architecture, work in progress. [PCE-DISC-REQ] J.L. Le Roux,"Requirements for Path Computation Element (PCE) Discovery", draft-ietf-pce-discovery-reqs-05.txt, work in progress. [PCE-DISCO-IGP] J.L. Le Roux, J.P. Vasseur, Yuichi Ikejir, Raymond Zhang, " IGP Protocol extensions for Path computation Element Discovery", draft-ietf-pce-disco-proto-igp, workin progress,JUne 2006. [BGP-CAP] R. Chandra, J. Scudder, "Capabilities advertisement with BGP-4", RFC3392,November 2002. [MP-BGP] T.Bates,Y.Rekhter,R.Chandra,D.Katz," Multiprotocol Extensions for BGP-4",RFC2858, June 2000. [Heffernan] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. 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. Vijayanand C September 2006 [page 13 ] INTERNET DRAFT BGP extensions for PCE discovery September 2006 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 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 C September 2006 [page 14 ] INTERNET DRAFT BGP extensions for PCE discovery September 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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 C September 2006 [page 15 ]