Path Computation Element (PCE) Protocol Extensions for Stateful PCE usage for Point-to-Multipoint Traffic Engineering Label Switched Paths

As per , 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. 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 (). The PCEP is designed as a communication protocol between PCCs and PCEs for point-to-point (P2P) path computations and is defined in . The extensions of PCEP to request path computation for P2MP TE LSPs are described in . Stateful PCEs are shown to be helpful in many application scenarios, in both MPLS and GMPLS networks, as illustrated in . These scenarios apply equally to P2P and P2MP TE LSPs. provides the fundamental extensions needed for stateful PCE to support general functionality for P2P TE LSP. provides the an extensions needed for stateful PCE-initiated P2P TE LSP. Complementarily, this document focuses on the 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", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Terminology used in this document is same as terminology used in , , and .

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. defines the extensions to PCEP for P2P TE LSPs. Complementarily, this document focuses on the 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 PLSP-ID (). For P2MP this is an added advantage, where the size of message is much larger. Incase of stateless PCE, a modification of P2MP tree requires encoding of all leaves along with the paths in PCReq message, but using a stateful PCE with P2MP capability, the PCEP message can be used to convey only the modifications (the other information can be retrieved from the P2MP LSP identifier in the LSP database (LSPDB)). In environments where the P2MP TE LSP 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 further describes the motivation behind the PCE-Initiation capability, which are equally applicable for P2MP TE LSPs.

The objectives for the protocol extensions to support P2MP TE LSP for stateful PCE are same as the objectives described in section 3.2 of .

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. both the PCC and the PCE must announce during PCEP session establishment that they support PCEP Stateful PCE extensions for P2MP using mechanisms defined in . 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. a stateful PCE with P2MP capability requests modification of attributes on a PCC's P2MP TE LSP. a PCC sends an LSP state report to a PCE whenever the state of a P2MP TE LSP changes. a PCC grants to a PCE the right to update LSP attributes on one or more P2MP TE LSPs; the PCE becomes the authoritative source of the LSP's attributes as long as the delegation is in effect (See Section 5.7 of ); the PCC may withdraw the delegation or the PCE may give up the delegation at any time. a PCE sends an LSP Initiate Message to a PCC to instantiate or delete a P2MP TE LSP.

New PCEP messages are defined in to support stateful PCE for P2P TE LSPs. In this document these messages are extended to support P2MP TE LSPs. Each P2MP TE LSP State Report in a PCRpt message can contain actual P2MP TE LSP path attributes, LSP status, etc. An LSP State Report carried on 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 message is described in . 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 on a PCUpd message is also used to return LSP delegations if at any point PCE no longer desires control of a P2MP TE LSP. The PCUpd message is described in . A new PCEP message is defined in to support stateful PCE instantiation of P2P TE LSPs. In this document this message is extended to support P2MP TE LSPs. is a PCEP message sent by a PCE to a PCC to trigger P2MP TE LSP instantiation or deletion. The PCInitiate message is described in .

During PCEP Initialization Phase, as per Section 7.1.1 of , PCEP speakers advertises Stateful capability via Stateful PCE Capability TLV in open message. Two new flags are defined for the STATEFUL-PCE-CAPABILITY TLV defined in and updated in and . Three new bits N (P2MP-CAPABILITY), M (P2MP-LSP-UPDATE-CAPABILITY), and P (P2MP-LSP-INSTANTIATION-CAPABILITY) are added in this document: if set to 1 by a PCC, the N Flag indicates that the PCC is willing to send P2MP LSP State Reports whenever P2MP LSP parameters or operational status changes.; if set to 1 by a PCE, the N Flag indicates that the PCE is interested in receiving LSP State Reports whenever LSP parameters or operational status changes. The P2MP-CAPABILITY Flag must be advertised by both a PCC and a PCE for PCRpt messages P2MP extension to be allowed on a PCEP session. 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 PCUpd messages P2MP extension to be allowed on a PCEP session. If set to 1 by a PCC, the P Flag indicates that the PCC allows instantiation of an 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 .

When PCCs are LSRs 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 and respectively. The PCE-CAP-FLAGS sub-TLV, defined in , is an optional sub- TLV used to advertise PCE capabilities. It MAY be present within the PCED sub-TLV carried by OSPF or IS-IS. and 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 bits are defined in [RFC5088]. This document defines new capability bits for the stateful PCE with P2MP as follows:

