summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8281.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8281.txt')
-rw-r--r--doc/rfc/rfc8281.txt1123
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc8281.txt b/doc/rfc/rfc8281.txt
new file mode 100644
index 0000000..62f30bd
--- /dev/null
+++ b/doc/rfc/rfc8281.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) E. Crabbe
+Request for Comments: 8281 Individual Contributor
+Category: Standards Track I. Minei
+ISSN: 2070-1721 Google, Inc.
+ S. Sivabalan
+ Cisco Systems, Inc.
+ R. Varga
+ Pantheon Technologies SRO
+ December 2017
+
+
+ Path Computation Element Communication Protocol (PCEP) Extensions for
+ PCE-Initiated LSP Setup in a Stateful PCE Model
+
+Abstract
+
+ The Path Computation Element Communication Protocol (PCEP) provides
+ mechanisms for Path Computation Elements (PCEs) to perform path
+ computations in response to Path Computation Client (PCC) requests.
+
+ The extensions for stateful PCE provide active control of
+ Multiprotocol Label Switching (MPLS) Traffic Engineering Label
+ Switched Paths (TE LSPs) via PCEP, for a model where the PCC
+ delegates control over one or more locally configured LSPs to the
+ PCE. This document describes the creation and deletion of
+ PCE-initiated LSPs under the stateful PCE model.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8281.
+
+
+
+
+
+
+
+
+
+
+
+Crabbe, et al. Standards Track [Page 1]
+
+RFC 8281 PCE-Initiated LSPs in Stateful PCE December 2017
+
+
+Copyright Notice
+
+ Copyright (c) 2017 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
+
+ (https://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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crabbe, et al. Standards Track [Page 2]
+
+RFC 8281 PCE-Initiated LSPs in Stateful PCE December 2017
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
+ 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 5
+ 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.2. Operation Overview . . . . . . . . . . . . . . . . . . . 6
+ 4. Support of PCE-Initiated LSPs . . . . . . . . . . . . . . . . 7
+ 4.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 8
+ 5. PCE-Initiated LSP Instantiation and Deletion . . . . . . . . 8
+ 5.1. The LSP Initiate Request . . . . . . . . . . . . . . . . 8
+ 5.2. The R Flag in the SRP Object . . . . . . . . . . . . . . 10
+ 5.3. LSP Instantiation . . . . . . . . . . . . . . . . . . . . 10
+ 5.3.1. The Create Flag . . . . . . . . . . . . . . . . . . . 12
+ 5.3.2. The SPEAKER-ENTITY-ID TLV . . . . . . . . . . . . . . 13
+ 5.4. LSP Deletion . . . . . . . . . . . . . . . . . . . . . . 13
+ 6. LSP Delegation and Cleanup . . . . . . . . . . . . . . . . . 14
+ 7. LSP State Synchronization . . . . . . . . . . . . . . . . . . 15
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
+ 8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 15
+ 8.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 15
+ 8.3. SRP object . . . . . . . . . . . . . . . . . . . . . . . 16
+ 8.4. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 16
+ 8.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 17
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
+ 9.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 18
+ 9.2. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 18
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . 19
+ 10.2. Informative References . . . . . . . . . . . . . . . . . 19
+ Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crabbe, et al. Standards Track [Page 3]
+
+RFC 8281 PCE-Initiated LSPs in Stateful PCE December 2017
+
+
+1. Introduction
+
+ [RFC5440] describes the Path Computation Element Communication
+ Protocol (PCEP). PCEP defines the communication between a Path
+ Computation Client (PCC) and a Path Computation Element (PCE), or
+ between PCE and PCE, enabling computation of Multiprotocol Label
+ Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP)
+ characteristics.
+
+ [RFC8231] specifies a set of extensions to PCEP to enable stateful
+ control of TE LSPs between and across PCEP sessions in compliance
+ with [RFC4657]. It includes:
+
+ o mechanisms to effect LSP State Synchronization between PCCs and
+ PCEs
+
+ o delegation of control of LSPs to PCEs
+
+ o PCE control of timing and sequence of path computations within and
+ across PCEP sessions
+
+ It focuses on a model where LSPs are configured on the PCC, and
+ control over them is delegated to the PCE.
+
+ This document describes the setup, maintenance, and teardown of
+ PCE-initiated LSPs under the stateful PCE model, without the need for
+ local configuration on the PCC, thus allowing for a dynamic network
+ that is centrally controlled and deployed.
+
+2. Terminology
+
+ This document uses the following terms defined in [RFC5440]: PCC,
+ PCE, and PCEP Peer.
+
+ This document uses the following terms defined in [RFC8051]: Stateful
+ PCE and Delegation.
+
+ This document uses the following terms defined in [RFC8231]:
+ Redelegation Timeout Interval, State Timeout Interval, LSP State
+ Report, and LSP Update Request.
+
+ The following terms are defined in this document:
+
+ PCE-initiated LSP: LSP that is instantiated as a result of a request
+ from the PCE.
+
+ The message formats in this document are specified using Routing
+ Backus-Naur Form (RBNF) encoding as specified in [RFC5511].
+
+
+
+Crabbe, et al. Standards Track [Page 4]
+
+RFC 8281 PCE-Initiated LSPs in Stateful PCE December 2017
+
+
+2.1. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+3. Architectural Overview
+
+3.1. Motivation
+
+ [RFC8231] provides active control over LSPs that are locally
+ configured on the PCC. This model relies on the Label Edge Router
+ (LER) taking an active role in delegating locally configured LSPs to
+ the PCE and is well suited in environments where the LSP placement is
+ fairly static. However, in environments where the LSP placement
+ needs to change in response to application demands, it is useful to
+ support dynamic creation and teardown of LSPs. The ability for a PCE
+ to trigger the creation of LSPs on demand can be seamlessly
+ integrated into a controller-based network architecture, where
+ intelligence in the controller can determine when and where to set up
+ paths.
+
+ A possible use case is a software-defined network, where applications
+ request network resources and paths from the network infrastructure.
+ For example, an application can request a path with certain
+ constraints between two Label Switching Routers (LSRs) by contacting
+ the PCE. The PCE can compute a path satisfying the constraints, and
+ instruct the head end LSR to instantiate and signal it. When the
+ path is no longer required by the application, the PCE can request
+ its teardown.
+
+ Another use case is dynamically adjusting aggregate bandwidth between
+ two points in the network using multiple LSPs. This functionality is
+ very similar to auto-bandwidth, but it allows for providing the
+ desired capacity through multiple LSPs. This approach overcomes two
+ of the limitations auto-bandwidth can experience: 1) growing the
+ capacity between the endpoints beyond the capacity of individual
+ links in the path and 2) achieving good bin packing through use of
+ several small LSPs instead of a single large one. The number of LSPs
+ varies based on the demand, and LSPs are created and deleted
+ dynamically to satisfy the bandwidth requirements.
+
+
+
+
+
+
+
+
+Crabbe, et al. Standards Track [Page 5]
+
+RFC 8281 PCE-Initiated LSPs in Stateful PCE December 2017
+
+
+ Another use case is demand engineering, where a PCE with visibility
+ into both the network state and the demand matrix can anticipate and
+ optimize how traffic is distributed across the infrastructure. Such
+ optimizations may require creating new paths across the
+ infrastructure.
+
+3.2. Operation Overview
+
+ This document defines the new I flag in the STATEFUL-PCE-CAPABILITY
+ TLV to indicate that the sender supports PCE-initiated LSPs (see
+ details in Section 4.1). A PCC or PCE sets this flag in the Open
+ message during the PCEP initialization phase to indicate that it
+ supports the procedures of this document.
+
+ This document defines a new PCEP message, the LSP Initiate Request
+ (PCInitiate) message, which a PCE can send to a PCC to request the
+ initiation or deletion of an LSP. The decision when to instantiate
+ or delete a PCE-initiated LSP is out of the scope of this document.
+
+ The PCE sends a PCInitiate message to the PCC to request the
+ initiation of an LSP. The PCC creates the LSP using the attributes
+ communicated by the PCE and local values for any unspecified
+ parameters. The PCC generates a Path Computation State Report
+ (PCRpt) for the LSP, carrying a newly assigned PLSP-ID for the LSP
+ and delegating the LSP to the PCE via the Delegate flag in the LSP
+ object.
+
+ The PCE can update the attributes of the LSP by sending subsequent
+ Path Computation Update Request (PCUpd) messages. Subsequent PCRpt
+ and PCUpd messages that the PCC and PCE, respectively, send for the
+ LSP will carry the PCC-assigned PLSP-ID, which uniquely identifies
+ the LSP. See details in Section 5.3.
+
+ The PCE sends a PCInitiate message to the PCC to request the deletion
+ of an LSP. To indicate a delete operation, this document defines the
+ new R flag in the Stateful PCE Request Parameter (SRP) object in the
+ PCInitiate message, as described in Section 5.2. As a result of the
+ deletion request, the PCC removes the LSP and sends a PCRpt for the
+ removed state. See details in Section 5.4.
+
+ Figure 1 illustrates these message exchanges.
+
+
+
+
+
+
+
+
+
+
+Crabbe, et al. Standards Track [Page 6]
+
+RFC 8281 PCE-Initiated LSPs in Stateful PCE December 2017
+
+
+ +-+-+ +-+-+
+ |PCC| |PCE|
+ +-+-+ +-+-+
+ | |
+ |<--PCInitiate-------------------| (Initiate LSP)
+ | |
+ |---PCRpt, PLSP_ID=1, D=1------->| (Confirm initiation)
+ | . |
+ | . |
+ | |
+ |<--PCUpd, PLSP_ID=1-------------| (Update LSP)
+ | |
+ |---PCRpt, PLSP_ID=1, D=1------->| (Confirm update)
+ | . |
+ | . |
+ | |
+ |<--PCInitiate, PLSP_ID=1, R=1---| (Delete LSP)
+ | |
+ |---PCRpt, PLSP_ID=1, R=1------->| (Confirm delete)
+
+ Figure 1: PCE-Initiated LSP Life Cycle
+
+4. Support of PCE-Initiated LSPs
+
+ A PCEP speaker indicates its ability to support PCE-initiated LSPs
+ during the PCEP initialization phase, as follows. When the PCEP
+ session is created, it sends an Open message with an OPEN object that
+ contains the STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]. A
+ new flag, the I (LSP-INSTANTIATION-CAPABILITY) flag, is introduced to
+ this TLV to indicate support for instantiation of PCE-initiated LSPs.
+ A PCE can initiate LSPs only for PCCs that advertised this
+ capability. A PCC will follow the procedures described in this
+ document only on sessions where the PCE advertised the I flag.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crabbe, et al. Standards Track [Page 7]
+
+RFC 8281 PCE-Initiated LSPs in Stateful PCE December 2017
+
+
+4.1. STATEFUL-PCE-CAPABILITY TLV
+
+ The format of the STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231]
+ and included here for easy reference with the addition of the new I
+ flag.
+
+ 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 | Length=4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Flags |I|S|U|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+
+
+ Figure 2: STATEFUL-PCE-CAPABILITY TLV Format
+
+ A new flag is defined to indicate the sender's support for LSP
+ instantiation by a PCE:
+
+ I (LSP-INSTANTIATION-CAPABILITY -- 1 bit): If set to 1 by a PCC, the
+ I flag indicates that the PCC allows instantiation of an LSP by a
+ PCE. If set to 1 by a PCE, the I flag indicates that the PCE
+ supports instantiating LSPs. The LSP-INSTANTIATION-CAPABILITY
+ flag must be set by both the PCC and PCE in order to enable
+ PCE-initiated LSP instantiation.
+
+5. PCE-Initiated LSP Instantiation and Deletion
+
+ To initiate an LSP, a PCE sends a PCInitiate message to a PCC. The
+ message format, objects, and TLVs are discussed separately below for
+ the creation and the deletion cases.
+
+5.1. The LSP Initiate Request
+
+ An LSP Initiate Request (PCInitiate) message is a PCEP message sent
+ by a PCE to a PCC to trigger LSP instantiation or deletion. The
+ Message-Type field of the PCEP common header for the PCInitiate
+ message is set to 12. The PCInitiate message MUST include the SRP
+ and the LSP objects and MAY contain other objects, as discussed later
+ in this section.
+
+
+
+
+
+
+
+
+
+
+
+Crabbe, et al. Standards Track [Page 8]
+
+RFC 8281 PCE-Initiated LSPs in Stateful PCE December 2017
+
+
+ The format of a PCInitiate message is as follows:
+
+ <PCInitiate Message> ::= <Common Header>
+ <PCE-initiated-lsp-list>
+ Where:
+ <Common Header> is defined in RFC 5440
+
+ <PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
+ [<PCE-initiated-lsp-list>]
+
+ <PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>|
+ <PCE-initiated-lsp-deletion>)
+
+ <PCE-initiated-lsp-instantiation> ::= <SRP>
+ <LSP>
+ [<END-POINTS>]
+ <ERO>
+ [<attribute-list>]
+
+ <PCE-initiated-lsp-deletion> ::= <SRP>
+ <LSP>
+
+ Where:
+ <attribute-list> is defined in RFC 5440 and extended by
+ PCEP extensions.
+
+ The LSP object is defined in [RFC8231]. The END-POINTS and Explicit
+ Route Objects (EROs) are defined in [RFC5440].
+
+ The SRP object is defined in [RFC8231]. The SRP object contains an
+ SRP-ID-number that is unique within a PCEP session. The PCE
+ increments the last-used SRP-ID-number before it sends each
+ PCInitiate message. The PCC MUST echo the value of the SRP-ID-number
+ in PCEP Error (PCErr) and PCRpt messages that it sends as a result of
+ the PCInitiate; this allows the PCE to correlate them with the
+ corresponding PCInitiate message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crabbe, et al. Standards Track [Page 9]
+
+RFC 8281 PCE-Initiated LSPs in Stateful PCE December 2017
+
+
+5.2. The R Flag in the SRP Object
+
+ The format of the SRP object is defined in [RFC8231] and included
+ here for easy reference with the addition of the new R flag.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Flags |R|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | SRP-ID-number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ // Optional TLVs //
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 3: The SRP Object Format
+
+ A new flag is defined to indicate a delete operation initiated by the
+ PCE:
+
+ R (LSP-REMOVE -- 1 bit): If set to 0, it indicates a request to
+ create an LSP. If set to 1, it indicates a request to remove an
+ LSP.
+
+5.3. LSP Instantiation
+
+ The LSP is instantiated by sending a PCInitiate message. The LSP is
+ set up using RSVP-TE. Extensions for other setup methods are outside
+ the scope of this document.
+
+ The PCInitiate message, when used to instantiate an LSP, MUST contain
+ an LSP object with the reserved PLSP-ID 0. The LSP object MUST
+ include the SYMBOLIC-PATH-NAME TLV, which is used to correlate
+ between the PCC-assigned PLSP-ID and the LSP.
+
+ The PCInitiate message, when used to instantiate an LSP, MUST contain
+ an ERO for the LSP.
+
+ For an instantiation request of an RSVP-signaled LSP, the destination
+ address may be needed. The PCC MAY determine it from a provided
+ object (e.g., ERO) or a local decision. Alternatively, the
+ END-POINTS object MAY be included to explicitly convey the
+ destination addresses to be used in the RSVP-TE signaling. The
+ source address MUST be either specified or left for the PCC to choose
+ by setting it to "0.0.0.0" (if the destination is an IPv4 address) or
+ "::" (if the destination is an IPv6 address).
+
+
+
+Crabbe, et al. Standards Track [Page 10]
+
+RFC 8281 PCE-Initiated LSPs in Stateful PCE December 2017
+
+
+ The PCE MAY include various attributes as per [RFC5440]. The PCC
+ MUST use these values in the LSP instantiation and local values for
+ unspecified parameters. After the LSP setup, the PCC MUST send a
+ PCRpt to the PCE, reflecting these values. The SRP object in the
+ PCRpt message MUST echo the value of the PCInitiate message that
+ triggered the setup. LSPs that were instantiated as a result of a
+ PCInitiate message MUST have the Create flag (Section 5.3.1) set in
+ the LSP object.
+
+ If the PCC receives a PCInitiate message with a non-zero PLSP-ID and
+ the R flag in the SRP object set to zero, then it MUST send a PCErr
+ message with Error-type=19 (Invalid Operation) and Error-value=8
+ (Non-zero PLSP-ID in the LSP Initiate Request).
+
+ If the PCC receives a PCInitiate message without an ERO and the R
+ flag in the SRP object set to zero, then it MUST send a PCErr message
+ with Error-type=6 (Mandatory Object missing) and Error-value=9 (ERO
+ object missing).
+
+ If the PCC receives a PCInitiate message without a SYMBOLIC-PATH-NAME
+ TLV, then it MUST send a PCErr message with Error-type=10 (Reception
+ of an invalid object) and Error-value=8 (SYMBOLIC-PATH-NAME TLV
+ missing).
+
+ The PCE MUST NOT provide a symbolic path name that conflicts with the
+ symbolic path name of any existing LSP in the PCC. (Existing LSPs
+ may be either statically configured or initiated by another PCE.) If
+ there is a conflict with the symbolic path name of an existing LSP,
+ the PCC MUST send a PCErr message with Error-type=23 (Bad Parameter
+ value) and Error-value=1 (SYMBOLIC-PATH-NAME in use). The only
+ exception to this rule is for LSPs for which the State Timeout
+ Interval timer is running (see Section 6).
+
+ If the PCC determines that the LSP parameters proposed in the
+ PCInitiate message are unacceptable, it MUST send a PCErr message
+ with Error-type=24 (PCE instantiation error) and Error-value=1
+ (Unacceptable instantiation parameters). If the PCC encounters an
+ internal error during the processing of the PCInitiate message, it
+ MUST send a PCErr message with Error-type=24 (PCE instantiation
+ error) and Error-value=2 (Internal error).
+
+ A PCC MUST relay errors it encounters in the setup of a PCE-initiated
+ LSP to the PCE by sending a PCErr message with Error-type=24 (PCE
+ instantiation error) and Error-value=3 (Signaling error). The PCErr
+ message MUST echo the SRP-ID-number of the PCInitiate message. The
+ PCEP-ERROR object SHOULD include the RSVP_ERROR_SPEC TLV (if an RSVP
+ ERROR_SPEC object was returned to the PCC by a downstream node).
+
+
+
+
+Crabbe, et al. Standards Track [Page 11]
+
+RFC 8281 PCE-Initiated LSPs in Stateful PCE December 2017
+
+
+ After the LSP is set up, errors in RSVP signaling are reported in
+ PCRpt messages, as described in [RFC8231].
+
+ On successful completion of the LSP instantiation, the PCC MUST send
+ a PCRpt message. The LSP object message MUST contain a non-zero
+ PLSP-ID that uniquely identifies the LSP within this PCC and MUST
+ have the Create flag (Section 5.3.1) and Delegate flag set. The SRP
+ object MUST contain an SRP-ID-number that echoes the value from the
+ PCInitiate message that triggered the setup. The PCRpt MUST include
+ the attributes that the PCC used to instantiate the LSP.
+
+ A PCC SHOULD be able to place a limit on either the number of LSPs or
+ the percentage of resources that are allocated to honor PCE-initiated
+ LSP requests. As soon as that limit is reached, the PCC MUST send a
+ PCErr message with Error-type=19 (Invalid Operation) and
+ Error-value=6 (PCE-initiated LSP limit reached) and is free to drop
+ any incoming PCInitiate messages without additional processing.
+
+ Similarly, the PCE SHOULD be able to place a limit on either the
+ number of PCInitiate messages pending for a particular PCC or the
+ time it waits for a response (positive or negative) to a PCInitiate
+ message from a PCC, and it MAY take further action (such as closing
+ the session or removing all its LSPs) if this limit is reached.
+
+5.3.1. The Create Flag
+
+ The LSP object is defined in [RFC8231] and included here for easy
+ reference with the addition of the new Create (C) flag.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | PLSP-ID |Flags |C| O |A|R|S|D|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ // TLVs //
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 4: The LSP Object Format
+
+ A new flag, the C flag, is introduced. On a PCRpt message, the C
+ flag set to 1 indicates that this LSP was created via a PCInitiate
+ message. The C flag MUST be set to 1 on each PCRpt message for the
+ LSP's duration of existence. The C flag allows PCEs to be aware of
+ which LSPs were PCE initiated (a state that would otherwise only be
+ known by the PCC and the PCE that initiated them).
+
+
+
+
+
+Crabbe, et al. Standards Track [Page 12]
+
+RFC 8281 PCE-Initiated LSPs in Stateful PCE December 2017
+
+
+5.3.2. The SPEAKER-ENTITY-ID TLV
+
+ The optional SPEAKER-ENTITY-ID TLV defined in [RFC8232] MAY be
+ included in the LSP object in a PCRpt message as an optional TLV for
+ LSPs for which the C flag is 1. The SPEAKER-ENTITY-ID TLV identifies
+ the PCE that initiated the creation of the LSP on all PCEP sessions,
+ a state that would otherwise only be known by the PCC and the PCE
+ that initiated the LSP. If the TLV appears in a PCRpt for an LSP for
+ which the C flag is 0, the LSP MUST be ignored, and the PCE MUST send
+ a PCErr message with Error-type=23 (Bad parameter value) and
+ Error-value=2 (Speaker identity included for an LSP that is not PCE
+ initiated).
+
+5.4. LSP Deletion
+
+ A PCE can initiate the removal of a PCE-initiated LSP by sending a
+ PCInitiate message with an LSP object carrying the PLSP-ID of the LSP
+ to be removed and an SRP object with the R flag set (see
+ Section 5.2). A PLSP-ID of zero removes all LSPs with the C flag set
+ to 1 (in their LSP object) that are delegated to the PCE.
+
+ If the PLSP-ID is unknown, the PCC MUST send a PCErr message with
+ Error-type=19 (Invalid Operation) and Error-value=3 (Unknown PLSP-ID)
+ [RFC8231].
+
+ If the PLSP-ID specified in the PCInitiate message is not delegated
+ to the PCE, the PCC MUST send a PCErr message with Error-type=19
+ (Invalid operation) and Error-value=1 (LSP is not delegated)
+ [RFC8231].
+
+ If the PLSP-ID specified in the PCInitiate message was not created by
+ a PCE, the PCC MUST send a PCErr message with Error-type=19 (Invalid
+ operation) and Error-value=9 (LSP is not PCE initiated).
+
+ Following the removal of the LSP, the PCC MUST send a PCRpt as
+ described in [RFC8231]. The SRP object in the PCRpt MUST include the
+ SRP-ID-number from the PCInitiate message that triggered the removal.
+ The R flag in the SRP object MUST be set.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crabbe, et al. Standards Track [Page 13]
+
+RFC 8281 PCE-Initiated LSPs in Stateful PCE December 2017
+
+
+6. LSP Delegation and Cleanup
+
+ The PCC MUST delegate PCE-initiated LSPs to the PCE upon
+ instantiation. The PCC MUST set the delegation bit to 1 in the PCRpt
+ that includes the assigned PLSP-ID.
+
+ The PCC MUST NOT revoke the delegation for a PCE-initiated LSP on an
+ active PCEP session. Therefore, all PCRpt messages from the PCC to
+ the PCE that owns the delegation MUST have the delegation bit set to
+ 1. If the PCE that owns the delegation receives a PCRpt message with
+ the delegation bit set to 0, then it MUST send a PCErr message with
+ Error-type=19 (Invalid Operation) and Error-value=7 (Delegation for
+ PCE-initiated LSP cannot be revoked). The PCE MAY further react by
+ closing the session.
+
+ Control over a PCE-initiated LSP can revert to the PCC in two ways.
+ A PCE MAY return a delegation to the PCC to allow for LSP transfer
+ between PCEs. Alternatively, the PCC gains control of an LSP if the
+ PCEP session that it was delegated on fails and the Redelegation
+ Timeout Interval timer expires. In both cases, the LSP becomes an
+ orphan until the expiration of the State Timeout Interval timer
+ [RFC8231].
+
+ The PCC MAY attempt to redelegate an orphaned LSP by following the
+ procedures of [RFC8231]. Alternatively, if the orphaned LSP was
+ PCE-initiated, then a PCE MAY obtain control over it, as follows.
+
+ A PCE (either the original or one of its backups) sends a PCInitiate
+ message that includes just the SRP and LSP objects and carries the
+ PLSP-ID of the LSP it wants to take control of. If the PCC receives
+ a PCInitiate message with a PLSP-ID pointing to an orphaned
+ PCE-initiated LSP, then it MUST redelegate that LSP to the PCE. Any
+ other non-zero PLSP-ID MUST result in the generation of a PCErr
+ message using the rules described in Section 5.4. The State Timeout
+ Interval timer for the LSP is stopped upon the redelegation. After
+ obtaining control of the LSP, the PCE may remove it using the
+ procedures described in this document.
+
+ The State Timeout Interval timer ensures that a PCE crash does not
+ result in automatic and immediate disruption for the services using
+ PCE-initiated LSPs. PCE-initiated LSPs are not removed immediately
+ upon PCE failure. Instead, they are cleaned up on the expiration of
+ this timer. This allows for network cleanup without manual
+ intervention. The PCC MUST support removal of PCE-initiated LSPs as
+ one of the behaviors applied on expiration of the State Timeout
+ Interval timer. The behavior MUST be picked based on local policy
+ and can result in either LSP removal or reverting to operator-defined
+ default parameters.
+
+
+
+Crabbe, et al. Standards Track [Page 14]
+
+RFC 8281 PCE-Initiated LSPs in Stateful PCE December 2017
+
+
+7. LSP State Synchronization
+
+ LSP State Synchronization procedures are described in Section 5.6 of
+ [RFC8231]. During State Synchronization, a PCC reports the state of
+ its LSPs to the PCE using PCRpt messages, setting the SYNC flag in
+ the LSP object. For PCE-initiated LSPs, the PCC MUST also set the
+ Create flag in the LSP object and MAY include the SPEAKER-ENTITY-ID
+ TLV identifying the PCE that requested the LSP creation. At the end
+ of State Synchronization, the PCE SHOULD send a PCInitiate message to
+ initiate any missing LSPs and/or remove any LSPs that are not wanted.
+ Under some circumstances, depending on the deployment, it might be
+ preferable for a PCE not to send this PCInitiate immediately, or at
+ all. For example, the PCC may be a slow device, or the operator
+ might prefer not to disrupt active flows.
+
+8. IANA Considerations
+
+ As detailed below, IANA has allocated code points for the protocol
+ elements defined in this document.
+
+8.1. PCEP Messages
+
+ IANA has registered the following message type within the "PCEP
+ Messages" subregistry of the PCEP Numbers registry. (Note that the
+ early allocation for this message type was called "Initiate"; it has
+ been changed as follows.)
+
+ Value Meaning Reference
+ ----- -------------------- -------------
+ 12 LSP Initiate Request RFC 8281
+
+8.2. LSP Object
+
+ [RFC8231] defines the LSP object; per that RFC, IANA created a
+ registry to manage the value of the LSP object's Flag field. IANA
+ has allocated a new bit in the "LSP Object Flag Field" subregistry,
+ as follows:
+
+ Bit Description Reference
+ --- ----------- -------------
+
+ 4 Create RFC 8281
+
+
+
+
+
+
+
+
+
+Crabbe, et al. Standards Track [Page 15]
+
+RFC 8281 PCE-Initiated LSPs in Stateful PCE December 2017
+
+
+8.3. SRP object
+
+ IANA has created a new subregistry, named "SRP Object Flag Field",
+ within the "Path Computation Element Protocol (PCEP) Numbers"
+ registry, to manage the Flag field of the SRP object. New values are
+ to be assigned by Standards Action [RFC8126]. Each bit is tracked
+ with the following qualities: bit number (counting from bit 0 as the
+ most significant bit), description, and defining RFC.
+
+ The following values are defined in this document:
+
+ Bit Description Reference
+ --- ----------- -------------
+
+ 31 LSP-Remove RFC 8281
+
+8.4. STATEFUL-PCE-CAPABILITY TLV
+
+ [RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV; per that RFC, IANA
+ created a registry to manage the value of the STATEFUL-PCE-CAPABILITY
+ TLV's Flag field. IANA has allocated a new bit in the STATEFUL-PCE-
+ CAPABILITY TLV Flag Field registry, as follows:
+
+ Bit Description Reference
+ --- -------------------------------- -------------
+
+ 29 LSP-INSTANTIATION-CAPABILITY (I) RFC 8281
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crabbe, et al. Standards Track [Page 16]
+
+RFC 8281 PCE-Initiated LSPs in Stateful PCE December 2017
+
+
+8.5. PCEP-Error Object
+
+ IANA has registered the following error types and error values within
+ the "PCEP-ERROR Object Error Types and Values" subregistry of the
+ PCEP Numbers registry.
+
+ Error-Type Meaning
+ ---------- --------------
+ 10 Reception of an invalid object
+
+ Error-value=8: SYMBOLIC-PATH-NAME TLV missing
+
+ 19 Invalid Operation
+
+ Error-value=6: PCE-initiated LSP limit reached
+ Error-value=7: Delegation for PCE-initiated LSP cannot
+ be revoked
+ Error-value=8: Non-zero PLSP-ID in LSP Initiate Request
+ Error-value=9: LSP is not PCE initiated
+ Error-value=10: PCE-initiated operation-frequency limit
+ reached
+
+ 23 Bad parameter value
+
+ Error-value=1: SYMBOLIC-PATH-NAME in use
+ Error-value=2: Speaker identity included for an LSP
+ that is not PCE initiated
+
+ 24 LSP instantiation error
+
+ Error-value=1: Unacceptable instantiation parameters
+ Error-value=2: Internal error
+ Error-value=3: Signaling error
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crabbe, et al. Standards Track [Page 17]
+
+RFC 8281 PCE-Initiated LSPs in Stateful PCE December 2017
+
+
+9. Security Considerations
+
+ The security considerations described in [RFC8231] apply to the
+ extensions described in this document. Additional considerations
+ related to a malicious PCE are introduced.
+
+9.1. Malicious PCE
+
+ The LSP instantiation mechanism described in this document allows a
+ PCE to generate state on the PCC and throughout the network. As a
+ result, it introduces a new attack vector: an attacker may flood the
+ PCC with LSP instantiation requests and consume network and LSR
+ resources by either spoofing messages or compromising the PCE itself.
+
+ A PCC can protect itself from such an attack by imposing a limit on
+ either the number of LSPs or the percentage of resources that are
+ allocated to honor PCE-initiated LSP requests. As soon as that limit
+ is reached, the PCC MUST send a PCErr message with Error-type=19
+ (Invalid Operation) and Error-value=6 (PCE-initiated LSP limit
+ reached) and is free to drop any incoming PCInitiate messages for LSP
+ initiation without additional processing.
+
+ Rapid flaps triggered by the PCE can also be an attack vector. A PCC
+ can protect itself from such an attack by imposing a limit on the
+ number of flaps per unit of time that it allows a PCE to generate.
+ As soon as that limit is reached, a PCC MUST send a PCErr message
+ with Error-type=19 (Invalid Operation) and Error-value=10
+ (PCE-initiated operation-frequency limit reached) and is free to
+ treat the session as having reached the limit in terms of resources
+ allocated to honor PCE-initiated LSP requests, either permanently or
+ for a locally-defined cool-off period.
+
+9.2. Malicious PCC
+
+ The LSP instantiation mechanism described in this document requires
+ the PCE to keep state for LSPs that it instantiates and relies on the
+ PCC responding (with either a state report or an error message) to
+ requests for LSP instantiation. A malicious PCC or one that reached
+ the limit of the number of PCE-initiated LSPs can ignore PCE requests
+ and consume PCE resources. A PCE can protect itself by imposing a
+ limit on the number of requests pending or by setting a timeout, and
+ it MAY take further action such as closing the session or removing
+ all the LSPs it initiated.
+
+
+
+
+
+
+
+
+Crabbe, et al. Standards Track [Page 18]
+
+RFC 8281 PCE-Initiated LSPs in Stateful PCE December 2017
+
+
+10. References
+
+10.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,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
+ Element (PCE) Communication Protocol (PCEP)", RFC 5440,
+ DOI 10.17487/RFC5440, March 2009,
+ <https://www.rfc-editor.org/info/rfc5440>.
+
+ [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
+ Used to Form Encoding Rules in Various Routing Protocol
+ Specifications", RFC 5511, DOI 10.17487/RFC5511, April
+ 2009, <https://www.rfc-editor.org/info/rfc5511>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+ [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
+ Computation Element Communication Protocol (PCEP)
+ Extensions for Stateful PCE", RFC 8231,
+ DOI 10.17487/RFC8231, September 2017,
+ <https://www.rfc-editor.org/info/rfc8231>.
+
+ [RFC8232] 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", RFC 8232,
+ DOI 10.17487/RFC8232, September 2017,
+ <https://www.rfc-editor.org/info/rfc8232>.
+
+10.2. Informative References
+
+ [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation
+ Element (PCE) Communication Protocol Generic
+ Requirements", RFC 4657, DOI 10.17487/RFC4657, September
+ 2006, <https://www.rfc-editor.org/info/rfc4657>.
+
+ [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
+ Stateful Path Computation Element (PCE)", RFC 8051,
+ DOI 10.17487/RFC8051, January 2017,
+ <https://www.rfc-editor.org/info/rfc8051>.
+
+
+
+
+
+Crabbe, et al. Standards Track [Page 19]
+
+RFC 8281 PCE-Initiated LSPs in Stateful PCE December 2017
+
+
+ [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+ Writing an IANA Considerations Section in RFCs", BCP 26,
+ RFC 8126, DOI 10.17487/RFC8126, June 2017,
+ <https://www.rfc-editor.org/info/rfc8126>.
+
+Acknowledgments
+
+ We would like to thank Jan Medved, Ambrose Kwong, Ramon Casellas,
+ Cyril Margaria, Dhruv Dhody, Raveendra Trovi, and Jon Hardwick for
+ their contributions to this document.
+
+Authors' Addresses
+
+ Edward Crabbe
+ Individual Contributor
+
+ Email: edward.crabbe@gmail.com
+
+
+ Ina Minei
+ Google, Inc.
+ 1600 Amphitheatre Parkway
+ Mountain View, CA 94043
+ United States of America
+
+ Email: inaminei@google.com
+
+
+ Siva Sivabalan
+ Cisco Systems, Inc.
+ 170 West Tasman Dr.
+ San Jose, CA 95134
+ United States of America
+
+ Email: msiva@cisco.com
+
+
+ Robert Varga
+ Pantheon Technologies SRO
+ Mlynske Nivy 56
+ Bratislava 821 05
+ Slovakia
+
+ Email: robert.varga@pantheon.tech
+
+
+
+
+
+
+
+Crabbe, et al. Standards Track [Page 20]
+