IGP Extensions for Stateful PCE Discovery
Author(s): Siva Sivabalan, Jan Medved, Xian Zhang
When a PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating in IGP, its presence and path computation capabilities can be advertised using IGP flooding. Such IGP extensions...
Internet Engineering Task Force S. Sivabalan Internet-Draft J. Medved Intended status: Standards Track Cisco Systems, Inc. Expires: January 13, 2014 X. Zhang Huawei Technologies July 12, 2013 IGP Extensions for Stateful PCE Discovery draft-sivabalan-pce-disco-stateful-02 Abstract When a PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating in IGP, its presence and path computation capabilities can be advertised using IGP flooding. Such IGP extensions exist for OSPF and ISIS. This document specifies two new PCE capabilities advertised by IGP. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 13, 2014. Copyright Notice Copyright (c) 2013 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 Sivabalan, et al. Expires January 13, 2014 [Page 1] Internet-Draft Stateful PCE Discovery July 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. IGP Extensions for Stateful PCE Capabilities . . . . . . . . . 4 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 5 5. Management Considerations . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Sivabalan, et al. Expires January 13, 2014 [Page 2] Internet-Draft Stateful PCE Discovery July 2013 1. Introduction [RFC5440] describes the Path Computation Element Protocol (PCEP), which defines the communication between a Path Computation Client (PCC) and a Path Control Element (PCE), or between PCE and PCE, enabling computation of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP) characteristics. Stateful PCE [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to enable stateful control of TE LSPs between and across PCEP sessions in compliance with [RFC4657]. It includes mechanisms to effect LSP state synchronization between PCCs and PCEs, delegation of control of LSPs to PCEs, and PCE control of timing and sequence of path computations within and across PCEP sessions. It focuses on a model where LSPs are configured on the PCC and the LSP's path routing and the timing of its setup is delegated to the PCE. When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs are either LSRs or servers also participating in the IGP, an effective mechanism for PCE discovery within an IGP routing domain consists of utilizing IGP advertisements. Such extension to OSPF to IS-IS exists in [RFC5088] and [RFC5089], respectively. Currently, the IGP PCE capability does not indicate whether the advertised PCE is stateful. Advertising active and passive stateful PCE capabilities would facilitate a PCC to learn about available stateful PCEs, as well as about a PCE's capability to modify LSP parameters. A PCC could listen to IGP updates, or use other mechanisms that carry IGP information to interested clients, such as BGP-LS ([I-D.ietf-idr-ls-distribution]) where IGP PCE capability advertisements can be carried in the Opaque Prefix Attribute defined in Section 188.8.131.52. This document extends the IGP PCE capability advertisement mechanism to include active and passive stateful PCEs. 1.1. 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 [RFC 2119] 2. Terminology The following terminology is used in this document: IGP: Interior Gateway Protocol Sivabalan, et al. Expires January 13, 2014 [Page 3] Internet-Draft Stateful PCE Discovery July 2013 IS-IS: Intermediate System to Intermediate System LSR: Label Switching Router OSPF: Open Shortest Path First PCC: Path Computation Client PCE: Path Computation Client PCEP: Path Computation Client 3. IGP Extensions for Stateful PCE Capabilities The PCE-CAP-FLAGS sub-TLV is an optional sub-TLV used to advertise PCE capabilities. It MAY be present within the PCED sub-TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] provide the description and processing rules for this sub-TLV when carried within OSPF and IS-IS, respectively. The PCE-CAP-FLAGS sub-TLV has the following format: o TYPE: 5 o LENGTH: Multiple of 4 o VALUE: This contains an array of units of 32 bit flags with the most significant bit as 0. Each bit represents one PCE capability PCE capability bits are defined in [RFC5088]. This document defines new capability bits for the stateful PCE as follows: Bit Capability 11 Active Stateful PCE capability 12 Passive Stateful PCE capability Note that while active and passive stateful PCE capabilities may be advertised during discovery, PCEP Speakers that wish to use stateful PCEP MUST negotiate stateful PCEP capabilities during PCEP session setup, as specified in Section 7.1.1 in [I-D.ietf-pce-stateful-pce]. A PCC MAY initiate stateful PCEP capability negotiation at PCEP session setup even if it did not receive any IGP PCE capability advertisements. Sivabalan, et al. Expires January 13, 2014 [Page 4] Internet-Draft Stateful PCE Discovery July 2013 4. Backward Compatibility An LSR that does not support the new IGP PCE capability bits specified in this document silently ignores those bits. IGP extensions defined in this document do not introduce any new interoperability issues. 5. Management Considerations A configuration option may be provided for advertising and withdrawing Stateful PCE IGP capability on a PCE. 6. Security Considerations Security considerations described in [RFC5088] are applicable to stateful PCE capabilities. No additional security measures are required. 7. IANA Considerations IANA is requested to allocate new bits in "PCE Capability Flags" registry for stateful PCE capability as follows: Bit Meaning Reference 11 Active stateful PCE capability This document 12 Passive stateful PCE capability This document 8. References 8.1. Normative References [I-D.ietf-idr-ls-distribution] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and TE Information using BGP", draft-ietf-idr-ls-distribution-03 (work in progress), May 2013. [I-D.ietf-pce-stateful-pce] Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce-stateful-pce-05 (work in progress), July 2013. Sivabalan, et al. Expires January 13, 2014 [Page 5] Internet-Draft Stateful PCE Discovery July 2013 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC5088, January 2008. [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC5089, January 2008. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC5440, March 2009. 8.2. Informative References [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC4657, September 2006. Authors' Addresses Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada Email: firstname.lastname@example.org Jan Medved Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Email: email@example.com Sivabalan, et al. Expires January 13, 2014 [Page 6] Internet-Draft Stateful PCE Discovery July 2013 Xian Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen, Guangdong 518129 P.R.China Email: firstname.lastname@example.org Sivabalan, et al. Expires January 13, 2014 [Page 7]