RFC 8623
Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs)
Pages: 33
Proposed Standard
Proposed Standard
Part 1 of 3 – Pages 1 to 10
Internet Engineering Task Force (IETF) U. Palle Request for Comments: 8623 D. Dhody Category: Standards Track Huawei Technologies ISSN: 2070-1721 Y. Tanaka NTT Communications V. Beeram Juniper Networks June 2019 Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs)Abstract
The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point- to-multipoint (P2MP) TE Label Switched Paths (LSPs). This document provides extensions required for the Path Computation Element Communication Protocol (PCEP) so as to enable the usage of a stateful PCE capability in supporting P2MP TE LSPs. 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/rfc8623.
Copyright Notice Copyright (c) 2019 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.Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Supporting P2MP TE LSPs for Stateful PCE . . . . . . . . . . 4 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 5 4. Functions to Support P2MP TE LSPs for Stateful PCEs . . . . . 5 5. Architectural Overview of Protocol Extensions . . . . . . . . 6 5.1. Extension of PCEP Messages . . . . . . . . . . . . . . . 6 5.2. Capability Advertisement . . . . . . . . . . . . . . . . 7 5.3. IGP Extensions for Stateful PCE P2MP Capabilities Advertisement . . . . . . . . . . . . . . . . . . . . . . 7 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 8 5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 8 5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . 9 5.6.1. Passive Stateful PCE . . . . . . . . . . . . . . . . 9 5.6.2. Active Stateful PCE . . . . . . . . . . . . . . . . . 9 5.6.3. PCE-Initiated LSP . . . . . . . . . . . . . . . . . . 9 5.6.3.1. P2MP TE LSPs Instantiation . . . . . . . . . . . 9 5.6.3.2. P2MP TE LSPs Deletion . . . . . . . . . . . . . . 10 5.6.3.3. Adding and Pruning Leaves for the P2MP TE LSP . . 10 5.6.3.4. P2MP TE LSPs Delegation and Cleanup . . . . . . . 10 6. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . 11 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 11 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 13 6.3. The PCReq Message . . . . . . . . . . . . . . . . . . . . 14 6.4. The PCRep Message . . . . . . . . . . . . . . . . . . . . 15 6.5. The PCInitiate Message . . . . . . . . . . . . . . . . . 16 6.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.6.1. P2MP TE LSPs Update Request . . . . . . . . . . . . . 17
6.6.2. P2MP TE LSP Report . . . . . . . . . . . . . . . . . 17
6.6.3. P2MP TE LSPs Initiation Request . . . . . . . . . . . 18
7. PCEP Object Extensions . . . . . . . . . . . . . . . . . . . 19
7.1. LSP Object Extension . . . . . . . . . . . . . . . . . . 19
7.1.1. P2MP-LSP-IDENTIFIERS TLV . . . . . . . . . . . . . . 19
7.2. S2LS Object . . . . . . . . . . . . . . . . . . . . . . . 22
8. Message Fragmentation . . . . . . . . . . . . . . . . . . . . 23
8.1. Report Fragmentation Procedure . . . . . . . . . . . . . 23
8.2. Update Fragmentation Procedure . . . . . . . . . . . . . 23
8.3. PCInitiate Fragmentation Procedure . . . . . . . . . . . 24
9. Nonsupport of P2MP TE LSPs for Stateful PCE . . . . . . . . . 24
10. Manageability Considerations . . . . . . . . . . . . . . . . 25
10.1. Control of Function and Policy . . . . . . . . . . . . . 25
10.2. Information and Data Models . . . . . . . . . . . . . . 25
10.3. Liveness Detection and Monitoring . . . . . . . . . . . 25
10.4. Verify Correct Operations . . . . . . . . . . . . . . . 26
10.5. Requirements on Other Protocols . . . . . . . . . . . . 26
10.6. Impact on Network Operations . . . . . . . . . . . . . . 26
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11.1. PCE Capabilities in IGP Advertisements . . . . . . . . . 26
11.2. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . 26
11.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 27
11.4. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . 27
11.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 28
11.6. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 28
11.7. S2LS Object . . . . . . . . . . . . . . . . . . . . . . 28
12. Security Considerations . . . . . . . . . . . . . . . . . . . 29
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
13.1. Normative References . . . . . . . . . . . . . . . . . . 29
13.2. Informative References . . . . . . . . . . . . . . . . . 31
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 32
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction
As per [RFC4655], the Path Computation Element (PCE) is an entity
that is capable of computing a network path or route based on a
network graph and applying computational constraints. A Path
Computation Client (PCC) may make requests to a PCE for paths to be
computed.
[RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic
Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
[RFC5671] examines the applicability of PCE for the path computation
for P2MP TE LSPs.
The PCEP is designed as a communication protocol between PCCs and PCEs for point-to-point (P2P) path computations and is defined in [RFC5440]. The extensions of PCEP to request path computation for P2MP TE LSPs are described in [RFC8306]. Stateful PCEs are shown to be helpful in many application scenarios, in both MPLS and GMPLS networks, as illustrated in [RFC8051]. These scenarios apply equally to P2P and P2MP TE LSPs. [RFC8231] provides the fundamental extensions to PCEP needed for stateful PCE to support general functionality for P2P TE LSP. [RFC8281] provides extensions to PCEP needed for stateful PCE-initiated P2P TE LSP. This document complements that work by focusing on PCEP extensions that are necessary in order for the deployment of stateful PCEs to support P2MP TE LSPs. This document describes the setup, maintenance, and teardown of PCE-initiated P2MP LSPs under the stateful PCE model.1.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.2. Terminology
Terminology used in this document is the same as terminology used in [RFC8231], [RFC8281], and [RFC8306].3. Supporting P2MP TE LSPs for Stateful PCE
3.1. Motivation
[RFC8051] presents several use cases, demonstrating scenarios that benefit from the deployment of a stateful PCE including optimization, recovery, etc., which are equally applicable to P2MP TE LSPs. [RFC8231] defines the extensions to PCEP needed for stateful operation of P2P TE LSPs. This document complements the previous work by focusing on extensions that are necessary in order for the deployment of stateful PCEs to support P2MP TE LSPs. In addition to that, the stateful nature of a PCE simplifies the information conveyed in PCEP messages since it is possible to refer to the LSPs via a PCEP-specific LSP identifier (PLSP-ID) ([RFC8231]). For P2MP, where the size of the message is much larger, this is an added advantage. When using a stateless PCE, a request to modify an existing P2MP tree requires that all the leaves are presented in the PCEP messages along with all the path information. But when using a
stateful PCE, the PCEP messages can use a PLSP-ID to represent all information about the LSP that has previously been exchanged in PCEP messages, and it is only necessary to encode the modifications (such as new or removed leaf nodes). The PLSP-ID provides an index into the LSP-DB at the PCE and identifies the LSP at the PCC. In environments where the P2MP TE LSPs placement needs to change in response to application demands, it is useful to support dynamic creation and tear down of P2MP TE LSPs. The ability for a PCE to trigger the creation of P2MP TE 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. Section 3 of [RFC8281] further describes the motivation behind the PCE-Initiation capability, which is equally applicable to P2MP TE LSPs.3.2. Objectives
The objectives for the protocol extensions to support P2MP TE LSPs for stateful PCE are the same as the objectives described in Section 3.2 of [RFC8231].4. Functions to Support P2MP TE LSPs for Stateful PCEs
[RFC8231] specifies new functions to support a stateful PCE. It also specifies that a function can be initiated either from a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C). This document extends these functions to support P2MP TE LSPs: Capability Advertisement (E-C,C-E): Both the PCC and the PCE must announce during PCEP session establishment that they support Stateful PCE extensions for P2MP using mechanisms defined in Section 5.2. LSP State Synchronization (C-E): After the session between the PCC and a stateful PCE with P2MP capability is initialized, the PCE must learn the state of a PCC's P2MP TE LSPs before it can perform path computations or update LSP attributes in a PCC. LSP Update Request (E-C): A stateful PCE with P2MP capability requests modification of attributes on a PCC's P2MP TE LSPs. LSP State Report (C-E): A PCC sends an LSP state report to a PCE whenever the state of a P2MP TE LSP changes.
LSP Control Delegation (C-E,E-C): A PCC grants to a PCE the right to
update LSP attributes on one or more P2MP TE LSPs; the PCE becomes
the authoritative source of the LSP's attributes as long as the
delegation is in effect (See Section 5.7 of [RFC8231]); the PCC
may withdraw the delegation or the PCE may give up the delegation
at any time.
PCE-initiated LSP instantiation (E-C): A PCE sends an LSP Initiate
Message to a PCC to instantiate or delete a P2MP TE LSP [RFC8281].
5. Architectural Overview of Protocol Extensions
5.1. Extension of PCEP Messages
Two new PCEP messages are defined in [RFC8231] to support stateful
PCE for P2P TE LSPs. In this document, these messages are extended
as follows to support P2MP TE LSPs.
Path Computation State Report (PCRpt): Each P2MP TE LSP State Report
in a PCRpt message contains the actual P2MP TE LSP path
attributes, the LSP status, etc. An LSP State Report carried in a
PCRpt message is also used in delegation or revocation of control
of a P2MP TE LSP to/from a PCE. The extension of PCRpt messages
is described in Section 6.1.
Path Computation Update Request (PCUpd): Each P2MP TE LSP Update
Request in a PCUpd message MUST contain all LSP parameters that a
PCE wishes to set for a given P2MP TE LSP. An LSP Update Request
carried in a PCUpd message is also used to return LSP delegations
if at any point the PCE no longer desires control of a P2MP TE
LSP. The PCUpd message is described in Section 6.2.
Further, a new PCEP message is defined in [RFC8281] to support
stateful PCE instantiation of P2P TE LSPs. In this document, this
message is extended as follows to support P2MP TE LSPs.
Path Computation LSP Initiate Message (PCInitiate): PCInitiate is a
PCEP message sent by a PCE to a PCC to trigger the instantiation
or deletion of a P2MP TE LSP. The PCInitiate message is described
in Section 6.5.
The Path Computation Request (PCReq) and Path Computation Reply
(PCRep) messages are also extended to support passive stateful PCE
for P2P TE LSPs in [RFC8231]. In this document, these messages are
extended to support P2MP TE LSPs as well.
5.2. Capability Advertisement
During the PCEP initialization phase, as per Section 7.1.1 of [RFC8231], PCEP speakers advertise Stateful capability via the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. Various flags are defined for the STATEFUL-PCE-CAPABILITY TLV defined in [RFC8231] and updated in [RFC8281] and [RFC8232]. Three new flags, N (P2MP-CAPABILITY), M (P2MP-LSP-UPDATE-CAPABILITY), and P (P2MP-LSP-INSTANTIATION-CAPABILITY), are added in this document: N (P2MP-CAPABILITY flag - 1 bit): If set to 1 by a PCC, the N Flag indicates that the PCC is willing to send P2MP LSP State Reports whenever there's a change to the parameters or operational status of the P2MP LSP; if set to 1 by a PCE, the N Flag indicates that the PCE is interested in receiving LSP State Reports whenever there is a parameter or operational status change to the P2MP LSP. The P2MP-CAPABILITY Flag MUST be advertised by both a PCC and a PCE for the P2MP extension (as per this document) of the PCRpt messages to be allowed on a PCEP session. M (P2MP-LSP-UPDATE-CAPABILITY flag - 1 bit): If set to 1 by a PCC, the M Flag indicates that the PCC allows modification of P2MP LSP parameters; if set to 1 by a PCE, the M Flag indicates that the PCE is capable of updating P2MP LSP parameters. The P2MP-LSP- UPDATE-CAPABILITY Flag MUST be advertised by both a PCC and a PCE for the P2MP extension (as per this document) of the PCUpd messages to be allowed on a PCEP session. P (P2MP-LSP-INSTANTIATION-CAPABILITY flag - 1 bit): If set to 1 by a PCC, the P Flag indicates that the PCC allows instantiation of a P2MP LSP by a PCE. If set to 1 by a PCE, the P flag indicates that the PCE supports P2MP LSP instantiation. The P2MP-LSP- INSTANTIATION-CAPABILITY flag MUST be set by both PCC and PCE in order to support PCE-initiated P2MP LSP instantiation. A PCEP speaker should continue to advertise the basic P2MP capability via mechanisms as described in [RFC8306].5.3. IGP Extensions for Stateful PCE P2MP Capabilities Advertisement
When the PCC is a Label Switching Router (LSR) participating in the IGP (either OSPF or IS-IS), and PCEs are either LSRs or servers also participating in the IGP, an effective mechanism for PCE discovery within an IGP routing domain consists of utilizing IGP
advertisements. Extensions for the advertisement of PCE discovery information are defined for OSPF and for IS-IS in [RFC5088] and [RFC5089], respectively. The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional sub- TLV used to advertise PCE capabilities. It MAY be present within the PCE Discovery (PCED) TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] provide the description and processing rules for this sub- TLV when carried within OSPF and IS-IS, respectively. The format of the PCE-CAP-FLAGS sub-TLV is included below for easy reference: Type: 5 Length: Multiple of 4 Value: This contains an array of units of 32-bit flags with the most significant bit as 0. Each bit represents one PCE capability. PCE capability bit flags are defined in [RFC5088]. This document defines new capability bits for the stateful PCE with P2MP as follows: Bit Capability 13 Active Stateful PCE with P2MP 14 Passive Stateful PCE with P2MP 15 PCE-Initiation with P2MP Note that, while active, passive, or initiation stateful PCE capabilities for P2MP may be advertised during discovery, PCEP Speakers that wish to use stateful PCEP for P2MP TE LSPs MUST advertise stateful PCEP capabilities during PCEP session setup, as specified in the current document. A PCC MAY initiate stateful PCEP P2MP capability advertisement at PCEP session setup even if it did not receive any IGP PCE capability advertisements.5.4. State Synchronization
State Synchronization operations (described in Section 5.6 of [RFC8231]) are applicable for the P2MP TE LSPs as well. The optimizations described in [RFC8232] can also be applied for P2MP TE LSPs.5.5. LSP Delegation
LSP delegation operations (described in Section 5.7 of [RFC8231]) are applicable for P2MP TE LSPs as well.
5.6. LSP Operations
5.6.1. Passive Stateful PCE
LSP operations for passive stateful PCE (described in Section 5.8.1 of [RFC8231]) are applicable for P2MP TE LSPs as well. The PCReq and PCRep message format for P2MP TE LSPs is described in Sections 3.4 and 3.5 of [RFC8306], respectively. The PCReq and PCRep message for P2MP TE LSPs are extended to support encoding of the LSP object so that it is possible to refer to an LSP with a unique identifier and simplify the PCEP message exchange. For example, in case of modification of one leaf in a P2MP tree, there should be no need to carry the full P2MP tree in a PCReq message. The extensions for the Request and Response message for passive stateful operations on P2MP TE LSPs are described in Sections 6.3 and 6.4. The extension for the Path Computation LSP State Report (PCRpt) message is described in Section 6.1.5.6.2. Active Stateful PCE
LSP operations for active stateful PCE (described in Section 5.8.2 of [RFC8231]) are applicable for P2MP TE LSPs as well. The extension for the Path Computation LSP Update (PCUpd) message for active stateful operations on P2MP TE LSPs is described in Section 6.2.5.6.3. PCE-Initiated LSP
As per Section 5.1 of [RFC8281], the PCE sends a Path Computation LSP Initiate Request (PCInitiate) message to the PCC to suggest instantiation or deletion of a P2P TE LSP. This document extends the PCInitiate message to support P2MP TE LSPs (see details in Section 6.5). The instantiation and deletion operations for P2MP TE LSPs are the same as for P2P LSPs as described in Sections 5.3 and 5.4 of [RFC8281].5.6.3.1. P2MP TE LSPs Instantiation
The instantiation operation of P2MP TE LSPs is the same as the LSP instantiation operation defined in Section 5.3 of [RFC8281]; this includes the handling of the PLSP-ID, SYMBOLIC-PATH-NAME TLV, etc. The processing rules and use of error codes remain unchanged. The N
(P2MP) flag (Section 7.1) MUST be set in the LSP object in the PCInitiate message by the PCE to specify that the instantiation is for P2MP TE LSPs. Like the PLSP-ID (as per [RFC8281]), the P2MP-LSP- IDENTIFIERS TLV SHOULD NOT be included in the LSP object in PCInitiate messages and MUST be ignored on receipt. These identifiers are generated by the PCC on receipt of the PCInitiate message and reported via a PCRpt message to the PCE.5.6.3.2. P2MP TE LSPs Deletion
The deletion operation of P2MP TE LSPs is the same as the LSP deletion operation defined in Section 5.4 of [RFC8281]; this entails sending an LSP Initiate Message with an LSP object carrying the PLSP- ID of the LSP to be removed as well as a Stateful PCE Request Parameter (SRP) object with the R flag set (LSP-REMOVE as per Section 5.2 of [RFC8281]). The processing rules and error codes remain unchanged.5.6.3.3. Adding and Pruning Leaves for the P2MP TE LSP
The adding of new leaves and pruning of old leaves for the PCE- initiated P2MP TE LSP MUST be carried in a PCUpd message as per Section 6.2 for P2MP TE LSP extensions. As defined in [RFC8306], leaf type = 1 is used for adding new leaves, and leaf type = 2 is used for pruning old leaves of P2MP END-POINTS Objects. PCC MAY use the Incremental State Update mechanism as described in [RFC4875] to signal the adding and pruning of leaves. Section 3.10 of [RFC8306] defines the error-handling procedures when adding new leaves to or removing old leaves from the existing P2MP tree for PCReq messages. The same error handling and error codes are also applicable to the stateful PCE messages as described in this document.5.6.3.4. P2MP TE LSPs Delegation and Cleanup
P2MP TE LSPs delegation and cleanup operations are the same as the LSP delegation and cleanup operations defined in Section 6 of [RFC8281]. The processing rules and error codes remain unchanged.
(next page on part 2)