rfc8623v2.txt   rfc8623.txt 
skipping to change at page 6, line 6 skipping to change at page 6, line 6
delegation is in effect (See Section 5.7 of [RFC8231]); the PCC delegation is in effect (See Section 5.7 of [RFC8231]); the PCC
may withdraw the delegation or the PCE may give up the delegation may withdraw the delegation or the PCE may give up the delegation
at any time. at any time.
PCE-initiated LSP instantiation (E-C): A PCE sends an LSP Initiate PCE-initiated LSP instantiation (E-C): A PCE sends an LSP Initiate
Message to a PCC to instantiate or delete a P2MP TE LSP [RFC8281]. Message to a PCC to instantiate or delete a P2MP TE LSP [RFC8281].
5. Architectural Overview of Protocol Extensions 5. Architectural Overview of Protocol Extensions
5.1. Extension of PCEP Messages 5.1. Extension of PCEP Messages
New PCEP messages are defined in [RFC8231] to support stateful PCE Two new PCEP messages are defined in [RFC8231] to support stateful
for P2P TE LSPs. In this document, these messages are extended to PCE for P2P TE LSPs. In this document, these messages are extended
support P2MP TE LSPs. as follows to support P2MP TE LSPs.
Path Computation State Report (PCRpt): Each P2MP TE LSP State Report Path Computation State Report (PCRpt): Each P2MP TE LSP State Report
in a PCRpt message contains the actual P2MP TE LSP path in a PCRpt message contains the actual P2MP TE LSP path
attributes, the LSP status, etc. An LSP State Report carried in a attributes, the LSP status, etc. An LSP State Report carried in a
PCRpt message is also used in delegation or revocation of control 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 of a P2MP TE LSP to/from a PCE. The extension of PCRpt messages
is described in Section 6.1. is described in Section 6.1.
Path Computation Update Request (PCUpd): Each P2MP TE LSP Update Path Computation Update Request (PCUpd): Each P2MP TE LSP Update
Request in a PCUpd message MUST contain all LSP parameters that a 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 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 carried in a PCUpd message is also used to return LSP delegations
if at any point PCE no longer desires control of a P2MP TE LSP. if at any point the PCE no longer desires control of a P2MP TE
The PCUpd message is described in Section 6.2. LSP. The PCUpd message is described in Section 6.2.
A PCEP message is defined in [RFC8281] to support stateful PCE Further, a new PCEP message is defined in [RFC8281] to support
instantiation of P2P TE LSPs. In this document, this message is stateful PCE instantiation of P2P TE LSPs. In this document, this
extended to support P2MP TE LSPs. message is extended as follows to support P2MP TE LSPs.
Path Computation LSP Initiate Message (PCInitiate): PCInitiate is a Path Computation LSP Initiate Message (PCInitiate): PCInitiate is a
PCEP message sent by a PCE to a PCC to trigger P2MP TE LSPs PCEP message sent by a PCE to a PCC to trigger the instantiation
instantiation or deletion. The PCInitiate message is described in or deletion of a P2MP TE LSP. The PCInitiate message is described
Section 6.5. in Section 6.5.
The Path Computation Request (PCReq) and Path Computation Reply The Path Computation Request (PCReq) and Path Computation Reply
(PCRep) messages are also extended to support passive stateful PCE (PCRep) messages are also extended to support passive stateful PCE
for P2P TE LSP in [RFC8231]. In this document, these messages are for P2P TE LSPs in [RFC8231]. In this document, these messages are
extended to support P2MP TE LSPs as well. extended to support P2MP TE LSPs as well.
5.2. Capability Advertisement 5.2. Capability Advertisement
During the PCEP initialization phase, as per Section 7.1.1 of During the PCEP initialization phase, as per Section 7.1.1 of
[RFC8231], PCEP speakers advertise Stateful capability via the [RFC8231], PCEP speakers advertise Stateful capability via the
STATEFUL-PCE-CAPABILITY TLV in the OPEN object. Various flags are STATEFUL-PCE-CAPABILITY TLV in the OPEN object. Various flags are
defined for the STATEFUL-PCE-CAPABILITY TLV defined in [RFC8231] and defined for the STATEFUL-PCE-CAPABILITY TLV defined in [RFC8231] and
updated in [RFC8281] and [RFC8232]. updated in [RFC8281] and [RFC8232].
skipping to change at page 23, line 27 skipping to change at page 23, line 27
Future documents might define optional TLVs that could be included in Future documents might define optional TLVs that could be included in
the S2LS Object. the S2LS Object.
8. Message Fragmentation 8. Message Fragmentation
The total PCEP message length, including the common header, is The total PCEP message length, including the common header, is
(2^16)-1 bytes. In certain scenarios, the P2MP report and update (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 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 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 initial report, update, or initiate request was too large to fit into
a single message and will be fragmented into multiple messages. In a single PCEP message and will be fragmented into multiple messages.
order to identify the single report or update, each message will use In order to identify the single report or update, each message will
the same PLSP-ID. In order to identify that a series of PCInitiate use the same PLSP-ID. In order to identify that a series of
messages represents a single Initiate, each message will use the same PCInitiate messages represents a single Initiate, each message will
PLSP-ID (in this case 0) and SRP-ID-number. use the same PLSP-ID (in this case 0) and SRP-ID-number.
The fragmentation procedure described below for report or update The fragmentation procedure described below for report or update
messages is similar to [RFC8306], which describes request and messages is similar to [RFC8306], which describes request and
response message fragmentation. response message fragmentation.
8.1. Report Fragmentation Procedure 8.1. Report Fragmentation Procedure
If the initial report is too large to fit into a single report 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, the PCC will split the report over multiple messages. Each
message sent to the PCE, except the last one, will have the F flag message sent to the PCE, except the last one, will have the F flag
skipping to change at page 24, line 26 skipping to change at page 24, line 26
The Error-Type value 18 ("P2MP Fragmentation Error") is used to The Error-Type value 18 ("P2MP Fragmentation Error") is used to
report any error associated with the fragmentation of a P2MP PCEP report any error associated with the fragmentation of a P2MP PCEP
message. A new error-value 3 indicates "Fragmented update failure" 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 and is used if a PCC does not receive the last part of the fragmented
message. message.
8.3. PCInitiate Fragmentation Procedure 8.3. PCInitiate Fragmentation Procedure
Once the PCE initiates to set up a P2MP TE LSP, a PCInitiate 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 is sent to the PCC. If the initiate request is too large to fit into
single PCInitiate message, the PCE will split the PCInitiate over a single PCInitiate message, the PCE will split the initiate request
multiple messages. Each PCInitiate message sent by the PCE, except over multiple messages. Each PCInitiate message sent by the PCE,
the last one, will have the F flag set in the LSP object to signify except the last one, will have the F flag set in the LSP object to
that the PCInitiate has been fragmented into multiple messages. In signify that the PCInitiate has been fragmented into multiple
order to identify that a series of PCInitiate messages represents a messages. In order to identify that a series of PCInitiate messages
single Initiate, each message will use the same PLSP-ID (in this case represents a single Initiate, each message will use the same PLSP-ID
0) and SRP-ID-number. (in this case 0) and SRP-ID-number.
The Error-Type value 18 ("P2MP Fragmentation Error") is used to The Error-Type value 18 ("P2MP Fragmentation Error") is used to
report any error associated with the fragmentation of a P2MP PCEP report any error associated with the fragmentation of a P2MP PCEP
message. A new error-value 4 indicates "Fragmented instantiation message. A new error-value 4 indicates "Fragmented instantiation
failure" and is used if a PCC does not receive the last part of the failure" and is used if a PCC does not receive the last part of the
fragmented message. fragmented message.
9. Nonsupport of P2MP TE LSPs for Stateful PCE 9. Nonsupport of P2MP TE LSPs for Stateful PCE
The PCEP extensions described in this document for stateful PCEs with The PCEP extensions described in this document for stateful PCEs with
 End of changes. 7 change blocks. 
26 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/