Bit Capability TBD Active Stateful PCE with P2MP TBD Passive Stateful PCE with P2MP TBD 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 are applicable for P2MP TE LSPs as well.

LSP delegation operations described in Section 5.7 of are applicable for P2MP TE LSPs as well.

LSP operations for passive stateful PCE described in Section 5.8.1 of are applicable for P2MP TE LSPs as well. The Path Computation Request and Response message format for P2MP TE LSPs is described in Section 3.4 and Section 3.5 of respectively. The Request and Response message for P2MP TE LSPs are extended to support encoding of LSP object, so that it is possible to refer to a LSP with a unique identifier and simplify the PCEP message exchange. For example, incase 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 and . The extension for the Path Computation LSP State Report (PCRpt) message is described in .

LSP operations for active stateful PCE described in Section 5.8.2 of 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 .

As per section 5.1 of , 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 LSP (see details in ). P2MP TE LSP suggested instantiation and deletion operations are same as P2P LSP as described in section 5.3 and 5.4 of .

The Instantiation operation of P2MP TE LSP is same as defined in section 5.3 of including handling of PLSP-ID, SYMBOLIC-PATH-NAME TLV etc. Rules of processing and error codes remains unchanged. The N bit MUST be set in LSP object in PCInitiate message by PCE to specify the instantiation is for P2MP TE LSP. Though N bit is set in the LSP object, P2MP-LSP-IDENTIFIER TLV MUST NOT be included in the LSP object in PCIntiitate message as it SHOULD be generated by PCC and carried in PCRpt message.

The deletion operation of P2MP TE LSP is same as defined in section 5.4 of 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 ). 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 and SHOULD refer for P2MP TE LSP extensions. As defined in , 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 mechanims as described in to signal adding and pruning of leaves.

P2MP TE LSP delegation and cleanup operations are same as defined in section 6 of . Rules of processing and error codes remains unchanged.

As per Section 6.1 of , 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 LSP. 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-path-pair-list> <attribute-list> Where: <end-point-path-pair-list>::= [<END-POINTS>] [<S2LS>] <intended_path> [<actual_path>] [<end-point-path-pair-list>] <intended_path> ::= (<ERO>|<SERO>) [<intended_path>] <actual_path> ::= (<RRO>|<SRRO>) [<actual_path>] <attribute-list> is defined in [RFC5440] and extended by PCEP extensions. The P2MP END-POINTS object defined in is mandatory for specifying address of P2MP leaves grouped based on leaf types. New leaves to add (leaf type = 1) Old leaves to remove (leaf type = 2) Old leaves whose path can be modified/reoptimized (leaf type = 3) Old leaves whose path must be left unchanged (leaf type = 4) When reporting the status of a P2MP TE LSP, the destinations are grouped in END-POINTS object based on the operational status (O field in S2LS object) and leaf type (in END-POINTS). This way the leaves that share the same operational status are grouped together. For reporting the status of delegated P2MP TE LSP, leaf-type = 3, where as for non-delegated P2MP TE LSP, leaf-type = 4 is used. For 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 we preserve compatibility with the definition of <state-report>. At least one instance of <END-POINTS> MUST be present in this message for P2MP LSP. During state synchronization, the PCRpt message must report the status of the full P2MP TE LSP. The S2LS object MUST be carried in PCRpt message along with END-POINTS object when N bit is set in LSP object for P2MP TE LSP. If the S2LS object is missing, the receiving PCE MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=TBD (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 .

As per Section 6.2 of , PCUpd message is used to update P2P TE LSP attributes. This document extends the PCUpd message in updating the attributes of 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>] <path> [<end-point-path-pair-list>] <path> ::= (<ERO>|<SERO>) [<path>] <attribute-list> is defined in [RFC5440] and extended by PCEP extensions. Note that we preserve compatibility with the definition of <update-request>. The PCC MAY use the make-before-break or sub-group-based procedures described in based on a local policy decision. The END-POINTS object MUST be carried in PCUpd message when N bit is set in LSP object for 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 .

As per Section 3.4 of , 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> <request> where: <request>::= <RP> <end-point-rro-pair-list> [<LSP>] [<OF>] [<LSPA>] [<BANDWIDTH>] [<metric-list>] [<IRO>] [<LOAD-BALANCING>] where: <end-point-rro-pair-list>::=<END-POINTS>[<RRO-List>][<BANDWIDTH>] [<end-point-rro-pair-list>] <RRO-List>::=(<RRO>|<SRRO>)[<BANDWIDTH>][<RRO-List>] <metric-list>::=<METRIC>[<metric-list>]

