Network Working Group Kexin Tang Internet-Draft Zhihong Wang Intended status: Informational Yuanlin Bao Expires: April 20, 2011 ZTE Corporation Oct 17, 2010 Statefull PCE draft-tang-pce-stateful-pce-00.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 20, 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 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Kexin Tang, et al. Expires April 20, 2011 [Page 1] Internet-Draft Statefull PCE Oct 2010 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. Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. PCE Discovery and PCEP Extensions . . . . . . . . . . . . . . . 4 4.1. Statefull PCE Capability Flag . . . . . . . . . . . . . . . 4 4.2. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 5 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Kexin Tang, et al. Expires April 20, 2011 [Page 2] Internet-Draft Statefull PCE Oct 2010 1. Introduction As defined in [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. Since stateful PCE has more network information, it can be used to do some complicated work, such as loops and resource scrap. However, the exsisting PCE discovery ([RFC5088], [RFC5089]) and PCEP don't support stateful 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. 3. Requirement This section lists the tipcal use case of statefull PCE. As described in [RFC4655], stateful PCE not only use information from TED, but also information about existing paths (for example, TE LSPs) in the network when processing new requests, so the information carried in stateful PCE are more detailed than that of stateless Kexin Tang, et al. Expires April 20, 2011 [Page 3] Internet-Draft Statefull PCE Oct 2010 PCE.Knowing the state capability of PCEs, the PCC may make advanced and informed choices about which PCE to use. Another scenario for using the state of PCEs is that the PCC send the path state (created or deleted) to stateful PCE. 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 PCEs . Knowing the state of PCEs, the PCC only send the path state information to stateful PCEs. [RFC5088] defines extensions to OSPFv2 [RFC2328] and OSPFv3 [RFC5340] 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 CE-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. 4. PCE Discovery and PCEP Extensions 4.1. Statefull PCE Capability Flag To support statefull PCE, PCC SHOULD know a PCE is statefull or not. Therefore, the PCE discovery message SHOULD indicates whether the PCE advertises this message is a statefull PCE. Since PCE-CAP-FLAGS Sub- TLV ([RFC5088] for OSPF, [RFC5089] for IS-IS) contains PCE Capability Flags, so this document defines a new flag, Statefull PCE Capability Flag, as follows (need to be assigned by IANA): Bit Capabilities 9 Stateful PCE 4.2. PCEP Extensions With respect to the definitation of stateful PCE ([RFC4655]), a stateful PCE utilizes information from the TED as well as information about existing paths (for example, TE LSPs) in the network when processing new requests. So, a stateful PCE SHOULD know the status Kexin Tang, et al. Expires April 20, 2011 [Page 4] Internet-Draft Statefull PCE Oct 2010 (created or deleted) of a path it computed. Thus, the PCC SHOULD tell PCE the path status which can be done by PCNtf message which is detailed in this section. A new Notification-type and two Notification-value are defined as follows (need to be assigned by IANA): o Notification-type=3: LSP path Status * Notification-value=1: LSP path is created. When a LSP path is created, the PCC SHOULD send a notification message with Notification-type=3 and Notification-value=1 to PCE which computed out the path. * Notification-value=1: LSP path is deleted. When a LSP path is deleted, the PCC SHOULD send a notification message with Notification-type=3 and Notification-value=2 to PCE which computed out the path. Furthermore, the LSP path information SHOULD be contained in PCNtf message so that a PCE can identify which path status changes. For the exsisting ERO object has expressed the path information well, so, it's subobjects ([RFC3209]) can be used in Optional TLVs of NOTIFICATION object. (NOTE: This extension needs to be disscussed.) 5. 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. 6. IANA Consideration TBD. 7. 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. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. Kexin Tang, et al. Expires April 20, 2011 [Page 5] Internet-Draft Statefull PCE Oct 2010 [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. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. 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/ Kexin Tang, et al. Expires April 20, 2011 [Page 6] Internet-Draft Statefull PCE Oct 2010 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/ Kexin Tang, et al. Expires April 20, 2011 [Page 7]