Network Working Group Kexin Tang Internet-Draft Zhihong Wang Intended status: Informational Yuanlin Bao Expires: April 28, 2011 Xuerong Wang Gang Lu ZTE Corporation Oct 25, 2010 Stateful PCE draft-tang-pce-stateful-pce-01.txt Abstract A PCE can be either stateful or stateless. The information carried in stateful PCE are more detailed than that of stateless PCE. With the state capability of PCEs, the PCCs may make advanced and informed choices about the PCEs to use. This draft focus on stateful PCE, describes the applicability of stateful PCE and gives the IGP and PCEP extensions to support stateful PCE. 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 April 28, 2011. Copyright Notice Copyright (c) 2010 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 Kexin Tang, et al. Expires April 28, 2011 [Page 1] Internet-Draft Stateful PCE Oct 2010 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Applicability of stateful PCE . . . . . . . . . . . . . . . . . 4 3.1. stateful PCE in support of GCO . . . . . . . . . . . . . . 4 3.2. stateful PCE in support of resources restoration . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. PCE Discovery and PCEP Extensions . . . . . . . . . . . . . . . 6 5.1. PCED Extensions . . . . . . . . . . . . . . . . . . . . . . 6 5.2. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Kexin Tang, et al. Expires April 28, 2011 [Page 2] Internet-Draft Stateful PCE Oct 2010 1. Introduction As defined in section 6.8 of RFC4655 [RFC4655], a PCE can be either stateful or stateless. For stateful PCE, there is a strict synchronization between the PCE and not only the network states (in term of topology and resource information), but also the set of computed paths and reserved resources in use in the network. So stateful PCE has more network information, and it can be used to do some complicated work, such as supporting GCO as well as resources restoration. Since the information carried in stateful PCEs are more detailed than that of stateless PCEs, having knowledge of the state capability of PCEs, the PCC may make advanced and informed choices about which PCE to use. However, the existing PCE discovery ([RFC5088], [RFC5089]) and PCEP don't support stateful PCE, and the PCC have no knowledge of the state of PCE. So, this document focus on stateful PCE, describes the applicability of stateful PCE and gives the IGP and PCEP extensions to support stateful PCE. 1.1. 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]. 2. Terminology o PCC: Path Computation Client. A client application requesting a path computation to be performed by the Path Computation Element. o PCE: Path Computation Element. An entity that is capable of computing a network path or route based on a network graph, and of applying computational constraints during the computation. o PCED: PCE Discovery. o PCEP: Path Computation Element communication Protocol. o TED: Traffic Engineering Database, which contains the topology and resource information of the domain. The TED may be fed by Interior Gateway Protocol (IGP) extensions or potentially by other means. o GCO: Global Concurrent Optimization. A concurrent path computation application where a set of TE paths are computed concurrently in order to optimize network resources. A GCO path Kexin Tang, et al. Expires April 28, 2011 [Page 3] Internet-Draft Stateful PCE Oct 2010 computation is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or reoptimize the entire network to satisfy all constraints for all TE LSPs. A GCO path computation can also provide an optimal way to migrate from an existing set of TE LSPs to a reoptimized set (Morphing Problem). 3. Applicability of stateful PCE As mentioned in the preceding part of this document, stateful PCE utilizes information from the TED as well as information about existing paths (for example, TE LSPs) in the network. Since stateful PCE has more network information, it can be used to solve the problem of resources conflict. Typical use cases of stateful PCE are listed in this section. 3.1. stateful PCE in support of GCO As mentioned in RFC5557 [RFC5557], when computing or reoptimizing the routes of a set of Traffic Engineering Label Switched Paths (TE LSPs) through a network, it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or reoptimize the entire network to satisfy all constraints for all TE LSPs. Since stateful PCE realized not only network states (in term of topology and resource information), but also the set of computed paths and reserved resources in use in the network, it can help a GCO realize the entire topology of the network and complete set of existing TE LSPs, so as to make a GCO to achieve the optimal network, particularly when there are several LSP needed to build, if a stateful PCE have computed a end-to-end path successfully, and hold the resources needed by this path, as a stateful PCE, therefore it could realize the newly path and reserved resources, so it can inform other PCEs involved in the GCO not to consider the same resources it just hold for the path, so stateful PCE can avoid unnecessary retries in GCO, so as to make a GCO sufficiently. 3.2. stateful PCE in support of resources restoration Another important scenario for using the state of PCEs is that in resources restoration. A serious situation of network failure as Kexin Tang, et al. Expires April 28, 2011 [Page 4] Internet-Draft Stateful PCE Oct 2010 fiber cutting may rise to a huge number of resources restoration requests in a short time from the PCC. In the restoration, if a stateful PCE have computed a LSP in its own domain successfully, and hold the resources needed by this LSP, as a stateful PCE, therefore it could realize the newly path and reserved resources, so it can inform other PCEs involved in the end-to-end path computation not to consider the same resources it just hold for the LSP, so stateful PCE can avoid unnecessary retries in resources restoration. And if a stateful PCE failed to compute an end-to-end LSP, it will informed the newly path states to other stateful PCE, and release the resources it just hold, so the other stateful PCE can use the resources. 4. Requirements As mentioned before, stateful PCE synchronized with not only the network states (in term of topology and resource information), but also the set of computed paths and reserved resources in use in the network. So the PCC need to tell stateful PCE the path state (created or deleted). However, having no knowledge of the state of PCEs, the PCC have no idea of which PCE to send the path state. In this situation, there are two possibilities for the PCC: send the path state to all the PCEs whatever the state of them, or not send to any of the PCE, and every stateful PCE query the path state information when needed. In the former case, there would be lots of unnecessary operation; and in the second case, it would increasing the complexity of the realization of the control plane and PCE. Therefore there are requirement of having knowledge of the state of PCEs for PCC. Knowing the state of PCEs, the PCC only send the path state information to stateful PCEs. [RFC5088] defines extensions to OSPFv2 [RFC2328] and OSPFv3 [RFC2740] to allow a PCE in an OSPF routing domain to advertise some information useful to a PCC for PCE selection. It defines a new TLV (named the PCE Discovery TLV (PCED TLV)) to be carried within the OSPF Router Information LSA ([RFC4970]). The type 5 sub-TLV of PCED TLV, which named PCE-CAP-FLAGS sub-TLV, used to indicate PCE capabilities. It contains eight capabilities, but not includes the state capability of a PCE. So the PCE in an OSPF routing domain cannot advertise its state capability information to a PCC for PCE selection. Kexin Tang, et al. Expires April 28, 2011 [Page 5] Internet-Draft Stateful PCE Oct 2010 5. PCE Discovery and PCEP Extensions This section provides protocol extensions for support of stateful PCE. Protocol extensions discussed in this section including PCED and PCEP. 5.1. PCED Extensions To support stateful PCE, PCC SHOULD know a PCE is stateful or not. Therefore, the PCE discovery message SHOULD indicates whether the PCE advertises this message is a stateful PCE. Since PCE-CAP-FLAGS Sub- TLV ([RFC5088] for OSPF, [RFC5089] for IS-IS) contains PCE Capability Flags, this document defines a new flag, Stateful PCE Capability Flag, as follows (need to be assigned by IANA): Bit Capabilities 9 Stateful PCE 5.2. PCEP Extensions A PCC that wishes to inform a successful end-to-end path computation and end-to-end path connection may send an unsolicited notification to the PCE involved in the end-to-end path computation. New Notification-type and Notification-value are currently defined as follows (need to be assigned by IANA): o Notification-type=3: end-to-end path computation result * Notification-value=1: end-to-end path computation successful. When an end-to-end path is successfully computed, the PCC SHOULD send a notification message with Notification-type=3 and Notification-value=1 to all the PCE which involved in the end- to-end path computation. * Notification-value=2: end-to-end path computation failure. When an end-to-end path is unsuccessfully computed, the PCC SHOULD send a notification message with Notification-type=3 and Notification-value=2 to all the PCE which involved in the end- to-end path computation. o Notification-type=4: end-to-end connection result * Notification-value=1: end-to-end path connection is success. When an end-to-end path is successfully connected, the PCC SHOULD send a NOTIFICATION message with Notification-type=4 and Notification-value=1 to all the PCE which involved in the end- to-end path computation. Kexin Tang, et al. Expires April 28, 2011 [Page 6] Internet-Draft Stateful PCE Oct 2010 * Notification-value=2: end-to-end path connection failure. When an end-to-end path is unsuccessfully connected, the PCC SHOULD send a notification message with Notification-type=4 and Notification-value=2 to all the PCE which involved in the end- to-end path connection. 6. Security Considerations The extensions of this draft is baed on PCEP and OSPF, only some optional protocol elements are added which will not change the security of existing network. 7. IANA Consideration TBD. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 4970, July 2007. [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008. [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008. [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization", RFC 5557, July 2009. Kexin Tang, et al. Expires April 28, 2011 [Page 7] Internet-Draft Stateful PCE Oct 2010 Authors' Addresses Kexin Tang ZTE Corporation No.68 ZiJingHua Road,Yuhuatai District Nanjing, Jiangsu 210012 P.R.China Phone: +86-025-52871745 Email: tang.kexin@zte.com.cn URI: http://www.zte.com.cn/ Zhihong Wang ZTE Corporation 12F, ZTE Plaza, No.19 East Huayuan Road,Haidian District Beijing 100191 P.R.China Phone: +86-010-59932453 Email: wang.zhihong@zte.com.cn URI: http://www.zte.com.cn/ Yuanlin Bao ZTE Corporation 5F, R&D Building 3, ZTE Industrial Park, XiLi LiuXian Road, Nanshan District, Shenzhen 518055 P.R.China Phone: +86-755-26773731 Email: bao.yuanlin@zte.com.cn URI: http://www.zte.com.cn/ Xuerong Wang ZTE Corporation R&D Building 3, ZTE Industrial Zone, Liuxian Road,Nanshan District Shenzhen 518055 P.R.China Phone: +86-755-26773926 Email: wang.xuerong@zte.com.cn URI: http://www.zte.com.cn/ Kexin Tang, et al. Expires April 28, 2011 [Page 8] Internet-Draft Stateful PCE Oct 2010 Gang Lu ZTE Corporation 2/F, ZTE Plaza, North Huashiyuan Road, East Lake Zone Wuhan 430223 P.R.China Phone: +86-027-51811033 Email: lu.gang2@zte.com.cn URI: http://www.zte.com.cn/ Kexin Tang, et al. Expires April 28, 2011 [Page 9]