Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8306

 
 
 

Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths

Part 2 of 3, p. 16 to 29
Prev Section       Next Section

 


prevText      Top      ToC       Page 16 
3.6.  P2MP Objective Functions and Metric Types

3.6.1.  Objective Functions

   Six objective functions have been defined in [RFC5541] for P2P path
   computation.

   This document defines two additional objective functions -- namely,
   SPT (Shortest-Path Tree) and MCT (Minimum-Cost Tree) -- that apply to
   P2MP path computation.  Hence, two objective function codes are
   defined as follows:

   Objective Function Code: 7

      Name: Shortest-Path Tree (SPT)

      Description: Minimize the maximum source-to-leaf cost with respect
      to a specific metric or to the TE metric used as the default
      metric when the metric is not specified (e.g., TE or IGP metric).

   Objective Function Code: 8

      Name: Minimum-Cost Tree (MCT)

      Description: Minimize the total cost of the tree (i.e., the sum of
      the costs of tree links) with respect to a specific metric or to
      the TE metric used as the default metric when the metric is not
      specified.

   Processing these two objective functions is subject to the rules
   defined in [RFC5541].

Top      Up      ToC       Page 17 
3.6.2.  METRIC Object-Type Values

   There are three types defined for the METRIC object in [RFC5440] --
   namely, the IGP metric, the TE metric, and Hop Counts.  This document
   defines three additional types for the METRIC object: the P2MP IGP
   metric, the P2MP TE metric, and the P2MP hop count metric.  They
   encode the sum of the metrics of all links of the tree.  The
   following values for these metric types have been assigned; see
   Section 6.4.

   o  P2MP IGP metric: T=8

   o  P2MP TE metric: T=9

   o  P2MP hop count metric: T=10

