Network Working Group Kexin Tang Internet-Draft Xuerong Wang Intended status: Informational Xuping Cao Expires: May 3, 2012 ZTE Corporation Oct 31, 2011 Stateful PCE draft-tang-pce-stateful-pce-02.txt Abstract A PCE can be either stateful or stateless. The information carried in a stateful PCE is more detailed than that of a stateless PCE. This draft focus on stateful PCE, describes the problems without stateful PCE, and gives the IGP and PCEP extensions to realize 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 May 3, 2012. Copyright Notice Copyright (c) 2011 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 the Trust Legal Provisions and are provided without warranty as Kexin Tang, et al. Expires May 3, 2012 [Page 1] Internet-Draft Stateful PCE Oct 2011 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . . 5 4.1. PCED Extensions . . . . . . . . . . . . . . . . . . . . . . 5 4.2. LSP State Synchronization . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 7 7. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Kexin Tang, et al. Expires May 3, 2012 [Page 2] Internet-Draft Stateful PCE Oct 2011 1. Introduction As defined in section 6.8 of [RFC4655], a PCE can be either stateful or stateless. For stateful PCE, there is a strict synchronization between the PCEs 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. However, the existing PCE discovery protocol ([RFC5088], [RFC5089]) and PCEP ([RFC5440]) do not support stateful PCE. And there is no effective synchronization mechanism defined to realize stateful PCE yet. For these sufficient reasons, 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. Problems This section lists the typical problems without stateful PCE. As described in [RFC4655], stateful PCE uses information not only from the TED, but also information about existing paths (for example, TE LSPs) in the network when processing new requests, so the information Kexin Tang, et al. Expires May 3, 2012 [Page 3] Internet-Draft Stateful PCE Oct 2011 carried in stateful PCE are more detailed than that of stateless PCE. Without stateful PCE, there would not be a strict synchronization between PCE and LSP state. Consequently,the PCE may not know the existing path in the network in time,and suppose the network resource taken by the existing path is unoccupied, so it would consider these resource in the other path computations. Resource conflict occurs under this condition. A PCE may received several PCReq messages, this may occurs when a PCE is required to compute a large number of path for several LSPs,for example when fiber cutting happened or in a sudden accident,which may result in a large number of links down simultaneity,and need to be recovery in a short time. Figure 1 shows a demonstration topology for the subsequent context. +-----+ +-----+ | A |---------------| B | +-----+ +-----+ \ / \ / +-----+ | C | +-----+ Figure 1: demonstration topology In Figure1,we make the assumptions as follows:the link capacity between all these three nodes is 100M,and the node that hosts the PCE function received a PCReq massage,which required it to compute paths for two LSP respectively:LSP1 and LSP2. LSP1 and LSP2 share the same original and terminal node pair,that is from node A to node B,and require the same link bandwidth:80M. For LSP 1,to get a shortest path,the PCE may return a path:A--B,while the computation result is not synchronized in its TED in time,the PCE assume the unreserved bandwidth of the link between A and B is still 100M. Then for LSP2,which require 80M link capacity either,the PCE may still consider the shortest path,that is A--B as before,and it seems that in the TED currently,this shortest path has enough capacity for LSP2,so the PCE returns the optimal path A--B for LSP2. Once the LSP setup procedure by signaling for LSP1 and LSP2 is running,the setup procedure for the first LSP would successful, while Kexin Tang, et al. Expires May 3, 2012 [Page 4] Internet-Draft Stateful PCE Oct 2011 the latter one would encounter resource conflict:there would not be enough link capacity for the LSP to be setup,and it would return a signaling failure notification message. As for Inter-area or Inter-AS path computation for a LSP, it is often involved in multiple PCEs cooperation to compute an end-to-end path, for example, BRPC ([RFC5441]) and H-PCE ([H-PCE-FWK]). Resource conflict would even worse in this situation because it takes extra time for communication between the cooperative PCEs. 4. Protocol Extensions 4.1. PCED Extensions [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 the capabilities of a PCE. It contains eight capabilities currently, but not includes the stateful capability of a PCE. So the PCE in an OSPF routing domain cannot advertise its state capability information to a PCC,which would help the PCC to make advanced and informed choices in PCE selection. To discover stateful PCE, a PCC SHOULD know whether PCE is stateful. Therefore, the PCE discovery message SHOULD indicate whether the PCE advertising 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 TBD Stateful PCE 4.2. LSP State Synchronization With respect to the definition of stateful PCE defined in [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 path computation requests. Therefore, a stateful PCE SHOULD know the status (created or deleted) of a LSP. For this reason, there SHOULD be a timely synchronization of LSP state between PCC and PCE, including the path computation result, and the LSP setup or deletion result. For this purpose, this section Kexin Tang, et al. Expires May 3, 2012 [Page 5] Internet-Draft Stateful PCE Oct 2011 makes an extension to the PCNtf message defined in [RFC5440], defines a new Notification-type as follows (need to be assigned by IANA): o Notification-type=TBD: LSP Status * Notification-value=1: end-to-end path computation success(This value is available for distributed path computation only). When a optimal end-to-end path is computed successfully, the head-end PCE SHOULD send a notification message with Notification-type=TBD and Notification-value=1 to the other PCEs collaboratively in the PCE chain which computed the other path segments successfully. * Notification-value=2: end-to-end path computation failure(This value is available for distributed path computation only). If an end-to-end path computation is failed,the head-end PCE SHOULD send a notification message with Notification-type=TBD and Notification-value=2 to the other PCEs collaboratively in the PCE chain which computed the other path segments successfully. * Notification-value=3: LSP setup success. When a LSP is created successfully by signaling, the PCC SHOULD send a notification message with Notification-type=TBD and Notification-value=3 to all the PCEs. * Notification-value=4: LSP setup failure. When a LSP is failed to setup by signaling, the PCC SHOULD send a notification message with Notification-type=TBD and Notification-value=4 to all the PCEs. * Notification-value=5: LSP delete success. When a LSP is delete in the network successfully, the PCC SHOULD send a notification message with Notification-type= TBD and Notification-value=5 to all the PCEs. * Notification-value=6: LSP delete failure . When a LSP path is failed to delete, the PCC SHOULD send a notification message with Notification-type= TBD and Notification-value=6 to all the PCEs. This draft extended the PCNtf message, added the Path object which defined for PCRep message [RFC5440] to the PCNtf message ,to identify the ERO and the attribute of a LSP. The format of the extended PCNtf message is as follows: Kexin Tang, et al. Expires May 3, 2012 [Page 6] Internet-Draft Stateful PCE Oct 2011 ::= ::= [] ::= [] ::= [] ::= where: ::=[] [] [] [] ::=[] With the newly added Path object which carries the ERO object and the attribute of a LSP,a PCE can identifies the status of which LSP changes,and the information of the LSP, so as to identifies the resource that taken by the LSP. 5. Security Considerations The extensions of this draft are based on PCEP and OSPF, only some optional protocol elements are added which will not change the security of existing network. 6. IANA Consideration 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. Normative References [H-PCE-FWK] Daniel King, Adrian Farrel, Quintin Zhao, and Fatai Zhang, Kexin Tang, et al. Expires May 3, 2012 [Page 7] Internet-Draft Stateful PCE Oct 2011 "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", draft-ietf-pce-hierarchy-fwk-00.txt . [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. [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. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009. Authors' Addresses Kexin Tang ZTE Corporation No.50 Software Avenue, Yuhuatai District Nanjing, Jiangsu 210012 P.R.China Phone: +86-025-88014225 Email: tang.kexin@zte.com.cn Kexin Tang, et al. Expires May 3, 2012 [Page 8] Internet-Draft Stateful PCE Oct 2011 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 Xuping Cao ZTE Corporation 21F, ZTE Plaza, No.19 East Huayuan Road,Haidian District Beijing 100191 P.R.China Email: cao.xuping@zte.com.cn Kexin Tang, et al. Expires May 3, 2012 [Page 9]