RFC 8623
Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs)
Pages: 33
Proposed Standard
Proposed Standard
Part 2 of 3 – Pages 11 to 23
6. PCEP Message Extensions
Message formats in this section, as those in [RFC8231], [RFC8281], and [RFC5440], are presented using Routing Backus-Naur Format (RBNF) as specified in [RFC5511].6.1. The PCRpt Message
As per Section 6.1 of [RFC8231], 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>]
<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 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 [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 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
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
(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).
6.2. The PCUpd Message
As per Section 6.2 of [RFC8231], 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>]
<intended-attribute-list> is the attribute-list 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 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 [RFC5440]).6.3. The PCReq Message
As per Section 3.4 of [RFC8306], 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>]
<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>]
6.4. The PCRep Message
As per Section 3.5 of [RFC8306], 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>]
6.5. The PCInitiate Message
As defined in section 5.1 of [RFC8281], 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 [RFC5440] 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 [RFC8231].
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 [RFC5440]).
6.6. Example
6.6.1. P2MP TE LSPs Update Request
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.
6.6.2. P2MP TE LSP Report
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)
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)
6.6.3. P2MP TE LSPs Initiation Request
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.
7. PCEP Object Extensions
The new PCEP TLVs defined in this document are in compliance with the PCEP TLV format defined in [RFC5440].7.1. LSP Object Extension
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 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 Section 8 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 [RFC8306] 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 [RFC8306].7.1.1. P2MP-LSP-IDENTIFIERS TLV
[RFC8231] 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.
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 Section 5.6.3.1) 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 [RFC3209]. See Section 4.6.2.1 of [RFC3209] for the LSP_TUNNEL_IPv4 Sender Template Object. LSP ID: Contains the 16-bit 'LSP ID' identifier defined in [RFC3209]. See Section 4.6.2.1 of [RFC3209] for the LSP_TUNNEL_IPv4 Sender Template Object. Tunnel ID: Contains the 16-bit 'Tunnel ID' identifier defined in [RFC3209]. See Section 4.6.1.1 of [RFC3209] for the LSP_TUNNEL_IPv4 Session Object. Extended Tunnel ID: Contains the 32-bit 'Extended Tunnel ID' identifier defined in [RFC3209]. See Section 4.6.1.1 of [RFC3209] for the LSP_TUNNEL_IPv4 Session Object.
P2MP ID: Contains the 32-bit 'P2MP ID' identifier defined in
Section 19.1.1 of [RFC4875] 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 [RFC3209]. See Section 4.6.2.2 of [RFC3209] for the
LSP_TUNNEL_IPv6 Sender Template Object.
LSP ID: Contains the 16-bit 'LSP ID' identifier defined in
[RFC3209]. See Section 4.6.2.2 of [RFC3209] for the
LSP_TUNNEL_IPv6 Sender Template Object.
Tunnel ID: Contains the 16-bit 'Tunnel ID' identifier defined in
[RFC3209]. See Section 4.6.1.2 of [RFC3209] for the
LSP_TUNNEL_IPv6 Session Object.
Extended Tunnel ID: Contains the 128-bit 'Extended Tunnel ID'
identifier defined in [RFC3209]. See Section 4.6.1.2 of [RFC3209]
for the LSP_TUNNEL_IPv6 Session Object.
P2MP ID: Defined above under Figure 1.
Tunnel ID: Remains constant over the lifetime of a tunnel.
7.2. S2LS Object
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 Section 7.3 of
[RFC8231].
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
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.
(page 23 continued on part 3)