Network Working Group BL. Guo Internet-Draft SG. Huang Intended status: Informational BUPT Expires: April 22, 2011 DJ. Wang ZY. Wang H. Ma ZTE Corporation October 19, 2010 RSVP-TE Extension for path computation based on PCE architecture in inter-layer and inter-domain network draft-guobl-pce-rsvp-00 Abstract The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in multi-domain Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. In this context, the ability to compute Traffic Engineering Label Switched Paths (TE LSPs) in MPLS and GMPLS networks across multiple domains has been identified as a key requirement. This document specifies the routing and wavelength assignment (RWA) procedures and potential extensions for the use of Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling in PCE based MPLS-TE packet networks and GMPLS packet and non-packet networks to support a flexible establishment and maintenance of Label Switched Paths that cross domain boundaries or cross layers. 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 22, 2011. Copyright Notice Guo, et al. Expires April 22, 2011 [Page 1] Internet-Draft RSVP-TE Extension October 2010 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. RWA Mechanisms in PCE based Multi-domain and Multi-layer Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Separated Path Computation Process and RSVP Process with Explicit End to End Route Information . . . . . . . . 4 2.2. Coordinated Path Computation Process and RSVP Process with Loose Route Information . . . . . . . . . . . . . . . 5 3. Detailed Extension for Border Node Procedure . . . . . . . . . 6 4. RSVP-TE Signaling Extensions . . . . . . . . . . . . . . . . . 7 5. PCEP Extension . . . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Attribute Flags for LSP_Attributes Object . . . . . . . . . . 8 8. New Error Codes . . . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 9 10.1. New Flags Of The RP Object . . . . . . . . . . . . . . . . 9 10.2. New Error-Type And Error-Value . . . . . . . . . . . . . . 9 10.3. New Flag Of The NO-PATH-VECTOR TLV . . . . . . . . . . . . 10 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 12. Other Authors . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1. Yongli Zhao . . . . . . . . . . . . . . . . . . . . . . . 10 12.2. Jie Zhang . . . . . . . . . . . . . . . . . . . . . . . . 10 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 13.1. Normative References . . . . . . . . . . . . . . . . . . . 11 13.2. INFORMAL References . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Guo, et al. Expires April 22, 2011 [Page 2] Internet-Draft RSVP-TE Extension October 2010 1. Introduction 1.1. Introduction [RFC4726] defines the framework for inter-domain Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) (inter-area and inter-AS TE), and the technique for establishing an inter-domain Generalized MPLS (GMPLS) TE Label Switched Path (LSP) has been provided by [RFC5152], whereby the path is computed during the signaling process on a per-domain basis by the entry boundary node of each domain (each node responsible for triggering the computation of a section of an inter-domain TE LSP path is always along the path of such TE LSP). The employment of PCE in MPLS and GMPLS multi-domain network provides a great flexibility for routing and resources reserving problem. This document presents the potential integrated routing and singling procedure in PCE based MPLS and GMPLS multi-domain network and defines the RSVP-TE protocol extensions necessary to support the routing and singling approaches of end-to-end inter-domain TE LSP.. Three different signaling methods for inter-domain RSVP-TE signaling are identified in [RFC4726]. Contiguous LSPs are achieved using the procedures of [RFC3209] and [RFC3473] to create a single end-to-end LSP that spans all domains. Nested LSPs are established using the techniques described in [RFC4206] to carry the end-to-end LSP in a separate tunnel across each domain. Stitched LSPs are established using the procedures of [LSP-STITCHING] to construct an end-to-end LSP from the concatenation of separate LSPs each spanning a domain. For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, Interior Gateway Protocol (IGP) routing areas, and GMPLS overlay networks. This document is subject to all the assumption described in RFC5152. Several of the new features described in this document were motivated by the requirements for traffic engineering over MPLS [RFC5441]. 1.2. 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 [RFC2119]. Guo, et al. Expires April 22, 2011 [Page 3] Internet-Draft RSVP-TE Extension October 2010 1.3. Terminology AS: Autonomous System. ASBR: Autonomous System Border Router. A router used to connect together ASs of a different or the same Service Provider via one or more inter-AS links. ERO: Explicit Route Object. LSR: Label Switching Router. TE link: Traffic Engineering link. TED: Traffic Engineering Database. The notion of contiguous, stitched and nested TE LSPs is defined in [RFC4726] and will not be repeated here. 2. RWA Mechanisms in PCE based Multi-domain and Multi-layer Network 2.1. Separated Path Computation Process and RSVP Process with Explicit End to End Route Information In multi-domain and multi-layer network, when the head-end router receives the path computation request, it would communicate with the PCE in its own domain. One possible routing approach is to provide strict hop with ERO of the end-to-end path by cooperation between PCEs with different TE visibility, then start the RSVP singling approach defined in [RFC5151]. In this case, it is not necessary to extend the RSVP with inter- domain extension (RFC5151) and the singling method depends on the configuration of ingress node and intermediate node or other policies applied. Furthermore, the whole resources reservation procedure for such end- to-end path belongs to the same RSVP Session. Guo, et al. Expires April 22, 2011 [Page 4] Internet-Draft RSVP-TE Extension October 2010 End to +-----+ +----+ End LSP Req| |Request | | +--------->| PCE |________\|PCE | | +----->| | /| | | | | |/_______ | | | | +-----+\ +----+ | | Responce| | |Explicit Route | | | | | | | | | | | | Signaling Protocol| | |with Explicit Route| | \ / Information | +---------+ +------+ | +------+ | |-->| | |\ | | |Head-End |---|Border|------ |Border| | Node | | Node |----|/-| Node | +---------+ +------+ | +------+ | Domain 1 | Domain 2 cooperation between different layer or domain 2.2. Coordinated Path Computation Process and RSVP Process with Loose Route Information [RFC5151] defines a per-domain path computation technique for establishing inter-domain TE MPLS and GMPLS LSPs. Per-domain computation applies where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node of the TE LSP, and is not signaled across domain boundaries. After receiving the end-to-end multi-domain or multi-layer path request from any one PCC, an alternative approach of end-to-end path computation is to get a loose route first from the PCE with local visibility (not including the ERO in remote domain), then the singling message which carries the loose hop information arrive the next domain and trigger the intra domain path computation by local PCE (shown in Fig.2) (dynamically computed based on the instant information of the network or static/fixed route). It implies an extension of the RSVP singling message, e.g. including the path computing request information restricted/specified by the head-end node, as well as the message type that could be used to trigger a path computing request. Guo, et al. Expires April 22, 2011 [Page 5] Internet-Draft RSVP-TE Extension October 2010 End to +-------+_Request_\ +------+ End LSP Req| | / | | +------------>| PCE |/__Responce_| PCE | | +-------->| |\ +--->| | | | | | | +--| | | | +-------+ | | +------+ | | | | | | |Loose Route |Seg- | |Explicit | | |ment | |Route | | |LSP | | | | |Req | |Signaling | | Signaling Protocol| | |Protocol | | with Loose Route| | |with Explicit | \ / Information | |\|/RouteInformation +---------+ +-------+ | +-------+ +--------+ | |->| | _|_\ | | | | |Head-End |--| Border| | / |Border |- |Adjacent| | Node | | Node |__|___| Node | | Node | +---------+ +-------+ | +-------+ +--------+ | Domain 1 | Domain 2 cooperation between different layer or domain 3. Detailed Extension for Border Node Procedure The ERO that an ASBR receives in the Path message was supplied by the ingress node of the TE LSP and may have been updated by other nodes (for example, other domain border nodes) as the Path message was propagated. Based on the Separated Path Computation Process and RSVP Process, which carries with Explicit End to End Route Information, it is unnecessary for the Border Nodes to make any additional process except the ERO process described in RFC5151. Actually, the Border Nodes don!_t need to do any path computation related action for the individual resource reservation purpose, without consideration of the path reoptimization and failure crackback. If the ingress node choose coordinated path computation process and RSVP process, which carries with loose hops, and the ERO subobject identifies a TE link formed by the advertisement of an H-LSP or LSP segment (whether numbered or unnumbered), contiguous signaling MUST NOT be used. The node MUST use either nesting or stitching according to the capabilities of the LSP that forms the TE link, the parameters signaled in the Path message, and local policy. If there is a Guo, et al. Expires April 22, 2011 [Page 6] Internet-Draft RSVP-TE Extension October 2010 conflict between the capabilities of the LSP that forms the TE link indicated in the ERO and the parameters on the Path message, the domain border node SHOULD send a PathErr message with error code "Routing Problem"/"ERO conflicts with inter-domain signaling method",. What!_s more, in this case, an ERO in a Path message received by a domain border node may have a loose hop as the next hop. This may be an IP address or an AS number. So, the ERO MUST be expanded to determine the path to the next hop using some form of a path request or path querying message, according to the path computation process applied in the ingress node. The LSP Setup Failure processing, RRO Processing and Notify Message Processing are subject to the definition in [RFC5151]. 4. RSVP-TE Signaling Extensions The following RSVP-TE signaling extensions are defined to enable inter-domain LSP setup in multi-domain and multi-layer MPLS or GMPLS enabled network. In many network environments, there may be a network-wide policy that determines which one of the three inter-domain LSP techniques is used. In these cases, no protocol extensions are required. However, in environments that support more than one technique, an ingress node may wish to constrain the choice made by domain border nodes for each inter-domain TE LSP that it originates. When the ingress node deploys the separated path computation process, contiguous singling scheme would not be supported, and nested or stitched could be chosen freely according to the configuration of node or domain; as the opposite, for coordinated path computation process, it is suitable for contiguous singling scheme. At the ASBR, RSVP message could trigger a path computation request or a routing looking up message to check the static path/route already stored in each PCE. The chosen of message type depends on the constraints in PathReq of ingress node. Also, there already have some definition in RFC5151 for the path request message, but it is necessary to extend for the looking up message. 5. PCEP Extension when PCC submit a path computation request to PCE, the PathReq Guo, et al. Expires April 22, 2011 [Page 7] Internet-Draft RSVP-TE Extension October 2010 message should include the related RWA strategy information, one of which is to return an ERO of the end-to-end path and the other isn!_t (just loose hops). In particular, there are two potential strategies to implement the loose hop option, looking up the static route information but without distributed among the whole network or the path computing dynamically after the reservation singling arrives. 6. IANA Considerations [RFC4420] defines the LSP_Attributes object that can be used to signal required attributes of an LSP. The Attributes Flags TLV includes Boolean flags that define individual attributes. This document defines a new bit in the TLV that can be set by the PCC/head-end router of an inter-domain TE LSP to define the RWA approach:RWA of LSP bit. This flag is set by the PCC/head-end router that originates a Path request to set up an inter-domain TE LSP if it requires that the coordinated path computation and RSVP process with loose hop information This flag bit is only to be used in the Attributes Flags TLV.IANA has made the code point allocations described in the following sections. 7. Attribute Flags for LSP_Attributes Object A new bit has been allocated from the "Attributes Flags" sub-registry of the "RSVP TE Parameters" registry. Bit| Name |Attribute | Path |RRO |Reference No | |Flags Path| Flags Resv| | ---+------+----------+-----------+----+-------- 4 C-LSP Yes No Yes [RFC5150] Attribute Flags for LSP_Attributes Objec 8. New Error Codes New RSVP error codes/values have been allocated from the "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry of the "RSVP Parameters" registry. For the existing error code "Policy control failure" (value 2), two new error values have been registered as follows:103 = Inter-domain Guo, et al. Expires April 22, 2011 [Page 8] Internet-Draft RSVP-TE Extension October 2010 policy failureGBP[not]104 = Inter-domain explicit route rejected For the existing error code "Routing Problem" (value 24), two new error values have been registered as follows:28 = Contiguous LSP type not supportedGBP[not]29 = ERO conflicts with inter-domain signaling method 9. Security Considerations TBD. 10. IANA Consideration 10.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 10.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 Guo, et al. Expires April 22, 2011 [Page 9] Internet-Draft RSVP-TE Extension October 2010 10.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 5 DRPC Path computation chain unavailable this document 11. Acknowledgments The RFC text was produced using Marshall Rose's xml2rfc tool. 12. Other Authors 12.1. Yongli Zhao BUPT No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China +8613811761857 yonglizhao@bupt.edu.cn http://www.zte.com.cn 12.2. Jie Zhang BUPT No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China +8613911060930 Guo, et al. Expires April 22, 2011 [Page 10] Internet-Draft RSVP-TE Extension October 2010 lgr24@bupt.edu.cn http://www.bupt.edu.cn/ 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate Requirement Levels", RFC 2119, March 1997. [RFC4665] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4874] Lee, CY. and S. De , "Exclude Routes Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April 2007. 13.2. INFORMAL References [RFC3209] Awduche, D., "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3473] Berger, L., ""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4206] Kompella, K. and Y. Rekhter., "LSP Hierarchy with Generalized MPLS TE", RFC 4206, October 2005. [RFC4420] Farrel., A., "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE", RFC 4420, February 2006. [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, ovember 2006. [RFC5150] Ayyangar, A., Kompella, K., Vasseur, J., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, February 2008. [RFC5152] Vasseur, J., Ayyangar, A., and R. Zhang, "Extensions to RSVP for LSP Tunnels", RFC 5152, February 2008. Guo, et al. Expires April 22, 2011 [Page 11] Internet-Draft RSVP-TE Extension October 2010 Authors' Addresses Bingli Guo BUPT No.10,Xitucheng Road,Haidian District Beijing 100876 P.R.China Phone: +8613488793951 Email: alonggnola@gmail.com URI: http://www.bupt.edu.cn/ Shangguo 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/ 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/ Zhenyu Wang ZTE Corporation 12/F ZTE Plaza East Huayuan Road, Haidian District Beijing 100191 P.R.China Phone: +8613911266628 Email: wang.zhenyu@zte.com.cn URI: http://www.zte.com.cn/ Guo, et al. Expires April 22, 2011 [Page 12] Internet-Draft RSVP-TE Extension October 2010 Heng Ma ZTE Corporation 12/F ZTE Plaza East Huayuan Road, Haidian District Beijing 100876 P.R.China Phone: +8613366607720 Email: ma.heng@zte.com.cn URI: http://www.zte.com.cn/ Guo, et al. Expires April 22, 2011 [Page 13]