PCE C. Margaria, Ed. Internet-Draft C. Barth Intended status: Standards Track S. Cheruathur Expires: September 21, 2016 B. Tsai Juniper March 20, 2016 PCEP Procedures for Hierarchical Label Switched Paths draft-margaria-pce-pcep-hlsp-extension-00 Abstract Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links to carry traffic in those networks or in other (client) networks. These LSPs can be referred to as Hierarchical LSPs (H-LSP). H-LSPs allow to improve the scalability of MPLS/GMPLS networks by creating hierarchies of TE-LSPs. Those hierarchies are an important state for optimal TE-Computation, therefore a stateful PCE should be able to discover and manage those H-LSPs. A PCE having a global view of the network, including Forwarding Adjacencies LSP (FA-LSP) and non FA- LSPs, can create more optimal hierachies and (re-)compute the TE-LSPs path to make use of the H-LSPs. In particular a PCE can better leverage the Private H-LSP introduced by RFC6107 without influencing the IGP, allowing a less disruptive use of Hierarchies. RFC6107 defined Protocol mechanisms to facilitate the establishment of such LSPs and to bundle traffic engineering (TE) links to reduce the load on routing protocols. This document defines PCEP extensions to learn about and control those H-LSPs. 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." Margaria, et al. Expires September 21, 2016 [Page 1] Internet-Draft PCEP H-LSPs March 2016 This Internet-Draft will expire on September 21, 2016. Copyright Notice Copyright (c) 2016 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. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Solution overview . . . . . . . . . . . . . . . . . . . . 3 2. H-LSP capability advertisement . . . . . . . . . . . . . . . 4 2.1. PCE Discovery Protocol . . . . . . . . . . . . . . . . . 4 2.2. OPEN Object extension HLSP-CAPABILITY TLV . . . . . . . . 4 3. PCEP object and extensions . . . . . . . . . . . . . . . . . 5 3.1. The PCReq message . . . . . . . . . . . . . . . . . . . . 5 3.2. The PCRep message . . . . . . . . . . . . . . . . . . . . 6 3.3. The PCRpt message . . . . . . . . . . . . . . . . . . . . 6 3.4. The PCUpd message . . . . . . . . . . . . . . . . . . . . 6 3.5. The PCInitiate message . . . . . . . . . . . . . . . . . 7 3.6. LSP_TUNNEL_INTERFACE_ID Object . . . . . . . . . . . . . 7 3.6.1. Procedures . . . . . . . . . . . . . . . . . . . . . 7 4. Additional Error Type and Error Values Defined . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 10 5.2. New PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . 11 5.3. RP Object Flag Field . . . . . . . . . . . . . . . . . . 11 5.4. New PCEP Error Codes . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Margaria, et al. Expires September 21, 2016 [Page 2] Internet-Draft PCEP H-LSPs March 2016 1. Introduction Traffic Engineering (TE) links in a Multiprotocol Label Switching (MPLS) or a Generalized MPLS (GMPLS) network may be constructed from Label Switched Paths (LSPs) [RFC6107]. Such LSPs are defined as hierarchical LSPs (H-LSPs). The mechanisms described in [RFC6107] enables the dynamically construction of provisioned hierarchical networks. The Path Computation Element Protocol (PCEP) defined in [RFC5440], [RFC5521], [RFC5541], [RFC5520], [I-D.ietf-pce-gmpls-pcep-extensions], [I-D.ietf-pce-stateful-pce] and [I-D.ietf-pce-pce-initiated-lsp] enable a PCE to compute paths for a range of switching technologies in a stateless and statefull manner, but does not allow a PCE to control the hierarchy of such LSPs. This document complements those RFCs to control H-LSPs. This document provides the same level of control as [RFC6107], so that the PCE can provide the following information to the LSPs endpoints: Whether the LSP is an ordinary LSP or an H-LSP. In which IGP instances the LSP should be advertised as a link. How the client networks should make use of H-LSP and corresponding TE-links. Whether the TE-link should form part of a bundle (and if so, which bundle). How the link endpoints should be identified when advertised. 1.1. 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]. 1.2. Solution overview The encoding and semantics associated with the control of H-LSPs is already considered and defined by [RFC6107]. This document reuses those definitisns and adapts them to PCEP. The following section describes the new PCEP new objects and associated procedures. Margaria, et al. Expires September 21, 2016 [Page 3] Internet-Draft PCEP H-LSPs March 2016 2. H-LSP capability advertisement 2.1. PCE Discovery Protocol IGP-based PCE Discovery (PCED) is defined in [RFC5088] and [RFC5089] for the OSPF and IS-IS protocols. A new flag (bit TBA-1) is defined to advertise the H-LSP capability: Bit Capabilities TBA-1 : H-LSP Capability 2.2. OPEN Object extension HLSP-CAPABILITY TLV In addition to the IGP advertisement, a PCEP speaker SHOULD be able to discover the other peer GMPLS capabilities during the Open message exchange. This capability is also useful to avoid misconfigurations. This document defines a new GMPLS-CAPABILITY TLV for use in the OPEN object to negotiate the H-LSP capability. The inclusion of this TLV in the OPEN message indicates that the PCC/PCE support the PCEP extensions defined in this document. A PCE that is able to support the extensions defined in this document MUST include the HLSP- CAPABILITY TLV in the OPEN message. If a PCEP Peer does not include the HLSP-CAPABILITY TLV in the OPEN message and the other PCEP peer does include the TLV, it is RECOMMENDED that each peer indicates a mismatch of capabilities. If any of the peers do not advertise the HLSP-CAPABILITY TLV, the extension defined in this document MUST NOT be used. IANA has allocated value TBA-2 from the "PCEP TLV Type Indicators" sub-registry, as documented in Section 5.2 ("New PCEP TLVs"). The description is "HLSP-CAPABILITY". Its format is shown in the following figure. 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=TBA-2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ No Flags are defined in this document, they are reserved for future use. Margaria, et al. Expires September 21, 2016 [Page 4] Internet-Draft PCEP H-LSPs March 2016 3. PCEP object and extensions This section describes the required PCEP objects and extensions. The PCReq and PCRep messages are defined in [RFC5440]. The PCRpt and PCUpd messages are defined in [I-D.ietf-pce-stateful-pce] and the PCInitiate in [I-D.ietf-pce-pce-initiated-lsp]. The control of H-LSP by a PCE will reuse and adapt the information, encoding and procedure described in [RFC6107]. This document defines the LSP_TUNNEL_INTERFACE_ID PCEP object for that purposea and it is carried in the following messages: PCReq: The PCC indicates that it will form a H-LSP. PCRep: If the object was present in the corresponding PCReq, the PCE may suggest IDs. PCRpt: The PCC reports the state of the H-LSP. PCUpd: The PCE requests the LSP to be used as H-LSP. PCInitiate: The PCE requests the creation of a H-LSP. 3.1. The PCReq message The PCReq MAY include the LSP_TUNNEL_INTERFACE_ID object. Multiple instances of the object MAY be included in the message, in case multiple IGP instances are the target, following [RFC6107], section 3.4. The presence of the object indicates that the PCC will setup the TE-LSP as a H-LSP. This MAY be used by the PCE as policy input. The PCC MAY set the IDs to 0, as described in Section 3.6.1. The PCReq is modified as follows: ::= [] [] [] [] [[]] [] [] [] [...] Margaria, et al. Expires September 21, 2016 [Page 5] Internet-Draft PCEP H-LSPs March 2016 3.2. The PCRep message The PCE MAY include the LSP_TUNNEL_INTERFACE_ID object from the corresponding PCReq. The PCE MUST NOT include the LSP_TUNNEL_INTERFACE_ID if it was not present in the corresponding PCReq. If the IDs were set to 0 on request, the PCE SHOULD provide a recommended value, as described in Section 3.6.1. The PCRep uses the definition, which is extended as follows: ::=[] [] [] [] [...] 3.3. The PCRpt message The PCRpt MAY include the LSP_TUNNEL_INTERFACE_ID object. Multiple instances of the object MAY be included in the message, in the case where multiple IGP instances are the target, following [RFC6107], section 3.4 or to report the ingress and egress IDs. The presence of the object indicates that the PCC will setup the TE-LSP as a H-LSP. If the LSP object O(Operational) flag is DOWN, the PCC MAY set the IDs to 0, as described in Section 3.6.1. If the LSP object O flag is UP or ACTIVE the PCC SHOULD report at least 2 LSP_TUNNEL_INTERFACE_IDs for a given target IGP instance, one for ingress and one for egress. The PCRpt uses the definition, which is extended as described in Section 3.2. 3.4. The PCUpd message The PCUpd MAY include the LSP_TUNNEL_INTERFACE_ID object. Multiple instances of the object MAY be included in the message, in the case where multiple IGP instances are the target, following [RFC6107], section 3.4 or to report the ingress and egress IDs. The presence of the object indicates that the PCC SHOULD setup the TE-LSP as a H-LSP. The PCE MUST NOT include any object type for the egress node. If the PCE includes the object type for the egress node the PCC MUST send a PCErr with error type TBA-5(PCC Hierarchy Issue) and error value 1(Egress LSP_TUNNEL_INTERFACE_ID Object type in PCUp, PCRep or PCInitiate message). The PCE MAY set the IDs in accordance to Section 3.6.1. Margaria, et al. Expires September 21, 2016 [Page 6] Internet-Draft PCEP H-LSPs March 2016 The PCUpd use the definition, which is extended as described in Section 3.2 Upon receipt of a PCUpd message with LSP_TUNNEL_INTERFACE_ID, the PCC SHOULD try to setup the TE-LSP as a H-LSP based on its policies. If the PCC ignores the LSP_TUNNEL_INTERFACE_ID, it MUST set the I bit. If the PCE requires the LSP to be an H-LSP, it MUST set the P(Processing) Flag in the object header. If the PCE is tearing down the LSP, the client LSPs may be impacted. It is RECOMMENDED that the PCC uses the Gracefull link shutdown procedures described in [RFC4203], [RFC5307] and [RFC5817]. It can be desirable for a PCE to know in advance if the LSP carries traffic before initiating the teardown as it would result in a smoother transition in the case where the gracefull teardown procedures are not used. This indication is not a H-LSP specific operation and MAY be used in a more general context, therefore it is out of the scope of this document. 3.5. The PCInitiate message The procedure for PCInitiate are the same as for PCUpd, described in Section 3.4. 3.6. LSP_TUNNEL_INTERFACE_ID Object IANA has allocated value TBA-3 from the "PCEP Objects" sub-registry, as documented in Section 5.1 ("New PCEP Object"). The description is "LSP_TUNNEL_INTERFACE_ID". The following object-type are defined by this document: Object-Type Description 1 Ingress Unnumbered Links with Action Identification. 2 Ingress IPv4 Numbered Links with Action Identification. 3 Ingress IPv6 Numbered Links with Action Identification. 4 Egress Unnumbered Links with Action Identification. 5 Egress IPv4 Numbered Links with Action Identification. 6 Egress IPv6 Numbered Links with Action Identification. The content and TLVs are those defined in [RFC6107]. The TLVs are not PCEP TLVs. 3.6.1. Procedures In [RFC6107] the interface IDs are allocated by the endpoints, this principle remains unchanged. In the context of PCEP the PCE does not manage the PCC ids. It may suggest IDs (numbered or unnumbered), but Margaria, et al. Expires September 21, 2016 [Page 7] Internet-Draft PCEP H-LSPs March 2016 the PCC remains in control of these allocations. The PCE can indicate to the PCC that the ID SHOULD be allocated by the PCC by setting the ID to the value of 0. This applies to the following fields: Interface ID LSR's Router ID IPv4 Interface Address IPv6 Interface Address Component Link Identifier IPv4 Numbered Component Link Identification IPv6 Numbered Component Link Identification The PCE MAY only set the Object-type (OT) in the range of 1 to 3, while the OT range of 4 to 6 are reserved for reporting the reverse Ids assigned by the egress node. The ID MAY be 0 for OT 1 to 3 in the following cases: PCReq: the PCC is indicating that the PCE SHOULD provide a value PCRep: the PCE is indicating the PCC SHOULD do the allocation PCRpt: when the LSP is DOWN or GOING-UP PCUpd: the PCE is indicating the PCC SHOULD do the allocation PCInitiate: the PCE is indicating the PCC SHOULD do the allocation In case where the PCC is not able to allocate an address suitable for the H-LSP, it MUST reply with a PCErr with type TBA-5 (PCC Hierarchy Issue), value 9 (PCC Cannot allocate a IPv4 Interface Address), value 10 (PCC Cannot allocate a IPv6 Interface Address) or value 11 (PCC Cannot allocate an Unnumbered Interface Address). The ID MAY be set by the PCE for OT in range of 1 to 3 in the following cases: PCRep: the PCE is suggesting and ID to be used PCUpd: the PCE is suggesting and ID to be used Margaria, et al. Expires September 21, 2016 [Page 8] Internet-Draft PCEP H-LSPs March 2016 PCInitiate: the PCE is suggesting and ID to be used The PCC MAY use the suggested value. If the value is not used, the PCC SHOULD send a PCErr with type TBA-5 (PCC Hierarchy Issue) and a value 2 ( Interface ID provided is invalid), 3 (LSR's Router ID provided is invalid), 4 (IPv4 Interface Address provided is invalid) 5 (IPv6 Interface Address provided is invalid), 6 (Component Link Identifier provided is invalid), 7 (IPv4 Numbered Component Link Identification provided is invalid) or 8 (IPv6 Numbered Component Link Identification provided is invalid). The ID MUST NOT be 0 for OT 1 to 3 in the following cases: PCRpt when the LSP is UP, ACTIVE or GOING-DOWN 4. Additional Error Type and Error Values Defined A PCEP-ERROR object is used to report a PCEP error and is characterized by an Error-Type that specifies the type of error while Error-value that provides additional information about the error. Additional errors types and error values are defined to represent some of the errors related to the newly identified objects. For each PCEP error, an Error-Type and an Error-value are defined. Error-Type 1 to 10 are already defined in [RFC5440]. Two new Error-Type are introduced (value TBA-4 and TBA-5). Margaria, et al. Expires September 21, 2016 [Page 9] Internet-Draft PCEP H-LSPs March 2016 Error-Type Error-value Type=TBA-4 LSP Hierarchy Issue Value=1: Link advertisement not supported. Value=2: Link advertisement not allowed by policy. Value=3: TE link creation not supported. Value=4: TE link creation not allowed by policy. Value=5: Routing adjacency creation not supported. Value=6: Routing adjacency creation not allowed by policy. Value=7: Bundle creation not supported. Value=8: Bundle creation not allowed by policy. Value=9: Hierarchical LSP not supported. Value=10: LSP stitching not supported. Value=11: Link address type or family not supported. Value=12: IGP instance unknown. Value=13: IGP instance advertisement not allowed by policy. Value=14: Component link identifier not valid. Value=15: Unsupported component link identifier address family. Type=TBA-5 PCC Hierarchy Issue Value=1: Egress LSP_TUNNEL_INTERFACE_ID Object type in PCUp, PCRep or PCInitiate message. Value=2: Interface ID provided is invalid. Value=3: LSR's Router ID provided is invalid. Value=4: IPv4 Interface Address provided is invalid. Value=5: IPv6 Interface Address provided is invalid. Value=6: Component Link Identifier provided is invalid. Value=7: IPv4 Numbered Component Link Identification provided is invalid. Value=8: IPv6 Numbered Component Link Identification provided is invalid. Value=9: PCC Cannot allocate a IPv4 Interface Address. Value=10: PCC Cannot allocate a IPv6 Interface Address. Value=11: PCC Cannot allocate an Unnumbered Interface Address. 5. IANA Considerations 5.1. PCEP Objects IANA is requested to make the following Object-Type allocations from the "PCEP Objects" sub-registry. Margaria, et al. Expires September 21, 2016 [Page 10] Internet-Draft PCEP H-LSPs March 2016 Object Name Object-Type Reference Class Value TBA-3 LSP_TUNNEL_INTERFACE_ID 1: Ingress Unnumbered This Links with Action document Identification. 2: Ingress IPv4 Numbered This Links with Action document Identification. 3:Ingress IPv6 Numbered This Links with Action document Identification. 4:Egress Unnumbered Links This with Action document Identification. 5:Egress IPv4 Numbered This Links with Action document Identification. 6:Egress IPv6 Numbered This Links with Action document Identification. 7-15: Unassigned This document 5.2. New PCEP TLVs IANA manages the PCEP TLV code point registry (see [RFC5440]). This is maintained as the "PCEP TLV Type Indicators" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry. This document defines new PCEP TLVs, to be carried in the END-POINTS object with Generalized Endpoint object Type. IANA is requested to do the following allocation. The values here are suggested for use by IANA. Value Meaning Reference TBA-2 HLSP-CAPABILITY TLV This document (section Section 2.2) 5.3. RP Object Flag Field As described in new flag are defined in the RP Object Flag IANA is requested to make the following allocations from the OSPF registry, "PCE Capability Flags" sub-registry. The values here are suggested for use by IANA. Margaria, et al. Expires September 21, 2016 [Page 11] Internet-Draft PCEP H-LSPs March 2016 Bit Description Reference TBA-1 H-LSP Capability This document, Section 2.1 5.4. New PCEP Error Codes As described in Section 4, new PCEP Error-Type and Error Values are defined. IANA is requested to make the following allocation in the "PCEP-ERROR Object Error Types and Values" registry. The values here are suggested for use by IANA. Margaria, et al. Expires September 21, 2016 [Page 12] Internet-Draft PCEP H-LSPs March 2016 Error name Reference Type=TBA-4 LSP Hierarchy Issue This Document Value=1: Link advertisement not supported. This Document Value=2: Link advertisement not allowed by policy. This Document Value=3: TE link creation not supported. This Document Value=4: TE link creation not allowed by policy. This Document Value=5: Routing adjacency creation not supported. This Document Value=6: Routing adjacency creation not allowed by This Document policy. Value=7: Bundle creation not supported. This Document Value=8: Bundle creation not allowed by policy. This Document Value=9: Hierarchical LSP not supported. This Document Value=10: LSP stitching not supported. This Document Value=11: Link address type or family not supported. This Document Value=12: IGP instance unknown. This Document Value=13: IGP instance advertisement not allowed by This Document policy. Value=14: Component link identifier not valid. This Document Value=15: Unsupported component link identifier This Document address family. Type=TBA-5 PCC Hierarchy Issue This Document Value=1: Egress LSP_TUNNEL_INTERFACE_ID Object type This Document in PCUp, PCRep or PCInitiate message. Value=2: Interface ID provided is invalid. This Document Value=3: LSR's Router ID provided is invalid. This Document Value=4: IPv4 Interface Address provided is invalid. This Document Value=5: IPv6 Interface Address provided is invalid. This Document Value=6: Component Link Identifier provided is This Document invalid. Value=7: IPv4 Numbered Component Link Identification This Document provided is invalid. Value=8: IPv6 Numbered Component Link Identification This Document provided is invalid. Value=9: PCC Cannot allocate a IPv4 Interface This Document Address. Value=10: PCC Cannot allocate a IPv6 Interface This Document Address. Value=11: PCC Cannot allocate an Unnumbered Interface This Document Address. Value=: . This Document 6. Security Considerations Margaria, et al. Expires September 21, 2016 [Page 13] Internet-Draft PCEP H-LSPs March 2016 7. Acknowledgments 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, . [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, January 2008, . [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, January 2008, . [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, DOI 10.17487/RFC5520, April 2009, . [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April 2009, . Margaria, et al. Expires September 21, 2016 [Page 14] Internet-Draft PCEP H-LSPs March 2016 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, DOI 10.17487/RFC5541, June 2009, . [RFC6107] Shiomoto, K., Ed. and A. Farrel, Ed., "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", RFC 6107, DOI 10.17487/RFC6107, February 2011, . 8.2. Informative References [I-D.ietf-pce-gmpls-pcep-extensions] Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for GMPLS", draft-ietf-pce-gmpls-pcep-extensions-11 (work in progress), October 2015. [I-D.ietf-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", draft-ietf-pce-pce-initiated-lsp-05 (work in progress), October 2015. [I-D.ietf-pce-stateful-pce] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce-stateful- pce-14 (work in progress), March 2016. [RFC5817] Ali, Z., Vasseur, JP., Zamfir, A., and J. Newton, "Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks", RFC 5817, DOI 10.17487/RFC5817, April 2010, . Authors' Addresses Cyril Margaria (editor) Juniper 200 Somerset Corporate Boulevard, , Suite 4001 Bridgewater, NJ 08807 USA Email: cmargaria@juniper.net Margaria, et al. Expires September 21, 2016 [Page 15] Internet-Draft PCEP H-LSPs March 2016 Colby Barth Juniper Email: cbarth@juniper.net Sudhir Cheruathur Juniper Email: scheruathur@juniper.net Ben J.C. Tsai Juniper Email: jtsai@juniper.net Margaria, et al. Expires September 21, 2016 [Page 16]