8623
PROPOSED STANDARD
Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs)
Authors: U. Palle, D. Dhody, Y. Tanaka, V. Beeram
Date: June 2019
Area: rtg
Working Group: pce
Stream: IETF
Updated by:
RFC 9756
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.
RFC 8623
PROPOSED STANDARD
Updated by: 9756
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
<span class="h1">Stateful Path Computation Element (PCE) Protocol Extensions</span>
<span class="h1">for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs)</span>
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 <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8623">https://www.rfc-editor.org/info/rfc8623</a>.
<span class="grey">Palle, et al. Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) 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
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Requirements Language . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. Supporting P2MP TE LSPs for Stateful PCE . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. Motivation . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.2">3.2</a>. Objectives . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4">4</a>. Functions to Support P2MP TE LSPs for Stateful PCEs . . . . . <a href="#page-5">5</a>
<a href="#section-5">5</a>. Architectural Overview of Protocol Extensions . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.1">5.1</a>. Extension of PCEP Messages . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.2">5.2</a>. Capability Advertisement . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
5.3. IGP Extensions for Stateful PCE P2MP Capabilities
Advertisement . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5.4">5.4</a>. State Synchronization . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5.5">5.5</a>. LSP Delegation . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5.6">5.6</a>. LSP Operations . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5.6.1">5.6.1</a>. Passive Stateful PCE . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5.6.2">5.6.2</a>. Active Stateful PCE . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5.6.3">5.6.3</a>. PCE-Initiated LSP . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5.6.3.1">5.6.3.1</a>. P2MP TE LSPs Instantiation . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5.6.3.2">5.6.3.2</a>. P2MP TE LSPs Deletion . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5.6.3.3">5.6.3.3</a>. Adding and Pruning Leaves for the P2MP TE LSP . . <a href="#page-10">10</a>
<a href="#section-5.6.3.4">5.6.3.4</a>. P2MP TE LSPs Delegation and Cleanup . . . . . . . <a href="#page-10">10</a>
<a href="#section-6">6</a>. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-6.1">6.1</a>. The PCRpt Message . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-6.2">6.2</a>. The PCUpd Message . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-6.3">6.3</a>. The PCReq Message . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-6.4">6.4</a>. The PCRep Message . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-6.5">6.5</a>. The PCInitiate Message . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-6.6">6.6</a>. Example . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<span class="grey">Palle, et al. Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
<a href="#section-6.6.1">6.6.1</a>. P2MP TE LSPs Update Request . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-6.6.2">6.6.2</a>. P2MP TE LSP Report . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-6.6.3">6.6.3</a>. P2MP TE LSPs Initiation Request . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-7">7</a>. PCEP Object Extensions . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-7.1">7.1</a>. LSP Object Extension . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-7.1.1">7.1.1</a>. P2MP-LSP-IDENTIFIERS TLV . . . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-7.2">7.2</a>. S2LS Object . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
<a href="#section-8">8</a>. Message Fragmentation . . . . . . . . . . . . . . . . . . . . <a href="#page-23">23</a>
<a href="#section-8.1">8.1</a>. Report Fragmentation Procedure . . . . . . . . . . . . . <a href="#page-23">23</a>
<a href="#section-8.2">8.2</a>. Update Fragmentation Procedure . . . . . . . . . . . . . <a href="#page-23">23</a>
<a href="#section-8.3">8.3</a>. PCInitiate Fragmentation Procedure . . . . . . . . . . . <a href="#page-24">24</a>
<a href="#section-9">9</a>. Nonsupport of P2MP TE LSPs for Stateful PCE . . . . . . . . . <a href="#page-24">24</a>
<a href="#section-10">10</a>. Manageability Considerations . . . . . . . . . . . . . . . . <a href="#page-25">25</a>
<a href="#section-10.1">10.1</a>. Control of Function and Policy . . . . . . . . . . . . . <a href="#page-25">25</a>
<a href="#section-10.2">10.2</a>. Information and Data Models . . . . . . . . . . . . . . <a href="#page-25">25</a>
<a href="#section-10.3">10.3</a>. Liveness Detection and Monitoring . . . . . . . . . . . <a href="#page-25">25</a>
<a href="#section-10.4">10.4</a>. Verify Correct Operations . . . . . . . . . . . . . . . <a href="#page-26">26</a>
<a href="#section-10.5">10.5</a>. Requirements on Other Protocols . . . . . . . . . . . . <a href="#page-26">26</a>
<a href="#section-10.6">10.6</a>. Impact on Network Operations . . . . . . . . . . . . . . <a href="#page-26">26</a>
<a href="#section-11">11</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-26">26</a>
<a href="#section-11.1">11.1</a>. PCE Capabilities in IGP Advertisements . . . . . . . . . <a href="#page-26">26</a>
<a href="#section-11.2">11.2</a>. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . <a href="#page-26">26</a>
<a href="#section-11.3">11.3</a>. LSP Object . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-27">27</a>
<a href="#section-11.4">11.4</a>. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . <a href="#page-27">27</a>
<a href="#section-11.5">11.5</a>. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . <a href="#page-28">28</a>
<a href="#section-11.6">11.6</a>. PCEP Object . . . . . . . . . . . . . . . . . . . . . . <a href="#page-28">28</a>
<a href="#section-11.7">11.7</a>. S2LS Object . . . . . . . . . . . . . . . . . . . . . . <a href="#page-28">28</a>
<a href="#section-12">12</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-29">29</a>
<a href="#section-13">13</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-29">29</a>
<a href="#section-13.1">13.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-29">29</a>
<a href="#section-13.2">13.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-31">31</a>
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-32">32</a>
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-32">32</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-33">33</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
As per [<a href="./rfc4655" title=""A Path Computation Element (PCE)-Based Architecture"">RFC4655</a>], 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.
[<a id="ref-RFC4875">RFC4875</a>] 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.
[<a href="./rfc5671" title=""Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)"">RFC5671</a>] examines the applicability of PCE for the path computation
for P2MP TE LSPs.
<span class="grey">Palle, et al. Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
The PCEP is designed as a communication protocol between PCCs and
PCEs for point-to-point (P2P) path computations and is defined in
[<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]. The extensions of PCEP to request path computation for
P2MP TE LSPs are described in [<a href="./rfc8306" title=""Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths"">RFC8306</a>].
Stateful PCEs are shown to be helpful in many application scenarios,
in both MPLS and GMPLS networks, as illustrated in [<a href="./rfc8051" title=""Applicability of a Stateful Path Computation Element (PCE)"">RFC8051</a>]. These
scenarios apply equally to P2P and P2MP TE LSPs. [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>] provides
the fundamental extensions to PCEP needed for stateful PCE to support
general functionality for P2P TE LSP. [<a href="./rfc8281" title=""Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model"">RFC8281</a>] 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.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Requirements Language</span>
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
<a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
Terminology used in this document is the same as terminology used in
[<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>], [<a href="./rfc8281" title=""Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model"">RFC8281</a>], and [<a href="./rfc8306" title=""Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths"">RFC8306</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Supporting P2MP TE LSPs for Stateful PCE</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Motivation</span>
[<a id="ref-RFC8051">RFC8051</a>] 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.
[<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>] 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) ([<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>]).
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
<span class="grey">Palle, et al. Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
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. <a href="./rfc8281#section-3">Section 3 of [RFC8281]</a> further describes the motivation
behind the PCE-Initiation capability, which is equally applicable to
P2MP TE LSPs.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Objectives</span>
The objectives for the protocol extensions to support P2MP TE LSPs
for stateful PCE are the same as the objectives described in
<a href="./rfc8231#section-3.2">Section 3.2 of [RFC8231]</a>.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Functions to Support P2MP TE LSPs for Stateful PCEs</span>
[<a id="ref-RFC8231">RFC8231</a>] 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
<a href="#section-5.2">Section 5.2</a>.
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.
<span class="grey">Palle, et al. Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
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 <a href="./rfc8231#section-5.7">Section 5.7 of [RFC8231]</a>); 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 [<a href="./rfc8281" title=""Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model"">RFC8281</a>].
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Architectural Overview of Protocol Extensions</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Extension of PCEP Messages</span>
Two new PCEP messages are defined in [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>] 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 <a href="#section-6.1">Section 6.1</a>.
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 <a href="#section-6.2">Section 6.2</a>.
Further, a new PCEP message is defined in [<a href="./rfc8281" title=""Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model"">RFC8281</a>] 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 <a href="#section-6.5">Section 6.5</a>.
The Path Computation Request (PCReq) and Path Computation Reply
(PCRep) messages are also extended to support passive stateful PCE
for P2P TE LSPs in [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>]. In this document, these messages are
extended to support P2MP TE LSPs as well.
<span class="grey">Palle, et al. Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Capability Advertisement</span>
During the PCEP initialization phase, as per <a href="./rfc8231#section-7.1.1">Section 7.1.1 of
[RFC8231]</a>, 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 [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>] and
updated in [<a href="./rfc8281" title=""Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model"">RFC8281</a>] and [<a href="./rfc8232" title=""Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE"">RFC8232</a>].
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 [<a href="./rfc8306" title=""Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths"">RFC8306</a>].
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. IGP Extensions for Stateful PCE P2MP Capabilities Advertisement</span>
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
<span class="grey">Palle, et al. Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
advertisements. Extensions for the advertisement of PCE discovery
information are defined for OSPF and for IS-IS in [<a href="./rfc5088" title=""OSPF Protocol Extensions for Path Computation Element (PCE) Discovery"">RFC5088</a>] and
[<a href="./rfc5089" title=""IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery"">RFC5089</a>], respectively.
The PCE-CAP-FLAGS sub-TLV, defined in [<a href="./rfc5089" title=""IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery"">RFC5089</a>], 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. [<a href="./rfc5088" title=""OSPF Protocol Extensions for Path Computation Element (PCE) Discovery"">RFC5088</a>] and
[<a href="./rfc5089" title=""IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery"">RFC5089</a>] 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 [<a href="./rfc5088" title=""OSPF Protocol Extensions for Path Computation Element (PCE) Discovery"">RFC5088</a>]. 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.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. State Synchronization</span>
State Synchronization operations (described in <a href="./rfc8231#section-5.6">Section 5.6 of
[RFC8231]</a>) are applicable for the P2MP TE LSPs as well. The
optimizations described in [<a href="./rfc8232" title=""Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE"">RFC8232</a>] can also be applied for P2MP TE
LSPs.
<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>. LSP Delegation</span>
LSP delegation operations (described in <a href="./rfc8231#section-5.7">Section 5.7 of [RFC8231]</a>) are
applicable for P2MP TE LSPs as well.
<span class="grey">Palle, et al. Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a>. LSP Operations</span>
<span class="h4"><a class="selflink" id="section-5.6.1" href="#section-5.6.1">5.6.1</a>. Passive Stateful PCE</span>
LSP operations for passive stateful PCE (described in <a href="./rfc8231#section-5.8.1">Section 5.8.1
of [RFC8231]</a>) are applicable for P2MP TE LSPs as well.
The PCReq and PCRep message format for P2MP TE LSPs is described in
Sections <a href="#section-3.4">3.4</a> and <a href="#section-3.5">3.5</a> of [<a href="./rfc8306" title=""Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths"">RFC8306</a>], 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 <a href="#section-6.3">6.3</a> and
6.4. The extension for the Path Computation LSP State Report (PCRpt)
message is described in <a href="#section-6.1">Section 6.1</a>.
<span class="h4"><a class="selflink" id="section-5.6.2" href="#section-5.6.2">5.6.2</a>. Active Stateful PCE</span>
LSP operations for active stateful PCE (described in <a href="./rfc8231#section-5.8.2">Section 5.8.2 of
[RFC8231]</a>) 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
<a href="#section-6.2">Section 6.2</a>.
<span class="h4"><a class="selflink" id="section-5.6.3" href="#section-5.6.3">5.6.3</a>. PCE-Initiated LSP</span>
As per <a href="./rfc8281#section-5.1">Section 5.1 of [RFC8281]</a>, 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
<a href="#section-6.5">Section 6.5</a>).
The instantiation and deletion operations for P2MP TE LSPs are the
same as for P2P LSPs as described in Sections <a href="#section-5.3">5.3</a> and <a href="#section-5.4">5.4</a> of
[<a href="./rfc8281" title=""Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model"">RFC8281</a>].
<span class="h5"><a class="selflink" id="section-5.6.3.1" href="#section-5.6.3.1">5.6.3.1</a>. P2MP TE LSPs Instantiation</span>
The instantiation operation of P2MP TE LSPs is the same as the LSP
instantiation operation defined in <a href="./rfc8281#section-5.3">Section 5.3 of [RFC8281]</a>; 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
<span class="grey">Palle, et al. Standards Track [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
(P2MP) flag (<a href="#section-7.1">Section 7.1</a>) 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 [<a href="./rfc8281" title=""Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model"">RFC8281</a>]), 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.
<span class="h5"><a class="selflink" id="section-5.6.3.2" href="#section-5.6.3.2">5.6.3.2</a>. P2MP TE LSPs Deletion</span>
The deletion operation of P2MP TE LSPs is the same as the LSP
deletion operation defined in <a href="./rfc8281#section-5.4">Section 5.4 of [RFC8281]</a>; 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
<a href="./rfc8281#section-5.2">Section 5.2 of [RFC8281]</a>). The processing rules and error codes
remain unchanged.
<span class="h5"><a class="selflink" id="section-5.6.3.3" href="#section-5.6.3.3">5.6.3.3</a>. Adding and Pruning Leaves for the P2MP TE LSP</span>
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
<a href="#section-6.2">Section 6.2</a> for P2MP TE LSP extensions. As defined in [<a href="./rfc8306" title=""Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths"">RFC8306</a>],
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
[<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>] to signal the adding and pruning of leaves.
<a href="./rfc8306#section-3.10">Section 3.10 of [RFC8306]</a> 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.
<span class="h5"><a class="selflink" id="section-5.6.3.4" href="#section-5.6.3.4">5.6.3.4</a>. P2MP TE LSPs Delegation and Cleanup</span>
P2MP TE LSPs delegation and cleanup operations are the same as the
LSP delegation and cleanup operations defined in <a href="./rfc8281#section-6">Section 6 of
[RFC8281]</a>. The processing rules and error codes remain unchanged.
<span class="grey">Palle, et al. Standards Track [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. PCEP Message Extensions</span>
Message formats in this section, as those in [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>], [<a href="./rfc8281" title=""Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model"">RFC8281</a>],
and [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>], are presented using Routing Backus-Naur Format (RBNF)
as specified in [<a href="./rfc5511" title=""Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications"">RFC5511</a>].
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. The PCRpt Message</span>
As per <a href="./rfc8231#section-6.1">Section 6.1 of [RFC8231]</a>, a PCRpt message is used to report
the current state of a P2P TE LSP. This document extends the PCRpt
message in reporting the status of P2MP TE LSPs.
The format of a PCRpt message is as follows:
<PCRpt Message> ::= <Common Header>
<state-report-list>
Where:
<state-report-list> ::= <state-report>
[<state-report-list>]
<state-report> ::= [<SRP>]
<LSP>
<path>
Where:
<path> ::= <end-point-intended-path-pair-list>
[<actual-attribute-list>
<end-point-actual-path-pair-list>]
[<intended-attribute-list>]
<end-point-intended-path-pair-list>::=
[<END-POINTS>]
[<S2LS>]
<intended-path>
[<end-point-intended-path-pair-list>]
<end-point-actual-path-pair-list>::=
[<END-POINTS>]
[<S2LS>]
<actual-path>
[<end-point-actual-path-pair-list>]
<intended-path> ::= (<ERO>|<SERO>)
[<intended-path>]
<actual-path> ::= (<RRO>|<SRRO>)
[<actual-path>]
<span class="grey">Palle, et al. Standards Track [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
<intended-attribute-list> is defined in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>] and extended by
PCEP extensions.
<actual-attribute-list> consists of the actual computed and signaled
values of the <BANDWIDTH> and <metric-lists> objects defined in
[<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>].
The P2MP END-POINTS object defined in [<a href="./rfc8306" title=""Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths"">RFC8306</a>] is mandatory for
specifying the address of P2MP leaves, grouped by leaf types.
o New leaves to add (leaf type = 1)
o Old leaves to remove (leaf type = 2)
o Old leaves whose path can be modified/reoptimized (leaf type = 3)
o Old leaves whose path must be left unchanged (leaf type = 4)
When reporting the status of a P2MP TE LSP, the destinations MUST be
grouped in the END-POINTS object based on the operational status (O
field in S2LS objects) and leaf type (in END-POINTS objects). This
way, leaves of the same type that share the same operational status
can be grouped together. For reporting the status of delegated P2MP
TE LSPs, leaf type = 3 is used, whereas for nondelegated P2MP TE
LSPs, leaf type = 4 is used.
For a delegated P2MP TE LSP, configuration changes are reported via a
PCRpt message. For example, for adding new leaves, leaf type = 1 is
used in the END-POINTS object, and for removing old leaves, leaf type
= 2 is used.
Note that the compatibility with the [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>] definition of <state-
report> is preserved. At least one instance of <END-POINTS> MUST be
present in this message for P2MP LSP.
Note that the ordering of <end-point-intended-path-pair-list>,
<actual-attribute-list>, <end-point-actual-path-pair-list>, and
<intended-attribute-list> is done to retain compatibility with state
reports for the P2P LSPs as per [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>].
During state synchronization, the PCRpt message reports the status of
the full P2MP tree.
The S2LS object MUST be carried in a PCRpt message along with the
END-POINTS object when an N (P2MP) flag is set in an LSP object for
P2MP TE LSPs. If the S2LS object is missing, the receiving PCE MUST
send a PCEP Error (PCErr) message with Error-type=6 ("Mandatory
Object missing") and Error-value=13 ("S2LS object missing"). If the
<span class="grey">Palle, et al. Standards Track [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
END-POINTS object is missing, the receiving PCE MUST send a PCErr
message with Error-type=6 ("Mandatory Object missing") and Error-
value=3 ("END-POINTS object missing") (defined in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>].
The S2LS object could be used in conjunction with the intended-path
(EXPLICIT_ROUTE object or ERO) as well as the actual-path
(RECORD_ROUTE object or RRO); for the same leaf, the state encoded in
the S2LS object associated with the actual-path MUST be used over the
intended-path.
If the E-bit (ERO-Compress bit) was set to 1 in the report, then the
path will be formed by an ERO followed by a list of
SECONDARY_EXPLICIT_ROUTE Objects (SEROs), or an RRO followed by a
list of SECONDARY_RECORD_ROUTE Objects (SRROs).
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. The PCUpd Message</span>
As per <a href="./rfc8231#section-6.2">Section 6.2 of [RFC8231]</a>, a PCUpd message is used to update
P2P TE LSP attributes. This document extends the PCUpd message in
updating the attributes of a P2MP TE LSP.
The format of a PCUpd message is as follows:
<PCUpd Message> ::= <Common Header>
<update-request-list>
Where:
<update-request-list> ::= <update-request>
[<update-request-list>]
<update-request> ::= <SRP>
<LSP>
<path>
Where:
<path> ::= <end-point-path-pair-list>
<intended-attribute-list>
<end-point-path-pair-list>::=
[<END-POINTS>]
<intended-path>
[<end-point-path-pair-list>]
<intended-path> ::= (<ERO>|<SERO>)
[<intended-path>]
<span class="grey">Palle, et al. Standards Track [Page 13]</span><span id="page-14" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
<intended-attribute-list> is the attribute-list defined in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]
and extended by PCEP extensions.
Note that the compatibility with the [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>] definition of <update-
request> is preserved.
The PCC SHOULD use the make-before-break or sub-group-based
procedures described in [<a href="./rfc4875" title=""Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)"">RFC4875</a>] based on a local policy decision.
The END-POINTS object MUST be carried in a PCUpd message when the N
flag is set in the LSP object for a P2MP TE LSP. If the END-POINTS
object is missing, the receiving PCC MUST send a PCErr message with
Error-type=6 ("Mandatory Object missing") and Error-value=3
("END-POINTS object missing") (defined in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]).
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. The PCReq Message</span>
As per <a href="./rfc8306#section-3.4">Section 3.4 of [RFC8306]</a>, a PCReq message is used for a P2MP
Path Computation Request. This document extends the PCReq message
such that a PCC MAY include the LSP object in the PCReq message if
the stateful PCE P2MP capability has been negotiated on a PCEP
session between the PCC and a PCE.
The format of a PCReq message is as follows:
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
where:
<svec-list>::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<end-point-rro-pair-list>
[<LSP>]
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>|<BNC>]
[<LOAD-BALANCING>]
<span class="grey">Palle, et al. Standards Track [Page 14]</span><span id="page-15" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
<end-point-rro-pair-list>::= <END-POINTS>
[<RRO-List>[<BANDWIDTH>]]
[<end-point-rro-pair-list>]
<RRO-List>::=(<RRO>|<SRRO>)[<RRO-List>]
<metric-list>::=<METRIC>[<metric-list>]
<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>. The PCRep Message</span>
As per <a href="./rfc8306#section-3.5">Section 3.5 of [RFC8306]</a>, a PCRep message is used for a P2MP
Path Computation Reply. This document extends the PCRep message such
that a PCE MAY include the LSP object in the PCRep message if the
stateful PCE P2MP capability has been negotiated on a PCEP session
between the PCC and a PCE.
The format of a PCRep message is as follows:
<PCRep Message>::= <Common Header>
<response-list>
where:
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<end-point-path-pair-list>]
[<LSP>]
[<NO-PATH>]
[<UNREACH-DESTINATION>]
[<attribute-list>]
<end-point-path-pair-list>::= [<END-POINTS>]
<path>
[<end-point-path-pair-list>]
<path> ::= (<ERO>|<SERO>) [<path>]
<attribute-list>::=[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<span class="grey">Palle, et al. Standards Track [Page 15]</span><span id="page-16" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>. The PCInitiate Message</span>
As defined in <a href="./rfc8281#section-5.1">section 5.1 of [RFC8281]</a>, a PCE sends a PCInitiate
message to a PCC to recommend instantiation of a P2P TE LSP. This
document extends the format of a PCInitiate message for the creation
of P2MP TE LSPs, but the creation and deletion operations of P2MP TE
LSPs are the same to the P2P TE LSPs.
The format of a PCInitiate message is as follows:
<PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list>
Where:
<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-point-path-pair-list>
[<attribute-list>]
<PCE-initiated-lsp-deletion> ::= <SRP>
<LSP>
Where:
<end-point-path-pair-list>::=
[<END-POINTS>]
<intended-path>
[<end-point-path-pair-list>]
<intended-path> ::= (<ERO>|<SERO>)
[<intended-path>]
<attribute-list> is defined in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>] and extended by PCEP
extensions.
The PCInitiate message with an LSP object with the N flag (P2MP) set
is used to convey operation on a P2MP TE LSP. The SRP object is used
to correlate between initiation requests sent by the PCE, and the
error reports and state reports sent by the PCC as described in
[<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>].
<span class="grey">Palle, et al. Standards Track [Page 16]</span><span id="page-17" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
The END-POINTS object MUST be carried in a PCInitiate message when
the N flag is set in an LSP object for a P2MP TE LSP. If the END-
POINTS object is missing, the receiving PCC MUST send a PCErr message
with Error-type=6 ("Mandatory Object missing") and Error-value=3
("END-POINTS object missing") (defined in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]).
<span class="h3"><a class="selflink" id="section-6.6" href="#section-6.6">6.6</a>. Example</span>
<span class="h4"><a class="selflink" id="section-6.6.1" href="#section-6.6.1">6.6.1</a>. P2MP TE LSPs Update Request</span>
An LSP Update Request message is sent by an active stateful PCE to
update the P2MP TE LSPs parameters or attributes. An example of a
PCUpd message for P2MP TE LSPs is described below:
Common Header
SRP
LSP with P2MP flag set
END-POINTS for leaf type 3
ERO list
In this example, a stateful PCE requests an update of the path taken
to some of the leaves in a P2MP tree. The update request uses the
END-POINT type 3 (modified/reoptimized). The ERO list represents the
source-to-leaves path after modification. The update message does
not need to encode the full P2MP tree in this case.
<span class="h4"><a class="selflink" id="section-6.6.2" href="#section-6.6.2">6.6.2</a>. P2MP TE LSP Report</span>
The LSP State Report message is sent by a PCC to report or delegate
the P2MP TE LSP. The leaves of the P2MP TE LSP are grouped in the
END-POINTS object based on the operational status and the leaf type.
An example of a PCRpt message is described below for a delegated P2MP
TE LSP to add new leaves to an existing P2MP TE LSP:
Common Header
LSP with P2MP flag set
END-POINTS for leaf type 1 (add)
S2LS (O=DOWN)
ERO list (empty)
An example of a PCRpt message for a P2MP TE LSP is described below to
prune leaves from an existing P2MP TE LSP:
Common Header
LSP with P2MP flag set
END-POINTS for leaf type 2 (remove)
S2LS (O=UP)
ERO list (empty)
<span class="grey">Palle, et al. Standards Track [Page 17]</span><span id="page-18" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
An example of a PCRpt message for a delegated P2MP TE LSP is
described below to report the status of leaves in an existing P2MP TE
LSP:
Common Header
SRP
LSP with P2MP flag set
END-POINTS for leaf type 3 (modify)
S2LS (O=UP)
RRO list
END-POINTS for leaf type 3 (modify)
S2LS (O=DOWN)
ERO list (empty)
In this example, the PCRpt message is in response to a PCUpd message.
The PCRpt message includes the corresponding SRP object and indicates
that some leaves are up (with the actual path) and some are down.
An example of a PCRpt message for a nondelegated P2MP TE LSP is
described below to report status of leaves:
Common Header
LSP with P2MP flag set
END-POINTS for leaf type 4 (unchanged)
S2LS (O=ACTIVE)
RRO list
END-POINTS for leaf type 4 (unchanged)
S2LS (O=DOWN)
ERO list (empty)
<span class="h4"><a class="selflink" id="section-6.6.3" href="#section-6.6.3">6.6.3</a>. P2MP TE LSPs Initiation Request</span>
An LSP Initiation Request message is sent by a stateful PCE to create
a P2MP TE LSP. An example of a PCInitiate message for a P2MP TE LSP
is described below:
Common Header
SRP
LSP with P2MP flag set
END-POINTS for leaf type 1 (add)
ERO list
In this example, a stateful PCE requests the creation of a P2MP TE
LSP. The initiation request uses the END-POINT type 1 (new leaves).
The ERO list represents the source-to-leaves path. The initiate
message encodes the full P2MP tree in this case.
<span class="grey">Palle, et al. Standards Track [Page 18]</span><span id="page-19" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. PCEP Object Extensions</span>
The new PCEP TLVs defined in this document are in compliance with the
PCEP TLV format defined in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>].
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. LSP Object Extension</span>
The LSP Object is defined in <a href="./rfc8231#section-7.3">Section 7.3 of [RFC8231]</a>. It specifies
the PLSP-ID to uniquely identify an LSP that is constant for the life
time of a PCEP session. Similarly, for a P2MP tunnel, the PLSP-ID
uniquely identifies a P2MP TE LSP. This document adds the following
flags to the LSP Object:
N (P2MP flag - 1 bit): If the N flag is set to 1, it indicates that
the message is for a P2MP TE LSP.
F (Fragmentation flag - 1 bit): If the F flag is unset (0), it
indicates that the LSP is not fragmented or that it is the last
piece of the fragmented LSP. If the F flag is set to 1, it
indicates that the LSP is fragmented and that it is not the last
piece of the fragmented LSP. The receiver needs to wait for
additional fragments until it receives an LSP with the same PLSP-
ID and with the F-bit set to 0. See <a href="#section-8">Section 8</a> for further
details.
E (ERO-compression flag - 1 bit): If the E flag is set to 1, it
indicates the route is in compressed format (that is, Secondary
Explicit Route Object (SERO) and Secondary Record Route Object
(SRRO) objects [<a href="./rfc8306" title=""Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths"">RFC8306</a>] are in use).
The flags defined in this section (N, F, and E) are used in PCRpt,
PCUpd, or PCInitiate messages. In the case of PCReq and PCRep
messages, these flags have no meaning and thus MUST be ignored. The
corresponding flags in the RP (Request Parameters) object are used as
described in [<a href="./rfc8306" title=""Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths"">RFC8306</a>].
<span class="h4"><a class="selflink" id="section-7.1.1" href="#section-7.1.1">7.1.1</a>. P2MP-LSP-IDENTIFIERS TLV</span>
[<a id="ref-RFC8231">RFC8231</a>] specifies the LSP-IDENTIFIERS TLVs to be included in the
LSP object. For P2MP TE LSP, this document defines P2MP-LSP-
IDENTIFIERS TLVs for the LSP object. There are two P2MP-LSP-
IDENTIFIERS TLVs, one for IPv4 and one for IPv6. The P2MP-LSP-
IDENTIFIERS TLV MUST be included in the LSP object in a PCRpt message
for P2MP TE LSPs. If the N bit is set in the LSP object in the PCRpt
message but the P2MP-LSP-IDENTIFIER TLV is absent, the PCE MUST
respond with a PCErr message carrying error-type 6 ("mandatory object
missing") and error-value 14 ("P2MP-LSP-IDENTIFIERS TLV missing") and
close the PCEP session.
<span class="grey">Palle, et al. Standards Track [Page 19]</span><span id="page-20" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
The P2MP-LSP-IDENTIFIERS TLV MAY be included in the LSP object in the
PCUpd message for P2MP TE LSPs. The special value of all zeros for
all the fields in the value portion of the TLV is used to refer to
all paths pertaining to a particular PLSP-ID. The length of the TLV
remains fixed based on the IP version.
The P2MP-LSP-IDENTIFIERS TLV SHOULD NOT be used in a PCInitiate
message (see <a href="#section-5.6.3.1">Section 5.6.3.1</a>) and MAY optionally be included in the
LSP object in the PCReq and the PCRep message for P2MP TE LSP.
The format of the IPV4-P2MP-LSP-IDENTIFIERS TLV is shown in Figure 1:
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=32 | Length=16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPV4-P2MP-LSP-IDENTIFIERS TLV Format
The type (16 bits) of the TLV is 32. The length (16 bits) has a
fixed value of 16 octets. The value contains the following fields:
IPv4 Tunnel Sender Address: Contains the sender node's IPv4 address,
as defined in [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>]. See <a href="./rfc3209#section-4.6.2.1">Section 4.6.2.1 of [RFC3209]</a> for the
LSP_TUNNEL_IPv4 Sender Template Object.
LSP ID: Contains the 16-bit 'LSP ID' identifier defined in
[<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>]. See <a href="./rfc3209#section-4.6.2.1">Section 4.6.2.1 of [RFC3209]</a> for the
LSP_TUNNEL_IPv4 Sender Template Object.
Tunnel ID: Contains the 16-bit 'Tunnel ID' identifier defined in
[<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>]. See <a href="./rfc3209#section-4.6.1.1">Section 4.6.1.1 of [RFC3209]</a> for the
LSP_TUNNEL_IPv4 Session Object.
Extended Tunnel ID: Contains the 32-bit 'Extended Tunnel ID'
identifier defined in [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>]. See <a href="./rfc3209#section-4.6.1.1">Section 4.6.1.1 of [RFC3209]</a>
for the LSP_TUNNEL_IPv4 Session Object.
<span class="grey">Palle, et al. Standards Track [Page 20]</span><span id="page-21" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
P2MP ID: Contains the 32-bit 'P2MP ID' identifier defined in
<a href="./rfc4875#section-19.1.1">Section 19.1.1 of [RFC4875]</a> for the P2MP LSP Tunnel IPv4 SESSION
Object.
The format of the IPV6-P2MP-LSP-IDENTIFIERS TLV is shown in Figure 2:
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=33 | Length=40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel sender address |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Extended Tunnel ID |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IPV6-P2MP-LSP-IDENTIFIERS TLV Format
The type (16 bits) of the TLV is 33. The length (16 bits) has a
fixed length of 40 octets. The value contains the following fields:
IPv6 Tunnel Sender Address: Contains the sender node's IPv6 address,
as defined in [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>]. See <a href="./rfc3209#section-4.6.2.2">Section 4.6.2.2 of [RFC3209]</a> for the
LSP_TUNNEL_IPv6 Sender Template Object.
LSP ID: Contains the 16-bit 'LSP ID' identifier defined in
[<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>]. See <a href="./rfc3209#section-4.6.2.2">Section 4.6.2.2 of [RFC3209]</a> for the
LSP_TUNNEL_IPv6 Sender Template Object.
Tunnel ID: Contains the 16-bit 'Tunnel ID' identifier defined in
[<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>]. See <a href="./rfc3209#section-4.6.1.2">Section 4.6.1.2 of [RFC3209]</a> for the
LSP_TUNNEL_IPv6 Session Object.
<span class="grey">Palle, et al. Standards Track [Page 21]</span><span id="page-22" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
Extended Tunnel ID: Contains the 128-bit 'Extended Tunnel ID'
identifier defined in [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>]. See <a href="./rfc3209#section-4.6.1.2">Section 4.6.1.2 of [RFC3209]</a>
for the LSP_TUNNEL_IPv6 Session Object.
P2MP ID: Defined above under Figure 1.
Tunnel ID: Remains constant over the lifetime of a tunnel.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. S2LS Object</span>
The S2LS (Source-to-Leaves) Object is used to report the state of one
or more destinations (leaves) encoded within the END-POINTS object
for a P2MP TE LSP. It MUST be carried in a PCRpt message along with
an END-POINTS object when the N flag is set in an LSP object.
S2LS Object-Class is 41.
S2LS Object-Types is 1.
The format of the S2LS object 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | O|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: S2LS Object Format
Flags (32 bits): The following flag is currently defined:
O (Operational - 3 bits) The O field represents the operational
status of the group of destinations. The values are as per the
Operational field in the LSP object defined in <a href="./rfc8231#section-7.3">Section 7.3 of
[RFC8231]</a>.
Unassigned bits are reserved for future uses. They MUST be set to 0
on transmission and MUST be ignored on receipt.
When the N flag is set in an LSP object, the O field in the LSP
object represents the operational status of the full P2MP TE LSP, and
the O field in the S2LS object represents the operational status of a
group of destinations encoded within the END-POINTS object. If there
is a conflict between the O field in the LSP and the S2LS object (for
<span class="grey">Palle, et al. Standards Track [Page 22]</span><span id="page-23" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
example, the O field in the LSP corresponds to down whereas the O
field in the S2LS is up), the PCEP speaker MUST generate an error
with error-type 10 ("Reception of an invalid object") and error-value
22 ("Mismatch of O field in S2LS and LSP object").
Future documents might define optional TLVs that could be included in
the S2LS Object.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Message Fragmentation</span>
The total PCEP message length, including the common header, is
(2^16)-1 bytes. In certain scenarios, the P2MP report and update
request may not fit into a single PCEP message (e.g., initial report
or update). The F flag is used in the LSP object to signal that the
initial report, update, or initiate request was too large to fit into
a single PCEP message and will be fragmented into multiple messages.
In order to identify the single report or update, each message will
use the same PLSP-ID. In order to identify that a series of
PCInitiate messages represents a single Initiate, each message will
use the same PLSP-ID (in this case 0) and SRP-ID-number.
The fragmentation procedure described below for report or update
messages is similar to [<a href="./rfc8306" title=""Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths"">RFC8306</a>], which describes request and
response message fragmentation.
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Report Fragmentation Procedure</span>
If the initial report is too large to fit into a single report
message, the PCC will split the report over multiple messages. Each
message sent to the PCE, except the last one, will have the F flag
set in the LSP object to signify that the report has been fragmented
into multiple messages. In order to identify that a series of report
messages represents a single report, each message will use the same
PLSP-ID.
The Error-Type value 18 ("P2MP Fragmentation Error") is used to
report any error associated with the fragmentation of a P2MP PCEP
message. A new error-value 2 indicates "Fragmented report failure"
and is used if a PCE does not receive the last part of the fragmented
message.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Update Fragmentation Procedure</span>
Once the PCE computes and updates a path for some or all leaves in a
P2MP TE LSP, an update message is sent to the PCC. If the update is
too large to fit into a single update message, the PCE will split the
update over multiple messages. Each update message sent by the PCE,
except the last one, will have the F flag set in the LSP object to
<span class="grey">Palle, et al. Standards Track [Page 23]</span><span id="page-24" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
signify that the update has been fragmented into multiple messages.
In order to identify that a series of update messages represents a
single update, each message will use the same PLSP-ID and SRP-ID-
number.
The Error-Type value 18 ("P2MP Fragmentation Error") is used to
report any error associated with the fragmentation of a P2MP PCEP
message. A new error-value 3 indicates "Fragmented update failure"
and is used if a PCC does not receive the last part of the fragmented
message.
<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>. PCInitiate Fragmentation Procedure</span>
Once the PCE initiates to set up a P2MP TE LSP, a PCInitiate message
is sent to the PCC. If the initiate request is too large to fit into
a single PCInitiate message, the PCE will split the initiate request
over multiple messages. Each PCInitiate message sent by the PCE,
except the last one, will have the F flag set in the LSP object to
signify that the PCInitiate has been fragmented into multiple
messages. In order to identify that a series of PCInitiate messages
represents a single Initiate, each message will use the same PLSP-ID
(in this case 0) and SRP-ID-number.
The Error-Type value 18 ("P2MP Fragmentation Error") is used to
report any error associated with the fragmentation of a P2MP PCEP
message. A new error-value 4 indicates "Fragmented instantiation
failure" and is used if a PCC does not receive the last part of the
fragmented message.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Nonsupport of P2MP TE LSPs for Stateful PCE</span>
The PCEP extensions described in this document for stateful PCEs with
P2MP capability MUST NOT be used if the PCE has not advertised its
stateful capability with P2MP as per <a href="#section-5.2">Section 5.2</a>. If the PCC
supports the extensions as per this document (understands the N
(P2MP-CAPABILITY) and M (P2MP-LSP-UPDATE-CAPABILITY) flags in the LSP
object) but did not advertise this capability, then upon receipt of a
PCUpd message from the PCE, it SHOULD generate a PCErr with error-
type 19 ("Invalid Operation"), error-value 12 ("Attempted LSP Update
Request for P2MP if active stateful PCE capability for P2MP was not
advertised"), and terminate the PCEP session. If the PCE supports
the extensions as per this document (understands the N (P2MP-
CAPABILITY) flag in the LSP object) but did not advertise this
capability, then upon receipt of a PCRpt message from the PCC, it
SHOULD generate a PCErr with error-type 19 ("Invalid Operation"),
error-value 11 ("Attempted LSP State Report for P2MP if stateful PCE
capability for P2MP was not advertised"), and it SHOULD terminate the
PCEP session.
<span class="grey">Palle, et al. Standards Track [Page 24]</span><span id="page-25" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
If a Stateful PCE receives a P2MP TE LSP report message and the PCE
does not understand the N (P2MP-CAPABILITY) flag in the LSP object,
and therefore the PCEP extensions described in this document, then
the Stateful PCE would act as per <a href="./rfc8231#section-6.1">Section 6.1 of [RFC8231]</a> (and
consider the PCRpt message as invalid).
The PCEP extensions described in this document for PCC or PCE with
the PCE-Initiation capability for P2MP TE LSPs MUST NOT be used if
the PCC or PCE has not advertised its stateful capability with
Instantiation and P2MP capability as per <a href="#section-5.2">Section 5.2</a>. If the PCC
supports the extensions as per this document (understands the P
(P2MP-LSP-INSTANTIATION-CAPABILITY) flag) but did not advertise this
capability, then upon receipt of a PCInitiate message from the PCE,
it SHOULD generate a PCErr with error-type 19 ("Invalid Operation"),
error-value 13 ("Attempted LSP Instantiation Request for P2MP if
stateful PCE instantiation capability for P2MP was not advertised"),
and terminate the PCEP session.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Manageability Considerations</span>
All manageability requirements and considerations listed in
[<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>], [<a href="./rfc8306" title=""Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths"">RFC8306</a>], [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>], and [<a href="./rfc8281" title=""Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model"">RFC8281</a>] apply to PCEP
extensions defined in this document. In addition, requirements and
considerations listed in this section apply.
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Control of Function and Policy</span>
A PCE or PCC implementation MUST allow configuration of the stateful
PCEP capability, the LSP Update capability, and the LSP Initiation
capability for P2MP LSPs.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Information and Data Models</span>
The PCEP YANG module [<a href="#ref-PCE-PCEP-YANG">PCE-PCEP-YANG</a>] can be extended to include
advertised P2MP stateful capabilities, P2MP synchronization status,
and the delegation status of a P2MP LSP, etc. The statistics module
should also count data related to P2MP LSPs.
<span class="h3"><a class="selflink" id="section-10.3" href="#section-10.3">10.3</a>. Liveness Detection and Monitoring</span>
Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already
listed in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>].
<span class="grey">Palle, et al. Standards Track [Page 25]</span><span id="page-26" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
<span class="h3"><a class="selflink" id="section-10.4" href="#section-10.4">10.4</a>. Verify Correct Operations</span>
Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in
[<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>], [<a href="./rfc8306" title=""Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths"">RFC8306</a>], [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>], and [<a href="./rfc8281" title=""Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model"">RFC8281</a>].
<span class="h3"><a class="selflink" id="section-10.5" href="#section-10.5">10.5</a>. Requirements on Other Protocols</span>
Mechanisms defined in this document do not imply any new requirements
on other protocols.
<span class="h3"><a class="selflink" id="section-10.6" href="#section-10.6">10.6</a>. Impact on Network Operations</span>
Mechanisms defined in this document do not have any impact on network
operations in addition to those already listed in [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>],
[<a href="./rfc8306" title=""Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths"">RFC8306</a>], [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>], and [<a href="./rfc8281" title=""Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model"">RFC8281</a>].
Stateful PCE features for P2MP LSPs would help with network
operations.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. IANA Considerations</span>
IANA has registered the code points for the protocol elements defined
in this document.
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>. PCE Capabilities in IGP Advertisements</span>
IANA has registered the new bits in the OSPF Parameters "Path
Computation Element (PCE) Capability Flags" registry, as follows:
Bit Capability Description Reference
13 Active Stateful PCE with P2MP <a href="./rfc8623">RFC 8623</a>
14 Passive Stateful PCE with P2MP <a href="./rfc8623">RFC 8623</a>
15 Stateful PCE Initiation with P2MP <a href="./rfc8623">RFC 8623</a>
<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>. STATEFUL-PCE-CAPABILITY TLV</span>
The STATEFUL-PCE-CAPABILITY TLV is defined in [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>], and the
"STATEFUL-PCE-CAPABILITY TLV Flag Field" subregistry was created to
manage the flags in the TLV. IANA has registered the following code
points in the aforementioned registry.
Bit Description Reference
23 P2MP-LSP-INSTANTIATION-CAPABILITY <a href="./rfc8623">RFC 8623</a>
24 P2MP-LSP-UPDATE-CAPABILITY <a href="./rfc8623">RFC 8623</a>
25 P2MP-CAPABILITY <a href="./rfc8623">RFC 8623</a>
<span class="grey">Palle, et al. Standards Track [Page 26]</span><span id="page-27" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
<span class="h3"><a class="selflink" id="section-11.3" href="#section-11.3">11.3</a>. LSP Object</span>
The LSP object is defined in [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>], and the "LSP Object Flag
Field" subregistry was created to manage the Flags field of the LSP
object.
IANA has registered the following code points in the aforementioned
registry.
Bit Description Reference
1 ERO-compression <a href="./rfc8623">RFC 8623</a>
2 Fragmentation <a href="./rfc8623">RFC 8623</a>
3 P2MP <a href="./rfc8623">RFC 8623</a>
<span class="h3"><a class="selflink" id="section-11.4" href="#section-11.4">11.4</a>. PCEP-ERROR Object</span>
IANA has registered the new error values within the "PCEP-ERROR
Object Error Types and Values" subregistry of the PCEP Numbers
registry, as follows:
Error-Type Meaning
6 Mandatory Object missing [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]
Error-value = 13: S2LS object missing
Error-value = 14: P2MP-LSP-IDENTIFIERS TLV missing
10 Reception of an invalid object [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]
Error-value = 22: Mismatch of O field in S2LS
and LSP object
18 P2MP Fragmentation Error [<a href="./rfc8306" title=""Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths"">RFC8306</a>]
Error-value = 2: Fragmented Report failure
Error-value = 3: Fragmented Update failure
Error-value = 4: Fragmented Instantiation failure
19 Invalid Operation [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>]
Error-value = 11: Attempted LSP State Report
for P2MP if stateful PCE capability
for P2MP was not advertised
Error-value = 12: Attempted LSP Update Request
for P2MP if active stateful PCE capability
for P2MP was not advertised
Error-value = 13: Attempted LSP Instantiation
Request for P2MP if stateful PCE
instantiation capability for P2MP was not
advertised
The reference for all new Error-values above is <a href="./rfc8623">RFC 8623</a>.
<span class="grey">Palle, et al. Standards Track [Page 27]</span><span id="page-28" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
<span class="h3"><a class="selflink" id="section-11.5" href="#section-11.5">11.5</a>. PCEP TLV Type Indicators</span>
IANA has registered the following code points in the existing "PCEP
TLV Type Indicators" registry as follows:
Value Description Reference
32 P2MP-IPV4-LSP-IDENTIFIERS <a href="./rfc8623">RFC 8623</a>
33 P2MP-IPV6-LSP-IDENTIFIERS <a href="./rfc8623">RFC 8623</a>
<span class="h3"><a class="selflink" id="section-11.6" href="#section-11.6">11.6</a>. PCEP Object</span>
IANA has registered the new object-class values and object types
within the "PCEP Objects" subregistry of the PCEP Numbers registry,
as follows.
Object-Class Value Name Reference
41 S2LS <a href="./rfc8623">RFC 8623</a>
Object-Type
0: Reserved
1: S2LS
<span class="h3"><a class="selflink" id="section-11.7" href="#section-11.7">11.7</a>. S2LS Object</span>
A new subregistry, named "S2LS Object Flag Field", has been created
within the "Path Computation Element Protocol (PCEP) Numbers"
registry to manage the 32-bit flag field of the S2LS object. New
values are to be assigned by Standards Action [<a href="./rfc8126" title="">RFC8126</a>]. Each bit
should be tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit)
o Capability description
o Defining RFC
The following values are defined in this document:
Bit Description Reference
0-28 Unassigned
29-31 Operational (3 bits) <a href="./rfc8623">RFC 8623</a>
<span class="grey">Palle, et al. Standards Track [Page 28]</span><span id="page-29" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Security Considerations</span>
The stateful operations on P2MP TE LSPs are more CPU intensive and
also utilize more bandwidth on the wire (in comparison to P2P TE
LSPs). If a rogue PCC were able to request unauthorized stateful PCE
operations, then it may be able to mount a DoS attack against a PCE,
which would disrupt the network and deny service to other PCCs.
Similarly, an attacker may flood the PCC with PCUpd messages at a
rate that exceeds either the PCC's ability to process them or the
network's ability to signal the changes by either spoofing messages
or compromising the PCE itself.
Consequently, it is important that implementations conform to the
relevant security requirements as listed below:
o As per [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>], it is RECOMMENDED that these PCEP extensions
only be activated on authenticated and encrypted sessions across
PCEs and PCCs belonging to the same administrative authority,
using Transport Layer Security (TLS) [<a href="./rfc8253" title=""PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)"">RFC8253</a>] as per the
recommendations and best current practices in [<a href="./rfc7525" title=""Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"">RFC7525</a>] (unless
explicitly set aside in [<a href="./rfc8253" title=""PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)"">RFC8253</a>]).
o Security considerations for path computation requests and
responses are as per [<a href="./rfc8306" title=""Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths"">RFC8306</a>].
o Security considerations for stateful operations (such as state
report, synchronization, delegation, update, etc.) are as per
[<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>].
o Security considerations for the LSP instantiation mechanism are as
per [<a href="./rfc8231" title=""Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE"">RFC8231</a>].
o Security considerations as stated in Sections <a href="#section-10.1">10.1</a>, <a href="#section-10.6">10.6</a>, and <a href="#section-10.7">10.7</a>
of [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>] continue to apply.
<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>. References</span>
<span class="h3"><a class="selflink" id="section-13.1" href="#section-13.1">13.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC3209">RFC3209</a>] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", <a href="./rfc3209">RFC 3209</a>, DOI 10.17487/RFC3209, December 2001,
<<a href="https://www.rfc-editor.org/info/rfc3209">https://www.rfc-editor.org/info/rfc3209</a>>.
<span class="grey">Palle, et al. Standards Track [Page 29]</span><span id="page-30" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
[<a id="ref-RFC4875">RFC4875</a>] Aggarwal, R., Ed., Papadimitriou, D., Ed., and
S. Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", <a href="./rfc4875">RFC 4875</a>,
DOI 10.17487/RFC4875, May 2007,
<<a href="https://www.rfc-editor.org/info/rfc4875">https://www.rfc-editor.org/info/rfc4875</a>>.
[<a id="ref-RFC5088">RFC5088</a>] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and
R. Zhang, "OSPF Protocol Extensions for Path Computation
Element (PCE) Discovery", <a href="./rfc5088">RFC 5088</a>, DOI 10.17487/RFC5088,
January 2008, <<a href="https://www.rfc-editor.org/info/rfc5088">https://www.rfc-editor.org/info/rfc5088</a>>.
[<a id="ref-RFC5089">RFC5089</a>] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and
R. Zhang, "IS-IS Protocol Extensions for Path Computation
Element (PCE) Discovery", <a href="./rfc5089">RFC 5089</a>, DOI 10.17487/RFC5089,
January 2008, <<a href="https://www.rfc-editor.org/info/rfc5089">https://www.rfc-editor.org/info/rfc5089</a>>.
[<a id="ref-RFC5440">RFC5440</a>] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", <a href="./rfc5440">RFC 5440</a>,
DOI 10.17487/RFC5440, March 2009,
<<a href="https://www.rfc-editor.org/info/rfc5440">https://www.rfc-editor.org/info/rfc5440</a>>.
[<a id="ref-RFC5511">RFC5511</a>] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", <a href="./rfc5511">RFC 5511</a>, DOI 10.17487/RFC5511, April
2009, <<a href="https://www.rfc-editor.org/info/rfc5511">https://www.rfc-editor.org/info/rfc5511</a>>.
[<a id="ref-RFC7525">RFC7525</a>] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", <a href="https://www.rfc-editor.org/bcp/bcp195">BCP 195</a>, <a href="./rfc7525">RFC 7525</a>, DOI 10.17487/RFC7525, May
2015, <<a href="https://www.rfc-editor.org/info/rfc7525">https://www.rfc-editor.org/info/rfc7525</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
May 2017, <<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
[<a id="ref-RFC8231">RFC8231</a>] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", <a href="./rfc8231">RFC 8231</a>,
DOI 10.17487/RFC8231, September 2017,
<<a href="https://www.rfc-editor.org/info/rfc8231">https://www.rfc-editor.org/info/rfc8231</a>>.
[<a id="ref-RFC8232">RFC8232</a>] 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", <a href="./rfc8232">RFC 8232</a>,
DOI 10.17487/RFC8232, September 2017,
<<a href="https://www.rfc-editor.org/info/rfc8232">https://www.rfc-editor.org/info/rfc8232</a>>.
<span class="grey">Palle, et al. Standards Track [Page 30]</span><span id="page-31" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
[<a id="ref-RFC8253">RFC8253</a>] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)",
<a href="./rfc8253">RFC 8253</a>, DOI 10.17487/RFC8253, October 2017,
<<a href="https://www.rfc-editor.org/info/rfc8253">https://www.rfc-editor.org/info/rfc8253</a>>.
[<a id="ref-RFC8281">RFC8281</a>] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", <a href="./rfc8281">RFC 8281</a>, DOI 10.17487/RFC8281, December 2017,
<<a href="https://www.rfc-editor.org/info/rfc8281">https://www.rfc-editor.org/info/rfc8281</a>>.
[<a id="ref-RFC8306">RFC8306</a>] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King,
"Extensions to the Path Computation Element Communication
Protocol (PCEP) for Point-to-Multipoint Traffic
Engineering Label Switched Paths", <a href="./rfc8306">RFC 8306</a>,
DOI 10.17487/RFC8306, November 2017,
<<a href="https://www.rfc-editor.org/info/rfc8306">https://www.rfc-editor.org/info/rfc8306</a>>.
<span class="h3"><a class="selflink" id="section-13.2" href="#section-13.2">13.2</a>. Informative References</span>
[<a id="ref-PCE-PCEP-YANG">PCE-PCEP-YANG</a>]
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", Work in Progress,
<a href="./draft-ietf-pce-pcep-yang-11">draft-ietf-pce-pcep-yang-11</a>, March 2019.
[<a id="ref-RFC4655">RFC4655</a>] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", <a href="./rfc4655">RFC 4655</a>,
DOI 10.17487/RFC4655, August 2006,
<<a href="https://www.rfc-editor.org/info/rfc4655">https://www.rfc-editor.org/info/rfc4655</a>>.
[<a id="ref-RFC5671">RFC5671</a>] Yasukawa, S. and A. Farrel, Ed., "Applicability of the
Path Computation Element (PCE) to Point-to-Multipoint
(P2MP) MPLS and GMPLS Traffic Engineering (TE)", <a href="./rfc5671">RFC 5671</a>,
DOI 10.17487/RFC5671, October 2009,
<<a href="https://www.rfc-editor.org/info/rfc5671">https://www.rfc-editor.org/info/rfc5671</a>>.
[<a id="ref-RFC8051">RFC8051</a>] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", <a href="./rfc8051">RFC 8051</a>,
DOI 10.17487/RFC8051, January 2017,
<<a href="https://www.rfc-editor.org/info/rfc8051">https://www.rfc-editor.org/info/rfc8051</a>>.
[<a id="ref-RFC8126">RFC8126</a>] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>,
<a href="./rfc8126">RFC 8126</a>, DOI 10.17487/RFC8126, June 2017,
<<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>>.
<span class="grey">Palle, et al. Standards Track [Page 31]</span><span id="page-32" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
Acknowledgments
Thanks to Quintin Zhao, Avantika, and Venugopal Reddy for the review
comments.
Thanks to Adrian Farrel (and Jonathan Hardwick) for the review as
document shepherds.
Thanks to Andy Malis for the RTG-DIR review. Thanks to Donald
Eastlake for the SEC-DIR review. Thanks to David Schinazi for the
GEN-ART review.
Thanks to Suresh Krishnan, Mirja Kuhlewind, Roman Danyliw, and
Benjamin Kaduk for the IESG reviews.
Contributors
Yuji Kamite
NTT Communications Corporation
Granpark Tower
3-4-1 Shibaura, Minato-ku
Tokyo 108-8118
Japan
Email: [email protected]
<span class="grey">Palle, et al. Standards Track [Page 32]</span><span id="page-33" ></span>
<span class="grey"><a href="./rfc8623">RFC 8623</a> Stateful P2MP June 2019</span>
Authors' Addresses
Udayasree Palle
Huawei Technologies
Email: [email protected]
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
Email: [email protected]
Yosuke Tanaka
NTT Communications Corporation
Granpark Tower
3-4-1 Shibaura, Minato-ku
Tokyo 108-8118
Japan
Email: [email protected]
Vishnu Pavan Beeram
Juniper Networks
Email: [email protected]
Palle, et al. Standards Track [Page 33]
Annotations
Select text to annotate