As per Section 3.5 of , 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> <response>::=<RP> [<end-point-path-pair-list>] [<NO-PATH>] [<attribute-list>] where: <end-point-path-pair-list>::= [<END-POINTS>]<path>[<end-point-path-pair-list>] <path> ::= (<ERO>|<SERO>) [<path>] <attribute-list>::=[<LSP>] [<OF>] [<LSPA>] [<BANDWIDTH>] [<metric-list>] [<IRO>]

As defined in section 5.1 of , 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 LSP are same to the P2P TE LSP. 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>] <path> [<end-point-path-pair-list>] <path> ::= (<ERO>|<SERO>) [<path>] <attribute-list> is defined in [RFC5440] and extended by PCEP extensions. The PCInitiate message with an LSP object with N bit (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 . The END-POINTS object MUST be carried in PCInitiate message when N bit is set in LSP object for 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 .

LSP Update Request message is sent by an active stateful PCE to update the P2MP TE LSP parameters or attributes. An example of a PCUpd message for P2MP TE LSP 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 request updation of path taken by some of the leaves in a P2MP tree. The update request uses the END-POINT type 3 (modified/reoptimized). The ERO list represents the S2LS path after modification. The update message does not need to encode the full P2MP tree in this case.

LSP State Report message is sent by a PCC to report or delegate the P2MP TE LSP. An example of a PCRpt message for a delegated P2MP TE LSP 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 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 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 LSP with P2MP flag set END-POINTS for leaf type 3 S2LS (O=UP) ERO list END-POINTS for leaf type 3 S2LS (O=DOWN) ERO list 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) ERO list END-POINTS for leaf type 4 S2LS (O=DOWN) ERO list

The PCEP TLV defined in this document is compliant with the PCEP TLV format defined in .

LSP Object is defined in Section 7.3 of . It specifies PLSP-ID to uniquely identify an LSP that is constant for the life time of a PCEP session. Similarly for P2MP tunnel, PLSP-ID identify a P2MP TE LSP uniquely. This document adds the following flags to the LSP Object: If the bit is set to 1, it specifies the message is for P2MP TE LSP which MUST be set in PCRpt or PCUpd message for a P2MP TE LSP. If the bit is set to 1, it specifies the message is fragmented. If P2MP bit is set, the following P2MP-LSP-IDENTIFIER TLV MUST be present in LSP object.

The P2MP LSP Identifier TLV MUST be included in the LSP object in PCRpt message for RSVP-TE signaled P2MP TE LSPs. If the TLV is missing, the PCE will generate an error with error-type 6 (mandatory object missing) and error-value TBD (P2MP-LSP-IDENTIFIERS TLV missing) and close the PCEP session. The P2MP LSP Identifier TLV MAY be included in the LSP object in PCUpd message for RSVP-TE signaled 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 Identifier TLVs, one for IPv4 and one for IPv6. The format of the IPV4-P2MP-LSP-IDENTIFIER TLV is shown in the following figure:

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=[TBD] | Length=16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Tunnel Sender Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP ID | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2MP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The type (16-bit) of the TLV is [TBD] to be assigned by IANA. The length (16-bit) has a fixed value of 16 octets. The value contains the following fields: contains the sender node's IPv4 address, as defined in , Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template Object. contains the 16-bit 'LSP ID' identifier defined in , Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template Object. contains the 16-bit 'Tunnel ID' identifier defined in , Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. contains the 32-bit 'Extended Tunnel ID' identifier defined in , Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. contains the 32-bit 'P2MP ID' identifier defined in Section 19.1.1 of for the P2MP LSP Tunnel IPv4 SESSION Object. The format of the IPV6-P2MP-LSP-IDENTIFIER TLV is shown in the following figure:

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=[TBD] | Length=40 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | IPv6 tunnel sender address | + (16 octets) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP ID | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Extended Tunnel ID | + (16 octets) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2MP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The type of the TLV is [TBD] to be assigned by IANA. The length (16-bit) has a fixed length of 40 octets. The value contains the following fields: contains the sender node's IPv6 address, as defined in , Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template Object. contains the 16-bit 'LSP ID' identifier defined in , Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template Object. contains the 16-bit 'Tunnel ID' identifier defined in , Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. contains the 128-bit 'Extended Tunnel ID' identifier defined in , Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. As defined above in IPV4-P2MP-LSP-IDENTIFIERS TLV. Tunnel ID remains constant over the life time of a tunnel.

