Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS-controlled Networks
The information below is for an old version of the document.
This is an older version of an Internet-Draft whose latest revision state is "Active".
|Authors||Xian Zhang , Young Lee , Fatai Zhang , Ramon Casellas , Oscar Gonzalez de Dios , Zafar Ali|
|RFC stream||Internet Engineering Task Force (IETF)|
RTGDIR Early review (of -19) Has Nits
|Additional resources||Mailing list discussion|
|Stream||WG state||WG Document|
|IESG||IESG state||I-D Exists|
|Send notices to||(None)|
PCE Working Group Xian Zhang Internet-Draft Young Lee Intended status: Standards Track Fatai Zhang Huawei Ramon Casellas CTTC Oscar Gonzalez de Dios Telefonica I+D Zafar Ali Cisco Systems Expires: January 05, 2016 July 06, 2015 Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS-controlled Networks draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt Abstract The Path Computation Element (PCE) facilitates Traffic Engineering (TE) based path calculation in large, multi-domain, multi-region, or multi-layer networks. The PCE communication Protocol (PCEP) has been extended to support stateful PCE functions where the PCE retains information about the paths already present in the network, but those extensions are technology-agnostic. This memo provides extensions required for PCEP so as to enable the usage of a stateful PCE capability in GMPLS-controlled networks. 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 Zhang et al Expires January 2016 [Page 1] draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt July 2015 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 5, 2016. Copyright Notice Copyright (c) 2015 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. 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 ............................................. 3 2.1. Overview of Requirements................................ 3 2.2. LSP Delegation in GMPLS-controlled Networks ............. 4 2.3. LSP Synchronization in GMPLS-controlled Networks......... 5 2.4. Modification of Existing PCEP Messages and Procedures.... 6 2.4.1. Modification for LSP Re-optimization ............... 6 2.4.2. Modification for Route Exclusion ................... 7 2.5. Object Encoding......................................... 8 3. IANA Considerations ......................................... 8 Zhang et al Expires January 2016 [Page 2] draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt July 2015 3.1. New PCEP Error Codes.................................... 8 3.2. New Subobject for the Exclude Route Object ..............9 4. Manageability Considerations................................. 9 4.1. Requirements on Other Protocols and Functional Components 9 5. Security Considerations...................................... 9 6. Acknowledgement ............................................. 9 7. References ................................................. 10 7.1. Normative References................................... 10 7.2. Informative References................................. 10 8. Contributors' Address....................................... 10 Authors' Addresses ............................................ 12 1. Introduction [RFC4655] 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). Such a PCE is usually referred as a stateless PCE. To request path computation services to a PCE, [RFC5440] defines the PCE communication Protocol (PCEP) for interaction between a Path Computation Client (PCC) and a PCE, or between two PCEs. PCEP as specified in [RFC 5440] mainly focuses on MPLS networks and the PCEP extensions needed for GMPLS-controlled networks are provided in [PCEP-GMPLS]. Stateful PCEs are shown to be helpful in many application scenarios, in both MPLS and GMPLS networks, as illustrated in [Stateful-APP]. Further discussion of concept of a stateful PCE can be found in [RFC7399]. In order for these applications to able to exploit the capability of stateful PCEs, extensions to PCEP are required. [Stateful-PCE] provides the fundamental extensions needed for stateful PCE to support general functionality, but leaves out the specification for technology-specific objects/TLVs. This document focuses on the extensions that are necessary in order for the deployment of stateful PCEs in GMPLS-controlled networks. 2. PCEP Extensions 2.1. Overview of Requirements Zhang et al Expires January 2016 [Page 3] draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt July 2015 This section notes the main functional requirements for PCEP extensions to support stateful PCE for use in GMPLS-controlled networks, based on the description in [Stateful-APP]. Many requirements are common across a variety of network types (e.g., MPLS-TE networks and GMPLS networks) and the protocol extensions to meet the requirements are already described in [Stateful-PCE]. This document does not repeat the description of those protocol extensions. This document presents protocol extensions for a set of requirements which are specific to the use of a stateful PCE in a GMPLS-controlled network. The basic requirements are as follows: o Advertisement of the stateful PCE capability. This generic requirement is covered in Section 7.1.1. of [Stateful-PCE]. This document does not provide any further extensions. o LSP delegation is already covered in Section 5.5. of [Stateful- PCE]. Section 2.3. of this document provides extension for its application in GMPLS-controlled networks. Moreover, further discussion of some generic details that need additional consideration is provided. o LSP state synchronization and LSP state report. This is a generic requirement already covered in Section 5.4. of [Stateful-PCE]. However, there are further extensions required specifically for GMPLS-controlled networks and discussed in Section 2.4. Reference to LSPs by identifiers is discussed in Section 7.3. of [Stateful- PCE]. This feature can be applied to reduce the data carried in PCEP messages. Use cases and additional Error Codes are necessary, as described in Section 2.5. of this document. 2.2. LSP Delegation in GMPLS-controlled Networks [Stateful-PCE] defines the Path Computation LSP Update Request (PCUpd) message to enable to update the attributes of an LSP. However, that document does not define technology-specific parameters. A key element of the PCUpd message is the attribute-list construct defined in [RFC5440] and extended by many other PCEP specifications. For GMPLS purposes we note that the BANDWIDTH object used in the attribute-list is defined in [PCEP-GMPLS]. Furthermore, additional TLVs are defined for the LSPA object in [PCEP-GMPLS] and MAY be included to indicate technology-specific attributes. Zhang et al Expires January 2016 [Page 4] draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt July 2015 LSP parameter update controlled by a stateful PCE in a multi-domain network is complex and requires well-defined operational procedures as well as protocol design and is out of scope of this document and left for further study. 2.3. LSP Synchronization in GMPLS-controlled Networks PCCs need to report the attributes of LSPs to the PCE to enable stateful operation of a GMPLS network. This process is known as LSP state synchronization. The LSP attributes include bandwidth, associated route, and protection information etc., are stored by the PCE in the LSP database (LSP-DB). Note that, as described in [Stateful-PCE], the LSP state synchronization covers both the bulk reporting of LSPs at initialization as well the reporting of new or modified LSP during normal operation. Incremental LSP-DB synchronization may be desired in a GMPLS-controlled network and it is specified in [Sync-OPT]. [Stateful-PCE] describes mechanisms for LSP synchronization using the Path Computation State Report (PCRpt) message, but does not cover reporting of technology-specific attributes. As stated in [Stateful-PCE], the <path> construct is further composed of a compulsory ERO object and a compulsory attribute-list and a optional RRO object. In order to report LSP states in GMPLS networks, this specification allows the use within a PCRpt message of technology- and GMPLS-specific attribute objects and TLVs defined in [PCEP-GMPLS] as follows: o Extensions to the ERO, RRO, IRO, and XRO to carry label sub- objects for SDH/SONET, OTN, and DWDM networks. o Extended objects to support the inclusion of the label and unnumbered links. o END-POINTS (Generalized END-POINTS Object Type) o BANDWIDTH (Generalized BANDWIDTH Object Type) o PROTECTION ATTRIBUTE TLV o IF_ID_ERROR_SPEC (extending [Stateful-PCE] section 7.3.4 that only considers the use of RSVP ERROR_SPEC) The END-POINTS object SHOULD be carried within the attribute-list to specify the endpoints pertaining to the reported LSP. The XRO object MAY be carried to specify the network resources that the reported LSP avoids and a PCE SHOULD consider avoid these network resources Zhang et al Expires January 2016 [Page 5] draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt July 2015 during the process of re-optimizing after this LSP is delegated to the PCE. To be more specific, the <attribute-list> is updated as: <attribute-list> ::= [<END-POINTS>] [<LSPA>] [<BANDWIDTH>] [<metric-list>] [<IRO>] [<XRO>] <metric-list>::= <METRIC>[<metric-list>] If the LSP being reported protects another LSP, the PROTECTION- ATTRIBUTE TLV [PCEP-GMPLS] MUST be included in the LSPA object to describe its attributes and restrictions. Moreover, if the status of the protecting LSP changes from non-operational to operational, this SHOULD to be synchronized to the stateful PCE using a PCRpt message. 2.4. Modification of Existing PCEP Messages and Procedures One of the advantages mentioned in [Stateful-APP] is that the stateful nature of a PCE simplifies the information conveyed in PCEP messages, notably between PCC and PCE, since it is possible to refer to PCE managed state for active LSPs. To be more specific, with a stateful PCE, it is possible to refer to a LSP with a unique identifier in the scope of the PCC-PCEP session and thus use such identifier to refer to that LSP. 2.4.1. Modification for LSP Re-optimization The Request Parameters (RP) object on a Path Computation Request (PCReq) message carries the R bit. When set, this indicates that the PCC is requesting reoptimization of an existing LSP. Upon receiving such a PCReq, a stateful PCE SHOULD perform the reoptimization in the following cases: - The existing bandwidth and route information of the LSP to be reoptimized is provided in the PCReq message using the BANDWIDTH object and the ERO. - The existing bandwidth and route information is not supplied in the PCReq message, but can be found in the PCE's LSP-DB. In this case, the LSP MUST be identified using an LSP identifier carried in the PCReq message, and that fact requires that the LSP identifier Zhang et al Expires January 2016 [Page 6] draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt July 2015 was previously supplied either by the PCC in a PCRpt message or by the PCE in a PCRep. [Stateful-PCE] defines how this is achieved using a combination of the per-node LSP identifier (PLSP-ID) and the PCC's address. If no LSP state information is available to carry out reoptimization, the stateful PCE should report the error "LSP state information unavailable for the LSP reoptimization" (Error Type = TBD1, Error value= TBD2). 2.4.2. Modification for Route Exclusion [RFC5521] defines a mechanism for a PCC to request or demand that specific nodes, links, or other network resources are excluded from paths computed by a PCE. A PCC may wish to request the computation of a path that avoids all link and nodes traversed by some other LSP. To this end this document defines a new sub-object for use with route exclusion defined in [RFC5521]. The LSP exclusion sub-object is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|Type (TBD3) | Length | Attributes | Flag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PLSP-ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ X bit and Attribute fields are defined in [RFC5521]. X bit: indicates whether the exclusion is mandatory (X=1) and MUST be accommodated, or desired (X=0) and SHOULD be accommodated. Type: Subobject Type for an LSP exclusion sub-object. Value of TBD3. To be assigned by IANA. Length: The Length contains the total length of the subobject in bytes, including the Type and Length fields. Attributes: indicates how the exclusion object is to be interpreted. Currently, Interface (Attributes = 0), Node (Attributes =1) and SRLG (Attributes =2) are defined in [RFC5521] and this document does not define new values. Flags: This field may be used to further specify the exclusion constraint with regard to the LSP. Currently, no values are defined. Zhang et al Expires January 2016 [Page 7] draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt July 2015 PLSP-ID: This is the identifier given to a LSP and is unique in the context of the PCC address as defined in [Stateful-PCE]. Reserved: MUST be transmitted as zero and SHOULD be ignored on receipt. This sub-object is OPTIONAL in the exclude route object (XRO) and can be present multiple times. When a stateful PCE receives a PCReq message carrying this sub-object, it SHOULD search for the identified LSP in its LSP-DB and then exclude it from the new path computation all resources used by the identified LSP. If the stateful PCE cannot recognize one or more of the received LSP identifiers, it should send an error message PCErr reporting "The LSP state information for route exclusion purpose cannot be found" (Error-type = TBD1, Error-value = TBD4). Optionally, it may provide with the unrecognized identifier information to the requesting PCC using the error reporting techniques described in [RFC5440]. 2.5. Object Encoding Note that, as is stated in Section 7 of [Stateful-PCE], the P flag and the I flag of the PCEP objects used on PCUpd and PCRpt messages SHOULD be set to 0 on transmission and SHOULD be ignored on receipt since these flags are exclusively related to path computation requests. 3. IANA Considerations IANA is requested to allocate new Types for the TLV/Object defined in this document. 3.1. New PCEP Error Codes IANA is requested to make the following allocation in the "PCEP- ERROR Object Error Types and Values" registry. Error Type Meaning Reference TBD1 LSP state information missing [This.I-D] Error-value TBD2: LSP state information unavailable [This.I-D] for the LSP re-optimization Error-value TBD4: LSP state information for route exclusion purpose cannot be found [This.I-D] Zhang et al Expires January 2016 [Page 8] draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt July 2015 3.2. New Subobject for the Exclude Route Object IANA maintains the "PCEP Parameters" registry containing a subregistry called "PCEP Objects". This registry has a subregistry for the XRO (Exclude Route Object) listing the sub-objects that can be carried in the XRO. IANA is requested to assign a further sub- object that can be carried in the XRO as follows: Value Description Reference ----------+------------------------------+------------- TBD3 LSP identifier sub-object [This.I-D] 4. Manageability Considerations The description and functionality specifications presented related to stateful PCEs should also comply with the manageability specifications covered in Section 8 of [RFC4655]. Furthermore, a further list of manageability issues presented in [Stateful-PCE] should also be considered. Additional considerations are presented in the next sections. 4.1. Requirements on Other Protocols and Functional Components When the detailed route information is included for LSP state synchronization (either at the initial stage or during LSP state report process), this require the ingress node of an LSP carry the RRO object in order to enable the collection of such information. 5. Security Considerations The security issues presented in [RFC5440] and [Stateful-PCE] apply to this document. 6. Acknowledgement We would like to thank Adrian Farrel and Cyril Margaria for the useful comments and discussions. Zhang et al Expires January 2016 [Page 9] draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt July 2015 7. References 7.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. [Stateful-PCE]Crabbe, E., Medved, J., Varga, R., Minei, I., "PCEP Extensions for Stateful PCE", draft-ietf-pce-stateful-pce, 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. 7.2. Informative References [Stateful-APP] Zhang, X., Minei, I., et al, "Applicability of Stateful Path Computation Element (PCE) ", draft-ietf-pce- stateful-pce-app, work in progress. [Sync-OPT] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., and D. Dhody, "Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE", draft- ietf-pce-stateful-sync-optimizations, work in progress. 8. Contributors' Address Dhruv Dhody Huawei Technology Leela Palace Bangalore, Karnataka 560008 INDIA EMail: firstname.lastname@example.org Yi Lin Huawei Technologies F3-5-B R&D Center, Huawei Base Zhang et al Expires January 2016 [Page 10] draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt July 2015 Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972914 Email: email@example.com Zhang et al Expires January 2016 [Page 11] draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt July 2015 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-28972645 Email: firstname.lastname@example.org Young Lee Huawei 1700 Alma Drive, Suite 100 Plano, TX 75075 US Phone: +1 972 509 5599 x2240 Fax: +1 469 229 5397 EMail: email@example.com Fatai Zhang Huawei F3-5-B R&D Center, Huawei Base Bantian, Longgang District P.R. China Phone: +86-755-28972912 Email: firstname.lastname@example.org Ramon Casellas CTTC Av. Carl Friedrich Gauss n7 Castelldefels, Barcelona 08860 Spain Phone: Email: email@example.com Oscar Gonzalez de Dios Telefonica Investigacion y Desarrollo Emilio Vargas 6 Madrid, 28045 Spain Zhang et al Expires January 2016 [Page 12] draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt July 2015 Phone: +34 913374013 Email: firstname.lastname@example.org Zafar Ali Cisco Systems Email: email@example.com Zhang et al Expires January 2016 [Page 13]