Internet DRAFT - draft-margaria-pce-pcep-hlsp-extension
draft-margaria-pce-pcep-hlsp-extension
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:
<request>::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<OF>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
[<XRO>]
[<LSP_TUNNEL_INTERFACE_ID>...]
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 <attribute-list> definition, which is extended as
follows:
<attribute-list>::=[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
[<LSP_TUNNEL_INTERFACE_ID>...]
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 <attribute-list> 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 <attribute-list> 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,
<http://www.rfc-editor.org/info/rfc2119>.
[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,
<http://www.rfc-editor.org/info/rfc4203>.
[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, <http://www.rfc-editor.org/info/rfc5088>.
[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, <http://www.rfc-editor.org/info/rfc5089>.
[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,
<http://www.rfc-editor.org/info/rfc5307>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>.
[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,
<http://www.rfc-editor.org/info/rfc5520>.
[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, <http://www.rfc-editor.org/info/rfc5521>.
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,
<http://www.rfc-editor.org/info/rfc5541>.
[RFC6107] Shiomoto, K., Ed. and A. Farrel, Ed., "Procedures for
Dynamically Signaled Hierarchical Label Switched Paths",
RFC 6107, DOI 10.17487/RFC6107, February 2011,
<http://www.rfc-editor.org/info/rfc6107>.
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, <http://www.rfc-editor.org/info/rfc5817>.
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]
