Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8623

Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs)

Pages: 33
Proposed Standard
Part 2 of 3 – Pages 11 to 23
First   Prev   Next

Top   ToC   RFC8623 - Page 11   prevText

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>]
Top   ToC   RFC8623 - Page 12
   <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
Top   ToC   RFC8623 - Page 13
   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>]
Top   ToC   RFC8623 - Page 14
   <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>]
Top   ToC   RFC8623 - Page 15
   <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>]
Top   ToC   RFC8623 - Page 16

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].
Top   ToC   RFC8623 - Page 17
   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)
Top   ToC   RFC8623 - Page 18
   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.
Top   ToC   RFC8623 - Page 19

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.
Top   ToC   RFC8623 - Page 20
   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.
Top   ToC   RFC8623 - Page 21
   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.
Top   ToC   RFC8623 - Page 22
   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
Top   ToC   RFC8623 - Page 23
   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)

Next Section