3.7.  Non-Support of P2MP Path Computation

   o  If a PCE receives a P2MP path computation request and it
      understands the P2MP flag in the RP object, but the PCE is not
      capable of P2MP computation, the PCE MUST send a PCErr message
      with a PCEP-ERROR object and corresponding Error-value.  The
      request MUST then be cancelled at the PCC.  The Error-Types and
      Error-values have been assigned; see Section 6 ("IANA
      Considerations") of this document.

   o  If the PCE does not understand the P2MP flag in the RP object,
      then the PCE would send a PCErr message with Error-Type=2
      (Capability not supported) as per [RFC5440].

3.8.  Non-Support by Back-Level PCE Implementations

   If a PCE receives a P2MP request and the PCE does not understand the
   P2MP flag in the RP object, and therefore the PCEP P2MP extensions,
   then the PCE SHOULD reject the request.

3.9.  P2MP TE Path Reoptimization Request

   A reoptimization request for a P2MP TE path is specified by the use
   of the R-bit within the RP object as defined in [RFC5440] and is
   similar to the reoptimization request for a P2P TE path.  The only
   difference is that the PCC MUST insert the list of Record Route
   Objects (RROs) and SRROs after each instance of the END-POINTS object
   in the PCReq message, as described in Section 3.4 ("Request Message
   Format") of this document.

Top      Up      ToC       Page 18 
   An example of a reoptimization request and subsequent PCReq message
   is described below:

                        Common Header
                        RP with P2MP flag/R-bit set
                        END-POINTS for leaf type 3
                          RRO list
                        OF (optional)

            Figure 5: PCReq Message Example 1 for Optimization

   In this example, we request reoptimization of the path to all leaves
   without adding or pruning leaves.  The reoptimization request would
   use an END-POINTS object with leaf type 3.  The RRO list would
   represent the P2MP LSP before the optimization, and the modifiable
   path leaves would be indicated in the END-POINTS object.

   It is also possible to specify distinct leaves whose path cannot be
   modified.  An example of the PCReq message in this scenario would be:

                      Common Header
                      RP with P2MP flag/R-bit set
                      END-POINTS for leaf type 3
                        RRO list
                      END-POINTS for leaf type 4
                        RRO list
                      OF (optional)

            Figure 6: PCReq Message Example 2 for Optimization

3.10.  Adding and Pruning Leaves to/from the P2MP Tree

   When adding new leaves to or removing old leaves from the existing
   P2MP tree, by supplying a list of existing leaves, it is possible to
   optimize the existing P2MP tree.  This section explains the methods
   for adding new leaves to or removing old leaves from the existing
   P2MP tree.

   To add new leaves, the PCC MUST build a P2MP request using END-POINTS
   with leaf type 1.

   To remove old leaves, the PCC MUST build a P2MP request using
   END-POINTS with leaf type 2.  If no type-2 END-POINTS exist, then the
   PCE MUST send Error-Type 17, Error-value 1: the PCE cannot satisfy
   the request due to no END-POINTS with leaf type 2.

Top      Up      ToC       Page 19 
   When adding new leaves to or removing old leaves from the existing
   P2MP tree, the PCC MUST also provide the list of old leaves, if any,
   including END-POINTS with leaf type 3, leaf type 4, or both.
   Specific PCEP-ERROR objects and types are used when certain
   conditions are not satisfied (i.e., when there are no END-POINTS with
   leaf type 3 or 4, or in the presence of END-POINTS with leaf type 1
   or 2).  A generic "Inconsistent END-POINTS" error will be used if a
   PCC receives a request that has an inconsistent END-POINTS setting
   (i.e., if a leaf specified as type 1 already exists).  These IANA
   assignments are documented in Section 6.6 ("PCEP-ERROR Objects and
   Types") of this document.

   For old leaves, the PCC MUST provide the old path as a list of RROs
   that immediately follows each END-POINTS object.  This document
   specifies Error-values when specific conditions are not satisfied.

   The following examples demonstrate full and partial reoptimization of
   existing P2MP LSPs:

   Case 1: Adding leaves with full reoptimization of existing paths

              Common Header
              RP with P2MP flag/R-bit set
              END-POINTS for leaf type 1
                RRO list
              END-POINTS for leaf type 3
                RRO list
              OF (optional)

   Case 2: Adding leaves with partial reoptimization of existing paths

              Common Header
              RP with P2MP flag/R-bit set
              END-POINTS for leaf type 1
              END-POINTS for leaf type 3
                RRO list
              END-POINTS for leaf type 4
                RRO list
              OF (optional)

Top      Up      ToC       Page 20 
   Case 3: Adding leaves without reoptimization of existing paths

              Common Header
              RP with P2MP flag/R-bit set
              END-POINTS for leaf type 1
                RRO list
              END-POINTS for leaf type 4
                RRO list
              OF (optional)

   Case 4: Pruning leaves with full reoptimization of existing paths

              Common Header
              RP with P2MP flag/R-bit set
              END-POINTS for leaf type 2
                RRO list
              END-POINTS for leaf type 3
                RRO list
              OF (optional)

   Case 5: Pruning leaves with partial reoptimization of existing paths

              Common Header
              RP with P2MP flag/R-bit set
              END-POINTS for leaf type 2
                RRO list
              END-POINTS for leaf type 3
                RRO list
              END-POINTS for leaf type 4
                RRO list
              OF (optional)

   Case 6: Pruning leaves without reoptimization of existing paths

              Common Header
              RP with P2MP flag/R-bit set
              END-POINTS for leaf type 2
                RRO list
              END-POINTS for leaf type 4
                RRO list
              OF (optional)

Top      Up      ToC       Page 21 
   Case 7: Adding and pruning leaves with full reoptimization of
           existing paths

              Common Header
              RP with P2MP flag/R-bit set
              END-POINTS for leaf type 1
              END-POINTS for leaf type 2
                RRO list
              END-POINTS for leaf type 3
                RRO list
              OF (optional)

   Case 8: Adding and pruning leaves with partial reoptimization of
           existing paths

              Common Header
              RP with P2MP flag/R-bit set
              END-POINTS for leaf type 1
              END-POINTS for leaf type 2
                RRO list
              END-POINTS for leaf type 3
                RRO list
              END-POINTS for leaf type 4
                RRO list
              OF (optional)

   Case 9: Adding and pruning leaves without reoptimization of existing
           paths

              Common Header
              RP with P2MP flag/R-bit set
              END-POINTS for leaf type 1
              END-POINTS for leaf type 2
                RRO list
              END-POINTS for leaf type 4
                RRO list
              OF (optional)

Top      Up      ToC       Page 22 
3.11.  Discovering Branch Nodes

   Before computing the P2MP path, a PCE may need to be provided means
   to know which nodes in the network are capable of acting as branch
   LSRs.  A PCE can discover such capabilities by using the mechanisms
   defined in [RFC5073].

3.11.1.  Branch Node Object

   The PCC can specify a list of nodes that can be used as branch nodes
   or a list of nodes that cannot be used as branch nodes by using the
   Branch Node Capability (BNC) object.  The BNC object has the same
   format as the Include Route Object (IRO) as defined in [RFC5440],
   except that it only supports IPv4 and IPv6 prefix sub-objects.  Two
   Object-Type parameters are also defined:

   o  Branch node list: List of nodes that can be used as branch nodes.

   o  Non-branch node list: List of nodes that cannot be used as branch
      nodes.

   The object can only be carried in a PCReq message.  A path
   computation request may carry at most one Branch Node object.

   The Object-Class and Object-Type values have been allocated by IANA.
   The IANA assignments are documented in Section 6.5 ("PCEP Objects").

3.12.  Synchronization of P2MP TE Path Computation Requests

   There are cases when multiple P2MP LSPs' computations need to be
   synchronized.  For example, one P2MP LSP is the designated backup of
   another P2MP LSP.  In this case, path diversity for these dependent
   LSPs may need to be considered during the path computation.

   The synchronization can be done by using the existing SVEC
   functionality as defined in [RFC5440].

Top      Up      ToC       Page 23 
   An example of synchronizing two P2MP LSPs, each having two leaves for
   Path Computation Request messages, is illustrated below:

                      Common Header
                      SVEC for sync of LSP1 and LSP2
                      OF (optional)
                      RP for LSP1
                        END-POINTS1 for LSP1
                        RRO1 list
                      RP for LSP2
                        END-POINTS2 for LSP2
                        RRO2 list

            Figure 7: PCReq Message Example for Synchronization

   This specification also defines two flags for the SVEC Object Flag
   Field for P2MP path-dependent computation requests.  The first flag
   allows the PCC to request that the PCE should compute a secondary
   P2MP path tree with partial path diversity for specific leaves or a
   specific S2L sub-path to the primary P2MP path tree.  The second flag
   allows the PCC to request that partial paths should be
   link direction diverse.

   The following flags are added to the SVEC object body in this
   document:

   o  P (Partial Path Diverse bit - 1 bit):

      When set, this would indicate a request for path diversity for a
      specific leaf, a set of leaves, or all leaves.

   o  D (Link Direction Diverse bit - 1 bit):

      When set, this would indicate a request that a partial path or
      paths should be link direction diverse.

   The IANA assignments are referenced in Section 6.8 of this document.

3.13.  Request and Response Fragmentation

   The total PCEP message length, including the common header, is
   16 bytes.  In certain scenarios, the P2MP computation request may not
   fit into a single request or response message.  For example, if a
   tree has many hundreds or thousands of leaves, then the request or
   response may need to be fragmented into multiple messages.

Top      Up      ToC       Page 24 
   The F-bit is outlined in Section 3.3.1 ("The Extension of the RP
   Object") of this document.  The F-bit is used in the RP object to
   signal that the initial request or response was too large to fit into
   a single message and will be fragmented into multiple messages.  In
   order to identify the single request or response, each message will
   use the same request ID.

3.13.1.  Request Fragmentation Procedure

   If the initial request is too large to fit into a single request
   message, the PCC will split the request over multiple messages.  Each
   message sent to the PCE, except the last one, will have the F-bit set
   in the RP object to signify that the request has been fragmented into
   multiple messages.  In order to identify that a series of request
   messages represents a single request, each message will use the same
   request ID.

   The assumption is that request messages are reliably delivered and in
   sequence, since PCEP relies on TCP.

3.13.2.  Response Fragmentation Procedure

   Once the PCE computes a path based on the initial request, a response
   is sent back to the PCC.  If the response is too large to fit into a
   single response message, the PCE will split the response over
   multiple messages.  Each message sent by the PCE, except the last
   one, will have the F-bit set in the RP object to signify that the
   response has been fragmented into multiple messages.  In order to
   identify that a series of response messages represents a single
   response, each message will use the same response ID.

   Again, the assumption is that response messages are reliably
   delivered and in sequence, since PCEP relies on TCP.

3.13.3.  Fragmentation Example

   The following example illustrates the PCC sending a request message
   with Req-ID1 to the PCE, in order to add one leaf to an existing tree
   with 1200 leaves.  The assumption used for this example is that one
   request message can hold up to 800 leaves.  In this scenario, the
   original single message needs to be fragmented and sent using two
   smaller messages, which have Req-ID1 specified in the RP object, and
   with the F-bit set on the first message and the F-bit cleared on the
   second message.

Top      Up      ToC       Page 25 
                 Common Header
                 RP1 with Req-ID1 and P2MP=1 and F-bit=1
                 OF (optional)
                 END-POINTS1 for P2MP
                   RRO1 list

                 Common Header
                 RP2 with Req-ID1 and P2MP=1 and F-bit=0
                 OF (optional)
                 END-POINTS1 for P2MP
                   RRO1 list

               Figure 8: PCReq Message Fragmentation Example

   To handle a scenario where the last fragmented message piece is lost,
   the receiver side of the fragmented message may start a timer once it
   receives the first piece of the fragmented message.  If the timer
   expires and it still has not received the last piece of the
   fragmented message, it should send an error message to the sender to
   signal that it has received an incomplete message.  The relevant
   error message is documented in Section 3.15 ("P2MP PCEP-ERROR Objects
   and Types").

3.14.  UNREACH-DESTINATION Object

   The PCE path computation request may fail because all or a subset of
   the destinations are unreachable.

   In such a case, the UNREACH-DESTINATION object allows the PCE to
   optionally specify the list of unreachable destinations.

   This object can be present in PCRep messages.  There can be up to one
   such object per RP.

Top      Up      ToC       Page 26 
   The following UNREACH-DESTINATION objects (for IPv4 and IPv6) are
   defined:

      UNREACH-DESTINATION Object-Class is 28.
      UNREACH-DESTINATION Object-Type for IPv4 is 1.
      UNREACH-DESTINATION Object-Type for IPv6 is 2.

   The format of the UNREACH-DESTINATION object body for IPv4
   (Object-Type=1) is as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Destination IPv4 address                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                           ...                                 ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Destination IPv4 address                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 9: UNREACH-DESTINATION Object Body for IPv4

   The format of the UNREACH-DESTINATION object body for IPv6
   (Object-Type=2) is as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |            Destination IPv6 address (16 bytes)                |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                          ...                                  ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |              Destination IPv6 address (16 bytes)              |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 10: UNREACH-DESTINATION Object Body for IPv6

Top      Up      ToC       Page 27 
3.15.  P2MP PCEP-ERROR Objects and Types

   To indicate an error associated with a policy violation, the
   Error-value "P2MP Path computation is not allowed" has been added to
   the existing error code for Error-Type 5 ("Policy violation") as
   defined in [RFC5440] (see also Section 6.6 of this document):

      Error-Type=5; Error-value=7: if a PCE receives a P2MP path
      computation request that is not compliant with administrative
      privileges (i.e., "The PCE policy does not support P2MP path
      computation"), the PCE MUST send a PCErr message with a PCEP-ERROR
      object (Error-Type=5) and an Error-value of 7.  The corresponding
      P2MP path computation request MUST also be cancelled.

   To indicate capability errors associated with the P2MP path
   computation request, Error-Type (16) and subsequent Error-values are
   defined as follows for inclusion in the PCEP-ERROR object:

      Error-Type=16; Error-value=1: if a PCE receives a P2MP path
      computation request and the PCE is not capable of satisfying the
      request due to insufficient memory, the PCE MUST send a PCErr
      message with a PCEP-ERROR object (Error-Type=16) and an
      Error-value of 1.  The corresponding P2MP path computation request
      MUST also be cancelled.

      Error-Type=16; Error-value=2: if a PCE receives a P2MP path
      computation request and the PCE is not capable of P2MP
      computation, the PCE MUST send a PCErr message with a PCEP-ERROR
      object (Error-Type=16) and an Error-value of 2.  The corresponding
      P2MP path computation request MUST also be cancelled.

   To indicate P2MP message fragmentation errors associated with a P2MP
   path computation request, Error-Type (18) and subsequent Error-values
   are defined as follows for inclusion in the PCEP-ERROR object:

      Error-Type=18; Error-value=1: if a PCE has not received the last
      piece of the fragmented message, it should send an error message
      to the sender to signal that it has received an incomplete message
      (i.e., "Fragmented request failure").  The PCE MUST send a PCErr
      message with a PCEP-ERROR object (Error-Type=18) and an
      Error-value of 1.

Top      Up      ToC       Page 28 
3.16.  PCEP NO-PATH Indicator

   To communicate the reasons for not being able to find a P2MP path
   computation, the NO-PATH object can be used in the PCRep message.

   One bit is defined in the NO-PATH-VECTOR TLV carried in the NO-PATH
   object:

      bit 24: when set, the PCE indicates that there is a reachability
      problem with all or a subset of the P2MP destinations.
      Optionally, the PCE can specify the destination or list of
      destinations that are not reachable using the UNREACH-DESTINATION
      object defined in Section 3.14.

4.  Manageability Considerations

   [RFC5862] describes various manageability requirements in support of
   P2MP path computation when applying PCEP.  This section describes how
   manageability requirements mentioned in [RFC5862] are supported in
   the context of PCEP extensions specified in this document.

   Note that [RFC5440] describes various manageability considerations
   for PCEP, and most of the manageability requirements mentioned in
   [RFC5862] are already covered there.

4.1.  Control of Function and Policy

   In addition to PCE configuration parameters listed in [RFC5440], the
   following additional parameters might be required:

   o  The PCE may be configured to enable or disable P2MP path
      computations.

   o  The PCE may be configured to enable or disable the advertisement
      of its P2MP path computation capability.  A PCE can advertise its
      P2MP capability via the IGP discovery mechanism discussed in
      Section 3.1.1 ("IGP Extensions for P2MP Capability Advertisement")
      or during the Open Message Exchange discussed in Section 3.1.2
      ("Open Message Extension").

4.2.  Information and Data Models

   A number of MIB objects have been defined in [RFC7420] for general
   PCEP control and monitoring of P2P computations.  [RFC5862] specifies
   that MIB objects will be required to support the control and
   monitoring of the protocol extensions defined in this document.  A
   new document will be required to define MIB objects for PCEP control
   and monitoring of P2MP computations.

Top      Up      ToC       Page 29 
   The "ietf-pcep" PCEP YANG module is specified in [PCEP-YANG].  The
   P2MP capability of a PCEP entity or a configured peer can be set
   using this YANG module.  Also, support for P2MP path computation can
   be learned using this module.  The statistics are maintained in the
   "ietf-pcep-stats" YANG module as specified in [PCEP-YANG].  This YANG
   module will be required to be augmented to also include the
   P2MP-related statistics.

4.3.  Liveness Detection and Monitoring

   There are no additional considerations beyond those expressed in
   [RFC5440], since [RFC5862] does not address any additional
   requirements.

4.4.  Verifying Correct Operation

   There are no additional requirements beyond those expressed in
   [RFC4657] for verifying the correct operation of the PCEP sessions.
   It is expected that future MIB objects will facilitate verification
   of correct operation and reporting of P2MP PCEP requests, responses,
   and errors.

4.5.  Requirements for Other Protocols and Functional Components

   The method for the PCE to obtain information about a PCE capable of
   P2MP path computations via OSPF and IS-IS is discussed in
   Section 3.1.1 ("IGP Extensions for P2MP Capability Advertisement") of
   this document.

   The relevant IANA assignment is documented in Section 6.9 ("OSPF PCE
   Capability Flag") of this document.

4.6.  Impact on Network Operation

   It is expected that the use of PCEP extensions specified in this
   document will not significantly increase the level of operational
   traffic.  However, computing a P2MP tree may require more PCE state
   compared to a P2P computation.  In the event of a major network
   failure and multiple recovery P2MP tree computation requests being
   sent to the PCE, the load on the PCE may also be significantly
   increased.


Next Section