Network Working Group SH. Huang Internet-Draft X. Li Intended status: Informational BUPT Expires: April 21, 2011 DJ. Wang ZTE Corporation WY. Gu BUPT XH. Fu ZTE Corporation October 18, 2010 Extensions to the Path Computation Element Communication Protocol(PCEP) for Crank-back Routing draft-huangshg-pce-crank-back-routing-00 Abstract Path computation in large multi-layer and multi-region networks is complex and may require special computational components and cooperation between different network domains, whereby a failure affect to establish a path or a failure of an existing path may be corrected by a new path computation and fresh signaling. This document specifies the crank-back routing mechanism based on re- routing in crank back Path Computation Element (PCE). When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify Crank-back routing to the path computation, abstract nodes, resources, and domains that are to be explicitly excluded from the computed route. Such mechanism is termed Crank- back routing. The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. To support this mechanism, function of PCE and procedure of PCEP signaling performance are extended. 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." Huang, et al. Expires April 21, 2011 [Page 1] Internet-Draft PCEP Extensions for Crank-back Routing October 2010 This Internet-Draft will expire on April 21, 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Huang, et al. Expires April 21, 2011 [Page 2] Internet-Draft PCEP Extensions for Crank-back Routing October 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Motivation for a Crank-back Routing . . . . . . . . . . . . . 5 5. Protocol Procedures and Extensions . . . . . . . . . . . . . . 5 5.1. Exclude Domain Object (XDO) and Include LSP Object (ILO) . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Relationship to Signaling . . . . . . . . . . . . . . . . 7 6. Practical application . . . . . . . . . . . . . . . . . . . . 7 6.1. Single PCE path computation Environment . . . . . . . . . 7 6.2. Multiple PCE path computation Environment . . . . . . . . 8 6.3. Centralized computation model Environment . . . . . . . . 8 6.4. Distributed computation model Environment . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 9 8.1. New Flags Of The RP Object . . . . . . . . . . . . . . . . 9 8.2. New Error-Type And Error-Value . . . . . . . . . . . . . . 9 8.3. New Flag Of The NO-PATH-VECTOR TLV . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 10. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Other Authors . . . . . . . . . . . . . . . . . . . . 10 A.1. Zhenyu Wang . . . . . . . . . . . . . . . . . . . . . . . 10 A.2. Yongjun Zhang . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Huang, et al. Expires April 21, 2011 [Page 3] Internet-Draft PCEP Extensions for Crank-back Routing October 2010 1. Introduction Crank-back routing is a mechanism whereby a failure affect to establish a path or a failure of an existing path may be corrected by a new path computation and fresh signaling. Crank-back routing relies on the distribution of Crank-back information along with the failure notification so that the new computation can be performed avoiding the failure or blockage point. In the context of Path Computation Element (PCE), Crank-back information may be passed back to the head-end where the process of computation and signaling can be repeated using the failed resource as an exclusion in the computation process. But Crank-back may be used to attempt to correct the problem at intermediate points along the path. Such Crank-back re- computation nodes are most likely to be domain boundaries where the Path Computation Client (PCC) had already invoked a PCE. Thus, a failure within a domain is reported to the ingress domain boundary, which will attempt to compute an alternate path across the domain. Finishing this, the problem may be reported to the previous domain and communicated to the ingress boundary for that domain, which may attempt to select a more successful path either by choosing a different entry point into the next domain, or by selecting a route through a different set of domains. 2. 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]. 3. Terminologies LSR: Label Switching Router. LSP: Label Switched Path. PCC: Path Computation Client. Any client application requesting a path computation to be performed by the Path Computation Element. PCE (Path Computation Element): an entity (component, application or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. TED: Traffic Engineering Database. Huang, et al. Expires April 21, 2011 [Page 4] Internet-Draft PCEP Extensions for Crank-back Routing October 2010 4. Motivation for a Crank-back Routing Several motivations for a Crank-back Routing are listed below.It should be highlighted that the aim of this section is to provide some application examples for which a Crank-back Routing may be suitable: this also clearly states that such a model does not aim to replace existing path computation models but would apply to specific existing or future situations.As can be seen from these examples, Crank-back does not replace the existing Internet model where intelligence is distributed within the network. Instead, it builds on this model and makes use of distributed centers of information or computational ability. 5. Protocol Procedures and Extensions This section describes the procedures adopted by a PCE handling a request for Crank-back routing computation with resources or domain exclusions received from a PCC, and defines how those exclusions are encoded.There are three types of resources or domain exclusion described in. 1. Exclusion of certain abstract nodes or resources from the specific domain. 2. Exclusion of certain domain from the whole path.3. Include of the original LSP.When a specific Label Switched Paths across several domains and the resource in a specific domain collapse, the first step is that the failure notification will send to the head PCE and this PCE calculation a another LSP path avoiding the failure resource across the domain. If the PCE can!_t find the suitable LSP in the failure domain, the Crank-back routing request will dispatch to the previous domain and the PCE in the previous domain is responsible for path calculation.This document defines protocol extensions to allow a PCC to specify both types of resources or domain exclusions and original LSP inclusions to a PCE on a path computation request and allow a PCE to specify domain exclusions and original LSP inclusions to another PCE on a path computation request. A new PCEP object, the Exclude Domain Object (XDO), is defined to convey the Exclude Domain List. Include LSP Object (ILO) is defined to convey the original LSP. The existing Include Route Object (IRO) in PCEP [RFC5440] and Exclude Route Object (XRO) in PCEP [RFC5521] is modified by introducing a new IRO sub- object and a new XRO sub-object to convey Explicit Domain Exclusions and the original LSP. 5.1. Exclude Domain Object (XDO) and Include LSP Object (ILO) Crank-back routing is based on the retrace point-based mechanism. Turn point do not send a path error message to upstream PCE, but reverting directly to the destination node for the residential, so that the connection re-routing, and establish the connection. Huang, et al. Expires April 21, 2011 [Page 5] Internet-Draft PCEP Extensions for Crank-back Routing October 2010 If a label switching path fail because of link or node failure, a new request will again request to PCE to repair label switched path, because the PCC did not know the TED has been updated, the new path request is request to carry these messages. If you want to use the resources of the original LSP as a new request will have an advantage. Therefore, path computation request message must be permitted to identify the requested LSP path is restored, must also support the inclusion of the original LSP and already failed element. A network failure may affect a lot of LSPs, in this case, there will be a lot of PCCs would like to request PCE at the same time. Different levels of LSP will retrace the route using different methods, so that the high-priority LSP would be rapidly recovered. In order to achieve this approach, you must set he appropriate level for each LSP in the PCE and configure the appropriate strategy to accomplish this task. Crank-back routing route can also be used to realize the TE LSP re- optimization, in the new route request contains the original routing path information that will help PCE to avoid double counting to reduce bandwidth congestion issue. The XDO and ILO are carried within Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages. When present in a PCReq message, the XRO provides a list of network domains that the PCE is requested to exclude from the path that it compute, the ILO provides the original LSP that the PCE use to compute a new path containing most of the normal running equipment in the original LSP. Flags associated with each list member instruct the PCE as to whether the domain must be excluded from the computed path and whether the partial LSP must be included in the computed path. The XDO MAY be used on a CRep message that carries the NO-PATH object (i.e., one that reports a path computation failure) to indicate the set of elements of the original XDO that prevented the PCE from finding a path. The XDO MAY also be used on a PCRep message for a successful path computation when the PCE wishes to provide a set of exclusions to be signaled during LSP setup using the extensions to Resource Reservation Protocol (RSVP)-TE [RFC4874]. XDO Body Format is in accordance with the Exclude Route Object (XRO) in PCEP [RFC5521]. Include LSP Object (ILO) defines network elements that must not or should not be used on the path between two PCE. This information is encoded by defining a new sub-object for the ILO. The new ILO sub- object has type 33. The ILO contains one or more sub-objects in its own right. An ILO must not be sent without sub-objects, and if received with no sub-objects, must be ignored.The format of the ILO is as follows: Huang, et al. Expires April 21, 2011 [Page 6] Internet-Draft PCEP Extensions for Crank-back Routing October 2010 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // One or more ILO subobjects // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the ILO L must be set to zero on transmission and must be ignored on receipt. Reserved must be set to zero on transmission and should be ignored on receipt. The ILO sub-object may carry any of the sub-objects defined for inclusion in the ILO by this document or by future documents. The meanings of the fields of the ILO sub-object are unchanged when the sub-object are included in an ILO. 5.2. Relationship to Signaling The inter-domain TE LSP is limited by the signaling methods supported on the intermediate nodes. It is usually the domain border nodes where this restriction applies since other transit nodes are oblivious to the crank-back mechanism in use. The ingress of the LSP may further restrict the choice by setting parameters in the Path message when it is signaled. Determine the signaling method to be used to cross the domain. If the ingress node of the inter-domain TE LSP has specified crank-back restrictions on the methods to be used, these must be adhered to. Within the freedom allowed by the ingress node, the domain border node may choose any method according to local configuration and policies. 6. Practical application 6.1. Single PCE path computation Environment In "single PCE path computation", a single PCE is used to compute a given path in a domain. All LSPs are computed by the single PCE and this PCE make it best effort to find another appropriate LSP when it receive crank-back request which include the XRO and ILO objects, if this PCE can not find the needed LSP, a crank-back request include the XDO and ILO objects is send to the previous domain. Huang, et al. Expires April 21, 2011 [Page 7] Internet-Draft PCEP Extensions for Crank-back Routing October 2010 6.2. Multiple PCE path computation Environment In "multiple PCE path computation", multiple PCEs are used to compute a given path in a domain. In this case, when a PCE send Path Computation Request(PCReq) messages to another PCE and this PCE compute the needed partial path for Previous PCE. After the network run for a period of time, there is a node or link failure in the path which is computed by current PCE, the failure notification is send to the current PCE and the current PCE will make the greatest efforts to compute another path. If the current PCE can!_t find the appropriate path, the Path Computation Request (PCReq) messages including the XRO and ILO objects send to previous PCE, this process continue to execute until the PCE can find the appropriate path to the destination. If all the PCE in this domain can!_t find the appropriate path, the Path Computation Request (PCReq) messages including the XDO and ILO objects send to a PCE which exist in previous domain. The PCE in the previous domain will choose another gateway node or choose another domain to establish the LSP. 6.3. Centralized computation model Environment "Centralized computation model" refers to a model whereby all paths in a domain are computed by a single, centralized PCE. There may be multiple PCEs in a domain, but only one PCE per domain is involved in any single path computation. Because there is only one PCE participate in the LSP compute, the Crank-back routing request will be send to the arbitrary PCE and the Path Computation Request (PCReq) messages include the XRO and ILO objects. 6.4. Distributed computation model Environment "Distributed computation model" refers to the computation of paths in a domain being shared among multiple PCEs. Paths that span multiple domains may be computed using the distributed model with one or more PCEs responsible for each domain, or the centralized model by defining a domain that encompasses all the other domains. From these definitions, a centralized computation model inherently uses single PCE path computation. However, a distributed computation model could use either single PCE path computation or multiple PCE path computations. There would be no such thing as a centralized model that uses multiple PCEs. 7. Security Considerations Crank-back Routing may raise new security issues when PCE-PCE communication is done between different region networks for inter- region path computation. Security issues may also exist when a Huang, et al. Expires April 21, 2011 [Page 8] Internet-Draft PCEP Extensions for Crank-back Routing October 2010 single PCE is granted full visibility of TE information that applies to multiple areas. It is expected that solutions for inter-region protocol extensions will address these issues in detail using security techniques such as authentication. 8. IANA Consideration 8.1. New Flags Of The RP Object A new flag of the RP object is defined in this document, which contains 2 bits. VSPG Flags Bit Number Name Flag Reference 23 VSPG 24 0: from source PCE to middle PCE this document 1: from destination PCE to middle PCE Bit 24 is valid under the assumption that bit 23 is valid 8.2. New Error-Type And Error-Value A new Error-Type is defined in this document (Error-Type and Error- value to be assigned by IANA). Error-type Meaning Reference 14 DRPC procedure completion failure this document Error-value 1: DRPC procedure not supported by one or more PCEs along the domain path 8.3. New Flag Of The NO-PATH-VECTOR TLV A new flag of the NO-PATH-VECTOR TLV defined in is specified in this document. Bit number Name Flag Reference Huang, et al. Expires April 21, 2011 [Page 9] Internet-Draft PCEP Extensions for Crank-back Routing October 2010 5 DRPC Path computation chain unavailable this document 9. Acknowledgments The RFC text was produced using Marshall Rose's xml2rfc tool. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate Requirement Levels", RFC 2119, March 1997. [RFC4874] Lee, CY. and S. De , "Exclude Routes Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April 2007. [RFC5440] Vasseur, JP. and Ed. JL., "Path Computation Element (PCE) Communication Protocol(PCEP)", RFC 5440, March 2009. [RFC5521] Oki, E. and T. Takeda, "Extensions to the Path Computation Element Communication Protocol(PCEP) for Route Exclusions", RFC 5521, April 2009. Appendix A. Other Authors A.1. Zhenyu Wang ZTE Corporation 12/F ZTE Plaza East Huayuan Road, Haidian District Beijing 100191 P.R.China +8613911266628 wang.zhenyu@zte.com.cn http://www.zte.com.cn Huang, et al. Expires April 21, 2011 [Page 10] Internet-Draft PCEP Extensions for Crank-back Routing October 2010 A.2. Yongjun Zhang BUPT No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China +8613366308960 yjzhang@bupt.edu.cn http://www.bupt.edu.cn/ Authors' Addresses Shanguo Huang BUPT No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China Phone: +8613693578265 Email: shghuang@bupt.edu.cn URI: http://www.bupt.edu.cn/ Xin li BUPT No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China Phone: +8613426082735 Email: xinli@bupt.edu.cn URI: http://www.bupt.edu.cn/ Huang, et al. Expires April 21, 2011 [Page 11] Internet-Draft PCEP Extensions for Crank-back Routing October 2010 Dajiang Wang ZTE Corporation 12/F ZTE Plaza East Huayuan Road, Haidian District Beijing 100191 P.R.China Phone: +8613811795408 Email: wang.dajiang@zte.com.cn URI: http://www.zte.com.cn/ Wanyi Gu BUPT No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China Phone: +8613371692708 Email: wyg@bupt.edu.cn URI: http://www.bupt.edu.cn/ Xihua Fu ZTE Corporation West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District Xi'an 710065 P.R.China Phone: +8615802921223 Email: fu.xihua@zte.com.cn URI: http://www.zte.com.cn/ Huang, et al. Expires April 21, 2011 [Page 12]