The S2LS (Source-to-Leaves) Object is used to report RSVP-TE 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 bit is set in LSP object. S2LS Object-Class is [TBD]. 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 // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the O Field represents the operational status of the group of destinations. The values are as per Operational field in LSP object defined in Section 7.3 of . When N bit 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. Future documents MAY define optional TLVs that MAY be included in the S2LS Object.

The total PCEP message length, including the common header, is 16 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-bit 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. Fragmentation procedure described below for report or update message is similar to 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-bit 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. To indicate P2MP message fragmentation errors associated with a P2MP Report, a Error-Type (18) and a new error-value TBD is used if a PCE has not received the last piece of the fragmented message, it should send an error message to the PCC to signal that it has received an incomplete message (i.e., "Fragmented Report failure").

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-bit 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. To indicate P2MP message fragmentation errors associated with a P2MP Update request, a Error-Type (18) and a new error-value TBD is used if a PCC has not received the last piece of the fragmented message, it should send an error message to the PCE to signal that it has received an incomplete message (i.e., "Fragmented Update failure").

Once the PCE initiates to set up the 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-bit 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. To indicate P2MP message fragmentation errors associated with a P2MP PCInitiate, a Error-Type (18) and a new error-value TBD is used if a PCC has not received the last piece of the fragmented message, it should send an error message to the PCE to signal that it has received an incomplete message (i.e., "Fragmented Instantiation failure").

The PCEP protocol 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 . 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 TBD (Attempted LSP Update Request for P2MP if active stateful PCE capability for P2MP was not advertised). 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 TBD (Attempted LSP State Report for P2MP if stateful PCE capability for P2MP was not advertised) and it will 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 . The PCEP protocol 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 . If the PCEP Speaker on the PCC supports the extensions of this draft (understands the P (P2MP-LSP-INSTANTIATION-CAPABILITY) flag in the LSP object) 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 TBD (Attempted LSP Instantiation Request for P2MP if stateful PCE instantiation capability for P2MP was not advertised).

All manageability requirements and considerations listed in , , , and apply to PCEP protocol 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 MIB module SHOULD be extended to include advertised P2MP stateful capabilities, P2MP synchronization status, and P2MP delegation status etc.

Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in .

Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in , , , and .

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 , , , and .

This document requests IANA actions to allocate code points for the protocol elements defined in this document.

IANA is requested to allocate new bits in "PCE Capability Flags" registry for stateful PCE with P2MP capability as follows:

Bit Meaning Reference TBD Active Stateful [This I-D] PCE with P2MP TBD Passive Stateful [This I-D] PCE with P2MP TBD Stateful PCE [This I-D] Initiation with P2MP

The following values are defined in this document for the Flags field in the STATEFUL-PCE-CAPABILITY-TLV (defined in ) in the OPEN object:

This document requests that a registry is created to manage the Flags field of the LSP object (defined in ). New values are to be assigned by Standards Action . Each bit should be tracked with the following qualities: Bit number (counting from bit 0 as the most significant bit) Capability description Defining RFC The following values are defined in this document:

A new 19 (recommended values) defined in section 8.5 of . The error-type 6 is defined in and error-type 18 in . This document extend the new Error-Values for those error types for the following error conditions:

Upon approval of this document, IANA is requested to make the assignment of a new error value for the existing "PCEP-ERROR Object Error Types and Values" registry located at http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object.

Upon approval of this document, IANA is requested to make the assignment of a new value for the existing "PCEP TLV Type Indicators" registry located at http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-indicators. This document defines the following new PCEP TLVs:

The stateful operations on P2MP TE LSP are more CPU-intensive and also utilize more link bandwidth. In the event of an unauthorized stateful P2MP operations, or a denial of service attack, the subsequent PCEP operations may be disruptive to the network. Consequently, it is important that implementations conform to the relevant security requirements of , and , and . Further discusses an experimental approach to provide secure transport for PCEP.

Thanks to Quintin Zhao, Avantika and Venugopal Reddy for his comments.