Network Working Group Xian Zhang Internet-Draft Young Lee Intended status: Standards Track Huawei Ramon Casellas CTTC Oscar Gonzalez de Dios Telefonica I+D Expires: January 07, 2013 July 07, 2012 Path Computation Element (PCE) Protocol Extension for Stateful PCE Usage in GMPLS Networks draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 07, 2013. Abstract Zhang Expires January 2013 [Page 1] draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012 The Path Computation Element (PCE) facilitates Traffic Engineering (TE) based path calculation in large, multi-domain, multi-region, or multi-layer networks. PCE can be stateless or stateful. With the LSP state information acquired from the network, a stateful PCE exhibits superiority in facilitating a wide variety of applications, especially in GMPLS networks, such as impairment-aware routing and wavelength assignment in wavelength-switched optical networks (WSON), time-based scheduling applications. This memo provides extensions required for PCE communication protocol (i.e. PCEP) so as to enable the usage of a stateful PCE capability in GMPLS networks. To be more specific, the PCEP extensions specified in this memo include not only new objects but also modification of existing objects in PCEP messages, with regard to stateful PCE usage in GMPLS networks. 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 RFC-2119 [RFC2119]. Table of Contents Table of Contents .............................................. 2 1. Introduction ................................................ 3 2. PCEP Extensions ............................................. 4 2.1. Overview ............................................... 4 2.2. PCEP Extension for Stateful PCE Capability Advertisement and Negotiation ................................................. 4 2.2.1. PCE Capability Negotiation/Advertisement in Multi-layer Networks ................................................. 5 2.3. LSP Delegation ......................................... 5 2.4. PCEP Extensions for LSP Synchronization .................6 2.5. PCEP Simplification .....................................6 2.6. Application-specific PCEP extensions for stateful PCE....7 2.6.1. Time-based Scheduling.............................. 7 2.6.1.1. PCEP Extension................................ 8 2.6.2. RWA in Impairment-aware Wavelength-switched Optical Networks (WSON) .......................................... 9 3. IANA Considerations ........................................ 10 3.1. LayerCapability TLV.................................... 10 3.2. SERVICE-TIME Object.................................... 10 3.3. Extension to METRIC Object............................. 10 4. Manageability Considerations................................ 10 5. Security Considerations..................................... 11 6. References ................................................. 11 6.1. Normative References................................... 11 6.2. Informative References................................. 11 Zhang Expires January 2013 [Page 2] draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012 7. Contributors' Address....................................... 12 Authors' Addresses ............................................ 13 1. Introduction [RFC 4655] presents the architecture of a Path Computation Element (PCE)-based model for computing Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs). To perform such a constrained computation, a PCE stores the network topology (i.e., TE links and nodes) and resource information (i.e., TE attributes) in its TE Database (TED). To request path computation services to a PCE, [RFC 5440] defines the PCE Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. A PCC can initiate a path computation request to a PCE through a Path Computation Request (PCReq) message, and then the PCE will return the computed route to the requesting PCC in response to a previously received PCReq message through a PCEP Path Computation Reply (PCRep) message. As per [RFC 4655], a PCE can be stateless or stateful. Compared to a stateless PCE, a stateful PCE stores not only the network state, but also the set of computed paths and reserved resources in use in the network. Note that [RFC4655] further specifies that the TED contains link state and bandwidth availability as distributed by IGPs or collected via other means. Even if such information can provide finer granularity and more details, it is not state information in the PCE context and so a model that uses it is still described as a stateless PCE. Stateful PCE(s) are shown to be helpful in many application scenarios, especially in GMPLS networks, as illustrated in [Stateful-APP]. In order for these applications to able to exploit the capability of stateful PCE(s), extensions to the PCE communication protocol (i.e., PCEP) are required. It is expected that there are common aspects for stateful PCE PCEP extension in GMPLS networks with that in MPLS networks [Stateful- PCE]. Therefore, this document focuses on the extensions unique to GMPLS networks while maintains a complete picture of the PCEP extensions required for a stateful PCE. In summary, this draft gives an overview of PCEP extensions necessary for stateful PCE usage in GMPLS networks as well as the details of required PCEP extension unique to stateful PCE usage in GMPLS networks. Zhang Expires January 2013 [Page 3] draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012 2. PCEP Extensions 2.1. Overview According to the description in [Stateful-APP], a summary of PCEP extensions required for stateful PCE in GMPLS networks is provided as follows: o Advertisement and negotiation of stateful PCE capability; o LSP synchronization; These two are fundamental extension requirements needed in order to make a stateful PCE functional. Attention should be paid in terms of the general considerations as discussed in [Stateful-APP]. Since the extensions to these two aspects are straightforward and have already been covered in [Stateful-PCE], we only cover the points that are either relevant to GMPLS or still missing in [Stateful-PCE]. o LSP Delegation; As explained in [Stateful-APP], the ability to collect LSP state information should be mandatory. As for PCE's ability to modify the LSP attributes as presented in [Stateful-PCE] as well as how it is enabled (per PCE base, per LSP base, or per NE base?) should be operator-dependent and is for further study. o Simplification of the existing PCEP protocol [RFC5440]; Since the LSP state is part of the information that a stateful PCE possesses, some simplifications to PCEP are possible and explained in this draft. o Application-specific extensions desired; A list of examples is provided in [Stateful-APP] and they may require additional extensions or modification of the PCEP protocol. In this draft, we present the PCEP extensions for some typical application examples. 2.2. PCEP Extension for Stateful PCE Capability Advertisement and Negotiation Whether a PCE has the stateful capability or not can be negotiated during the PCEP session establishment process. It can also be advertised through routing protocols as described in [RFC5088]. In either case, the following additional aspects should also be considered. Zhang Expires January 2013 [Page 4] draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012 2.2.1. PCE Capability Negotiation/Advertisement in Multi-layer Networks In multi-layer network scenarios where there is a PCE responsible for each layer, then the PCCs should be informed of which PCE they should synchronize their LSP states with as well as send path computation requests to. A new LayerCapability TLV is defined as shown below to denote to which layer a PCE is in charge of LSP synchronization as well as path computation. It can be included in the OPEN Object if applicable. Alternatively, the extension to current OSPF PCED TLV is needed. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (T.B.D.) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Enc. Type | Switching Type| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Enc. Type | Switching Type| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.3. LSP Delegation If a LSP span across multiple domains and the delegation features presented in [Stateful-PCE] is supported, it adds complexity to LSP state synchronization/update. For instance, in a multi-domain networks where one PCE per domain is adopted, a contiguous LSP is setup which spans across multiple domains. Then, each PCE is responsible for synchronizing/updating or is able to modify only part of the LSP within the network for which the PCE is deployed. Moreover, a modification action of a stateful PCE for partial LSP may trigger a chain of LSP updating actions (e.g., informing other PCEs of the modification or requesting other PCEs of additional modification). This needs to be considered carefully and modification capability specifications might be needed to limit the scope of LSP attribute modification action to avoid conflicts(?). Zhang Expires January 2013 [Page 5] draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012 [Editor Note: this needs clarification and further discussion. The scenario with mixed stateful/stateless PCE might also cause potential issues for LSP delegation ability.] 2.4. PCEP Extensions for LSP Synchronization For LSP state synchronization of stateful PCE(s) in GMPLS networks, the LSP attributes, such as its bandwidth, associated label as well as protection information etc, should be updated by PCC(s) to PCE LSP database (LSP-DB). As per [Stateful-PCE], it only covers LSP attributes pertaining to MPLS networks, based on [RFC5440]. Therefore, extensions of PCEP protocol for stateful PCE usage in GMPLS networks are required. The following presents a list of objects/TLVs that should be used by stateful PCE for LSP synchronization purpose when applied in GMPLS networks: o GENERALIZED BANDWIDTH o PROTECTION ATTRIBUTE o Extended Objects to support the inclusion of label sub-object - RP - IRO - XRO Note that the list above should also be used for path computation requests/replies. Refer to [PCEP-GMPLS] for the details of these objects/TLVs. 2.5. PCEP Simplification One of the merits mentioned in [Stateful-APP] is its ability to simplify the information exchange between PCC and PCE. To be more specific, with a stateful PCE, it is possible for PCCs to carry only LSP ID information, instead of giving detailed LSP information (such as route), whenever necessary. Example 1: a PCC (e.g. NMS) requesting for a re-optimization of several LSPs, it can send the request with relevant LSP IDs. In order to support these, the LSP identifier TLV defined in [Stateful-PCE] can be used in the RP Object to specify the request LSP ID(s). Upon receiving the PCReq message, PCE should be able to Zhang Expires January 2013 [Page 6] draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012 correlate with one or multiple LSPs with their detailed state information and carry out optimization accordingly. Example 2: in order to set up a LSP which is diversified with one or more specific LSPs, a PCC can send a PCReq with the ID of these LSPs. A stateful PCE should be able to find the corresponding route and resource information so as to meet the constraints set by the requesting PCC. In order to support this, a new subobject type should be supported, i.e. LSP ID(s). Hence, the LSP identifier TLV defined in [Stateful- PCE] can be used in XRO object for this purpose. 2.6. Application-specific PCEP extensions for stateful PCE [Editor's Note: this is not a complete list of application-specific PCEP extensions. Suggestions are welcome on expansion on this section.] 2.6.1. Time-based Scheduling To support time-based scheduling, network operators need to reserve resources in advance according to customers' requests with specified starting time and duration. A simple utilization example of this service is to support scheduled data transmission between data centers or any generic scheduled based services. Traditionally, this can be supported by NMS operation through path pre-establishment and activation on the agreed starting time. However, this does not provide efficient network usage since the established paths exclude the possibility of being used by other services even when they are not used for undertaking any service due to the lack of a time-based mechanism. It can also be accomplished through GMPLS protocol extensions by carrying the related request information (e.g., starting time and duration) across the network. Nevertheless, this method inevitably increases the complexity of signaling and routing process. Since a stateful PCE needs to collect LSP related information for the whole network, it can naturally support this service with resource usage flexibility (i.e., only excluding the time slot(s) reserved for time-based scheduling requests). Moreover, it can avoid the need to add complexity on network elements in this regard. A stateful PCE should also maintain a database that stores all the reserved information with time reference. This can be achieved either by maintaining a separate database or having all the reserved information with time reference incorporated into LSP-DB. The details of organizing time-based scheduling related information are Zhang Expires January 2013 [Page 7] draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012 subject to network provider's policy and administrative consideration and thus outside of the scope of this document. 2.6.1.1. PCEP Extension For a PCC to request a path computation for scheduled service, it MUST be able to specify the time-related information, including the starting time and LSP holding time, in PCEP request. A SERVICE-TIME object is presented as follows to provide the required information (i.e. service starting time and holding time). The Object-Class is TBD and the Object-Type is 1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start-Year | Month | Day | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hour | Minute | Second | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duration (in seconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ field Length range ----- ------ -------- Start-Year 16 bit 0..65536 Month 8 bit 1..12 Day 8 bit 1..31 Hour 8 bit 0..23 Minute 8 bit 0..59 Second 8 bit 0..59 The SERVICE-TIME object can be included in a PCEP request as specified in the following manner: ::= [] Zhang Expires January 2013 [Page 8] draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012 Where: []::= [] ::=[] ::= [] [] [] [] [[]] [] [] WHERE: ::=[] Upon receiving the PCReq message, PCE should compute the path taking into consideration the constraints of the TED, LSP-DB as well as other scheduled service information and return the computed route back to the requesting PCC. If no path can be found, PCE should return an error message specifying the reason. 2.6.2. RWA in Impairment-aware Wavelength-switched Optical Networks (WSON) In impairment-ware WSON networks, the routing and wavelength assignment process needs to consider the constraints incurred by the physical impairments. As described in [Stateful-APP], stateful PCE can effectively reduce the control plane overhead by centrally maintaining the impairment-information related to each LSP. Zhang Expires January 2013 [Page 9] draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012 In order to establish an impairment-aware LSP, a path computation request may need to specify the desired values and/or constraints for one or more of the following parameters: o Power o OSNR o PMD o T.B.D. Upon receiving the path computation request, a stateful PCE should take into consideration the explicitly defined constraints as well as those of the existing LSPs, stored in LSP-DB. Furthermore, a PCE may need to reply in PCRep with the actual values of the one or more of the above-mentioned parameters to the requesting PCC as well as the adjustment needed. After receiving the reply message, the PCC can take appropriate actions along the to-be-established paths in tuning its power or changing other impairment-related parameters so as to achieve the desired signal quality. To support the above-mentioned requirements, the METRIC object defined in [RFC5440] can be exploited with proper extension. A new type value should be added. T=T.B.D.: Impairment-aware information Furthermore, as described in [PCE-IA-WSON], there are two types of parameters that can be specified, i.e. path level or link level. If a stateful PCE needs to reply with adjustment needed for path level parameters. Then further extension to the METRIC object is desirable and this will be considered in the future. 3. IANA Considerations IANA is requested to allocate new Types for the TLV/Object defined in this document. 3.1. LayerCapability TLV 3.2. SERVICE-TIME Object 3.3. Extension to METRIC Object 4. Manageability Considerations TBD. Zhang Expires January 2013 [Page 10] draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012 5. Security Considerations TBD. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirements levels", RFC 2119, March 1997. [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC5088] Le Roux, JL., Vasseur, J.-P., Ikejiri, Y., Zhang, R., ''OSPF Protocol Extensions for Path Computation Element (PCE) Discovery'', RFC 5088, January 2008. 6.2. Informative References [Stateful-APP] Zhang, F., Zhang, X., Lee, Y., Casellas, R., Gonzalez de Dios, O., "Applicability of Stateful Path Computation Element (PCE) ", draft-zhang-pce-stateful-pce-app, work in progress. [Stateful-PCE]Crabbe, E., Medved, J., Varga, R., Minei, I., ''PCEP Extensions for Stateful PCE'', draft-ietf-pce-stateful-pce, work in progress. [PCE-IA-WSON] Lee, Y., Bernstein G., Takeda, T., Tsuritani, T., ''PCEP Extensions for WSON Impairments'', draft-lee-pce- wson-impairments, work in progress. [PCEP-GMPLS] Margaria, C., Gonzalez de Dios, O., Zhang, F., ''PCEP extensions for GMPLS'', draft-ietf-pce-gmpls-pcep- extensions, work in progress. Zhang Expires January 2013 [Page 11] draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012 7. Contributors' Address Dhruv Dhody Huawei Technology Leela Palace Bangalore, Karnataka 560008 INDIA EMail: dhruvd@huawei.com Zhang Expires January 2013 [Page 12] draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012 Authors' Addresses Xian Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972913 Email: zhang.xian@huawei.com Young Lee Huawei 1700 Alma Drive, Suite 100 Plano, TX 75075 US Phone: +1 972 509 5599 x2240 Fax: +1 469 229 5397 EMail: ylee@huawei.com Ramon Casellas CTTC - Centre Tecnologic de Telecomunicacions de Catalunya Av. Carl Friedrich Gauss n7 Castelldefels, Barcelona 08860 Spain Phone: Email: ramon.casellas@cttc.es Oscar Gonzalez de Dios Telefonica Investigacion y Desarrollo Emilio Vargas 6 Madrid, 28045 Spain Phone: +34 913374013 Email: ogondio@tid.es Intellectual Property Zhang Expires January 2013 [Page 13] draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012 The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. Disclaimer of Validity All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION Zhang Expires January 2013 [Page 14] draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt July 2012 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Full Copyright Statement Copyright (c) 2012 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. Zhang Expires January 2013 [Page 15]