| PCE Working Group | U. Palle |
| Internet-Draft | D. Dhody |
| Intended status: Standards Track | Huawei Technologies |
| Expires: August 24, 2019 | Y. Tanaka |
| NTT Communications | |
| V. Beeram | |
| Juniper Networks | |
| February 20, 2019 |
Path Computation Element (PCE) Protocol Extensions for Stateful PCE usage for Point-to-Multipoint Traffic Engineering Label Switched Paths
draft-ietf-pce-stateful-pce-p2mp-12
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 Path Computation Element Communication Protocol (PCEP) so as to enable the usage of a stateful PCE capability in supporting P2MP TE LSPs.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 24, 2019.
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.
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. The PCE has been identified as a suitable application for the computation of paths for P2MP TE LSPs ([RFC5671]).
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.
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.
Terminology used in this document is same as terminology used in [RFC8231], [RFC8281], and [RFC8306].
[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 for 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 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.
The objectives for the protocol extensions to support P2MP TE LSPs for stateful PCE are same as the objectives described in section 3.2 of [RFC8231].
[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.
New PCEP messages are defined in [RFC8231] to support stateful PCE for P2P TE LSPs. In this document these messages are extended to support P2MP TE LSPs.
A PCEP message is defined in [RFC8281] to support stateful PCE instantiation of P2P TE LSPs. In this document this message is extended to support P2MP TE LSPs.
The Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages are also extended to support passive stateful PCE for P2P TE LSP in [RFC8231]. In this document these messages are extended to support P2MP TE LSPs as well.
During 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:
A PCEP speaker should continue to advertise the basic P2MP capability via mechanisms as described in [RFC8306].
When PCC is a Label Switching Router (LSR), participating in the IGP (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 (early allocated by IANA) 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 with P2MP capabilities may be advertised during discovery, PCEP Speakers that wish to use stateful PCEP 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.
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.
LSP delegation operations (described in Section 5.7 of [RFC8231]) are applicable for P2MP TE LSPs as well.
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 Section 3.4 and Section 3.5 of [RFC8306] respectively.
The PCReq and PCRep message for P2MP TE LSPs are extended to support encoding of 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 PCReq message.
The extension for the Request and Response message for passive stateful operations on P2MP TE LSPs are described in Section 6.3 and Section 6.4. The extension for the Path Computation LSP State Report (PCRpt) message is described in Section 6.1.
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 are described in Section 6.2.
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 P2MP TE LSPs suggested instantiation and deletion operations are same as for P2P LSP as described in section 5.3 and 5.4 of [RFC8281].
The Instantiation operation of P2MP TE LSPs is same as defined in section 5.3 of [RFC8281] including handling of PLSP-ID, SYMBOLIC-PATH-NAME TLV etc. Rules of processing and error codes remains unchanged. The N (P2MP) flag (Section 7.1) MUST be set in LSP object in PCInitiate message by PCE to specify 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 PCIntiitate message (as it is generated by PCC and carried in PCRpt message instead) and MUST be ignored on receipt.
The deletion operation of P2MP TE LSPs is same as defined in section 5.4 of [RFC8281] by sending an LSP Initiate Message with an LSP object carrying the PLSP-ID of the LSP to be removed and an SRP object with the R flag set (LSP-REMOVE as per section 5.2 of [RFC8281]). Rules of processing and error codes remains unchanged.
Adding of new leaves and Pruning of old Leaves for the PCE initiated P2MP TE LSP MUST be carried in PCUpd message as per Section 6.2 for P2MP TE LSP extensions. As defined in [RFC8306], leaf type = 1 for adding of new leaves, leaf type = 2 for pruning of old leaves of P2MP END-POINTS Object are used in PCUpd message.
PCC MAY use the Incremental State Update mechanism as described in [RFC4875] to signal 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 message. The same error handling and error-codes are also applicable to the stateful PCE messages as described in this document.
P2MP TE LSPs delegation and cleanup operations are same as defined in section 6 of [RFC8281]. Rules of processing and error codes remains unchanged.
Message formats in this section, as those in [RFC8231], [RFC8281], and [RFC5440], are presented using Routing Backus-Naur Format (RBNF) as specified in [RFC5511].
As per Section 6.1 of [RFC8231], 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 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>
<end-point-intended-path-pair-list>
[<actual-attribute-list>
<end-point-actual-path-pair-list>]
[<intended-attribute-list>]
Where:
<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>]
<intended-attribute-list> is defined in [RFC5440] 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 [RFC5440].
The P2MP END-POINTS object defined in [RFC8306] is mandatory for specifying address of P2MP leaves grouped based on leaf types.
When reporting the status of a P2MP TE LSP, the destinations MUST be grouped in END-POINTS object based on the operational status (O field in S2LS object) and leaf type (in END-POINTS). This way, leaves of the same type that share the same operational status are grouped together. For reporting the status of delegated P2MP TE LSPs leaf-type = 3 is used, whereas for non-delegated P2MP TE LSPs, leaf-type = 4 is used.
For a delegated P2MP TE LSP configuration changes are reported via PCRpt message. For example, adding of new leaves END-POINTS (leaf-type = 1) is used where as removing of old leaves (leaf-type = 2) is used.
Note that the compatibility with the [RFC8231] 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 [RFC8231].
During state synchronization, the PCRpt message reports the status of the full P2MP tree.
The S2LS object MUST be carried in PCRpt message along with END-POINTS object when N (P2MP) flag is set in LSP object for P2MP TE LSPs. If the S2LS object is missing, the receiving PCE MUST send a PCErr message with Error-type=6 ("Mandatory Object missing") and Error-value=13 (early allocated by IANA) ("S2LS object missing"). If the 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 [RFC5440].
The S2LS object could be used in conjunction with the intended-path (ERO) as well as the actual-path (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 SEROs or RRO followed by a list of SRROs.
As per Section 6.2 of [RFC8231], 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>
<end-point-path-pair-list>
<attribute-list>
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 [RFC5440] and
extended by PCEP extensions.
Note that the compatibility with the [RFC8231] definition of <update-request> is preserved.
The PCC SHOULD use the make-before-break or sub-group-based procedures described in [RFC4875] based on a local policy decision.
The END-POINTS object MUST be carried in PCUpd message when N flag is set in 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 [RFC5440]).
As per Section 3.4 of [RFC8306], 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 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>]
<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>]
As per Section 3.5 of [RFC8306], 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 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>]
As defined in section 5.1 of [RFC8281], PCE sends a PCInitiate message to a PCC to recommend instantiation of a P2P TE LSP. This document extends the format of PCInitiate message for the creation of P2MP TE LSPs but the creation and deletion operations of P2MP TE LSPs are same to the P2P TE LSPs.
The format of 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 [RFC5440] and extended
by PCEP extensions.
The PCInitiate message with an LSP object with 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 [RFC8231].
The END-POINTS object MUST be carried in PCInitiate message when N flag is set in 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 [RFC5440]).
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.
The LSP State Report message is sent by a PCC to report or delegate the P2MP TE LSPs. An example of a PCRpt message for a delegated P2MP TE LSPs is described below to add new leaves to an existing P2MP TE LSP:
Common Header
LSP with P2MP flag set
END-POINTS for leaf type 1
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
S2LS (O=UP)
ERO list (empty)
An example of a PCRpt message for a delegated P2MP TE LSP is described below to report status of leaves in an existing P2MP TE LSP:
Common Header
SRP
LSP with P2MP flag set
END-POINTS for leaf type 3
S2LS (O=UP)
RRO list
END-POINTS for leaf type 3
S2LS (O=DOWN)
ERO list (empty)
In this example, the PCRpt message is in response to a PCUpd message (with corresponding SRP) object indicating some leaves that are up (with the actual path) and some are down.
An example of a PCRpt message for a non-delegated P2MP TE LSP is described below to report status of leaves:
Common Header
LSP with P2MP flag set
END-POINTS for leaf type 4
S2LS (O=ACTIVE)
RRO list
END-POINTS for leaf type 4
S2LS (O=DOWN)
ERO list (empty)
An LSP Initiation Request message is sent by an 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
ERO list
In this example, a stateful PCE request 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.
The new PCEP TLVs defined in this document are in compliance with the PCEP TLV format defined in [RFC5440].
The LSP Object is defined in Section 7.3 of [RFC8231]. 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 identify a P2MP TE LSP uniquely. This document adds the following flags to the LSP Object:
The flags defined in this section (N, F, E flags) are used in PCRpt, PCUpd, or PCInitiate message. In case of PCReq and PCRep message, these flags have no meaning and thus MUST be ignored. The corresponding flags in the RP (Request Parameters) object are used as described in [RFC8231].
If the N bit is set on a PCRpt 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 (early allocated by IANA) ("P2MP-LSP-IDENTIFIER TLV missing") and close the PCEP session.
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 this TLV is used to refer to all paths pertaining to a particular PLSP-ID.
There are two P2MP-LSP-IDENTIFIERS TLVs, one for IPv4 and one for IPv6.
The format of the IPV4-P2MP-LSP-IDENTIFIERS TLV is shown in the Figure 6:
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 6: IPV4-P2MP-LSP-IDENTIFIERS TLV format
The type (16-bits) of the TLV is 32 (early allocated by IANA). The length (16-bits) has a fixed value of 16 octets. The value contains the following fields:
The format of the IPV6-P2MP-LSP-IDENTIFIERS TLV is shown in the Figure 7:
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 7: IPV6-P2MP-LSP-IDENTIFIERS TLV format
The type (16-bits) of the TLV is 33 (early allocated by IANA). The length (16-bits) has a fixed length of 40 octets. The value contains the following fields:
Tunnel ID remains constant over the life time of a tunnel.
The S2LS (Source-to-Leaves) Object is used to report state of one or more destinations (leaves) encoded within the END-POINTS object for a P2MP TE LSP. It MUST be carried in PCRpt message along with END-POINTS object when N flag is set in LSP object.
S2LS Object-Class is 41 (Early allocated by IANA).
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 8: S2LS object format
Unassigned bits are reserved for future uses. They MUST be set to 0 on transmission and MUST be ignored on receipt.
When N flag is set in LSP object then the O field in LSP object represents the operational status of the full P2MP TE LSP and the O field in 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 example, O field in LSP corresponds to down whereas the O field in S2LS is up), the PCEP speaker MUST generate an error with error-type 10 ("Reception of an invalid object") and error-value TBD1 (to be allocated by IANA) ("Mis-match of O field in S2LS and LSP object").
Future documents might define optional TLVs that could be included in the S2LS Object.
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 message was too large to fit into a single 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 message is similar to [RFC8306] which describes request and response message fragmentation.
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 (early allocated by IANA) indicates "Fragmented report failure" and is used if a PCE does not receive the last part of the fragmented message.
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 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 (early allocated by IANA) indicates "Fragmented update failure" and is used if a PCC does not receive the last part of the fragmented message.
Once the PCE initiates to set up a P2MP TE LSP, a PCInitiate message is sent to the PCC. If the PCInitiate is too large to fit into a single PCInitiate message, the PCE will split the PCInitiate 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 (early allocated by IANA) indicates "Fragmented instantiation failure" and is used if a PCC does not receive the last part of the fragmented message.
The PCEP extensions described in this document for stateful PCEs with P2MP capability MUST NOT be used if PCE has not advertised its stateful capability with P2MP as per Section 5.2. If the PCEP Speaker on the PCC supports the extensions of this draft (understands the P2MP flag in the LSP object) but did not advertise this capability, then upon receipt of PCUpd message from the PCE, it SHOULD generate a PCErr with error-type 19 ("Invalid Operation"), error-value 12 (early allocated by IANA) ("Attempted LSP Update Request for P2MP if active stateful PCE capability for P2MP was not advertised") and terminate the PCEP session. If the PCEP Speaker on the PCE supports the extensions of this draft (understands the P2MP 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 (early allocated by IANA) ("Attempted LSP State Report for P2MP if stateful PCE capability for P2MP was not advertised") and it SHOULD terminate the PCEP session.
If a Stateful PCE receives a P2MP TE LSP report message and the PCE does not understand the P2MP flag in the LSP object, and therefore the PCEP extensions described in this document, then the Stateful PCE would act as per [RFC8231].
The PCEP extensions described in this document for PCC or PCE with instantiation capability for P2MP TE LSPs MUST NOT be used if PCC or PCE has not advertised its stateful capability with Instantiation and P2MP capability as per Section 5.2. If the PCEP Speaker on the PCC supports the extensions of this draft (understands the P (P2MP-LSP-INSTANTIATION-CAPABILITY) flag) but did not advertise this capability, then upon receipt of PCInitiate message from the PCE, it SHOULD generate a PCErr with error-type 19 ("Invalid Operation"), error-value 13 (early allocated by IANA) ("Attempted LSP Instantiation Request for P2MP if stateful PCE instantiation capability for P2MP was not advertised") and terminate the PCEP session..
All manageability requirements and considerations listed in [RFC5440], [RFC8306], [RFC8231], and [RFC8281] apply to PCEP extensions defined in this document. In addition, requirements and considerations listed in this section apply.
A PCE or PCC implementation MUST allow configuring the stateful PCEP capability, the LSP Update capability, and the LSP Initiation capability for P2MP LSPs.
The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to include advertised P2MP stateful capabilities, P2MP synchronization status, and delegation status of P2MP LSP etc. The statistics module should also count P2MP LSP related data.
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440].
Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440], [RFC8306], [RFC8231], and [RFC8281].
Mechanisms defined in this document do not imply any new requirements on other protocols.
Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440], [RFC8306], [RFC8231], and [RFC8281].
Stateful PCE feature for P2MP LSP would help with network operations.
This document requests IANA to confirm the early allocation of the code-points for the protocol elements defined in this document.
Bit Meaning Reference
13 Active Stateful [This.I-D]
PCE with P2MP
14 Passive Stateful [This.I-D]
PCE with P2MP
15 Stateful PCE [This.I-D]
Initiation with P2MP
IANA is requested to confirm the early allocation for the new bits in the OSPF Parameters "PCE Capability Flags" registry, as follows:
The STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231] and the 'STATEFUL-PCE-CAPABILITY TLV Flag Field' subregistry was created to manage the flags in the TLV. IANA is requested to confirm the early allocation of the following code-points in the aforementioned registry.
Bit Description Reference
25 P2MP-CAPABILITY [This.I-D]
24 P2MP-LSP-UPDATE- [This.I-D]
CAPABILITY
23 P2MP-LSP- [This.I-D]
INSTANTIATION-
CAPABILITY
The LSP object is defined in [RFC8231] and the 'LSP Object Flag Field' subregistry was created to manage the Flags field of the LSP object.
IANA is requested to confirm the early allocation of the following code-points in the aforementioned registry.
Bit Description Reference
3 P2MP [This.I-D]
2 Fragmentation [This.I-D]
Additionally, IANA is requested to allocate an additional code-point in this registry.
Bit Description Reference
TBD ERO-compression [This.I-D]
IANA is requested to confirm the early allocation of the new error values within the "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP Numbers registry, as follows:
Error-Type Meaning
6 Mandatory Object missing [RFC5440]
Error-value=13: S2LS object missing
Error-value=14: P2MP-LSP-IDENTIFIERS TLV missing
18 P2MP Fragmentation Error [RFC8306]
Error-value= 2. Fragmented Report
failure
Error-value= 3. Fragmented Update
failure
Error-value= 4. Fragmented Instantiation
failure
19 Invalid Operation [RFC8231]
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
Reference for all new Error-Value above is [This.I-D].
Additionally, IANA is requested to allocate an additional code-point in this registry.
Error-Type Meaning
10 Reception of an invalid object [RFC5440]
Error-value=TBD1: Mis-match of O field in S2LS
and LSP object
Reference for all new Error-Value above is [This.I-D].
IANA is requested to confirm the early allocation of the following code-points in the existing "PCEP TLV Type Indicators" registry as follows:
Value Meaning Reference
32 P2MP-IPV4-LSP-IDENTIFIERS [This.I-D]
33 P2MP-IPV6-LSP-IDENTIFIERS [This.I-D]
IANA is requested to confirm the early allocation for the new object-class values and object types within the "PCEP Objects" sub-registry of the PCEP Numbers registry, as follows.
Object-Class Value Name Reference
41 S2LS [This.I-D]
Object-Type
0: Reserved
1: S2LS
This document requests that a new sub-registry, named "S2LS Object Flag Field", is created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the 32-bits Flag field of the S2LS object. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities:
The following values are defined in this document:
Bit Description Reference
29-31 Operational (3-bits) [This.I-D]
0-28 Unassigned
The stateful operations on P2MP TE LSPs are more CPU-intensive and also utilize more bandwidth on 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. Consequently, it is important that implementations conform to the relevant security requirements of [RFC5440], [RFC8306] and [RFC8231], and [RFC8281]. Securing the PCEP session using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in [RFC7525], is RECOMMENDED.
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 RTGDIR review.
Yuji Kamite
NTT Communications Corporation
Granpark Tower
3-4-1 Shibaura, Minato-ku
Tokyo 108-8118
Japan
EMail: y.kamite@ntt.com