Extensions to Path Computation Element Communication Protocol (PCEP) for Backup Ingress of a Traffic Engineering Label Switched Path

4.1.1. Capability TLV in Existing PCE Discovery Protocol

There are a couple of options for advertising a PCE capability for computing a backup ingress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP.¶

The first option is to define a new flag in the OSPF and ISIS PCE Capability Flags to indicate the capability that a PCE is capable to compute both a backup ingress for an MPLS TE P2MP LSP and a backup ingress for an MPLS TE P2P LSP.¶

The second option is to define two new flags. One new flag in the OSPF and ISIS PCE Capability Flags indicates the capability that a PCE is capable to compute a backup ingress for an MPLS TE P2MP LSP; and another new flag in the OSPF and ISIS PCE Capability Flags indicates the capability that a PCE is capable to compute a backup ingress for an MPLS TE P2P LSP.¶

This second option is preferred now.¶

The format of the PCE-CAP-FLAGS sub-TLV 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Type = 5         |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                 PCE Capability Flags                          ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type:     5
      Length:   Multiple of 4 octets
      Value:    This contains an array of units of 32-bit flags
                numbered from the most significant as bit zero, where
                each bit represents one PCE capability.

The following capability bits have been assigned by IANA:

      Bit       Capabilities
       0        Path computation with GMPLS link constraints
       1        Bidirectional path computation
       2        Diverse path computation
       3        Load-balanced path computation
       4        Synchronized path computation
       5        Support for multiple objective functions
       6        Support for additive path constraints
                (max hop count, etc.)
       7        Support for request prioritization
       8        Support for multiple requests per message
       9        Global Concurrent Optimization (GCO)
       10       P2MP path computation
      11-31     Reserved for future assignments by IANA.

Reserved bits SHOULD be set to zero on transmission and MUST be ignored on receipt.¶

For the second option, one bit such as bit 11 may be assigned to indicate that a PCE is capable to compute a backup ingress for an MPLS TE P2MP LSP and another bit such as bit 12 may be assigned to indicate that a PCE is capable to compute a backup ingress for an MPLS TE P2P LSP.¶

      Bit       Capabilities
       11       Backup ingress computation for P2MP LSP
       12       Backup ingress computation for P2P LSP
      13-31     Reserved for future assignments by IANA.

4.1.2. Open Message Extension

If a PCE does not advertise its backup ingress compution capability during discovery, PCEP should be used to allow a PCC to discover, during the Open Message Exchange, which PCEs are capable of supporting backup ingress computation.¶

To achieve this, we extend the PCEP OPEN object by defining a new optional TLV to indicate the PCE's capability to perform backup ingress compution for an MPLS TE P2MP LSP and an MPLS TE P2P LSP.¶

We request IANA to allocate a value such as 8 from the "PCEP TLV Type Indicators" subregistry, as documented in Section below ("Backup Ingress Capability TLV"). The description is "backup ingress capable", and the length value is 2 bytes. The value field is set to indicate the capability of a PCE for backup ingress compution for an MPLS TE LSP in details.¶

We can use flag bits in the value field in the same way as the PCE Capability Flags described in the previous section.¶

The inclusion of this TLV in an OPEN object indicates that the sender can perform backup ingress compution for an MPLS TE P2MP LSP or an MPLS TE P2P LSP.¶

The capability TLV is meaningful only for a PCE, so it will typically appear only in one of the two Open messages during PCE session establishment. However, in case of PCE cooperation (e.g., inter-domain), when a PCE behaving as a PCC initiates a PCE session it SHOULD also indicate its path computation capabilities.¶

4.2.1. RP Object Extension

The following flags are added into the RP Object:¶

The I bit is added in the flag bits field of the RP object to tell the receiver of the message that the request/reply is for computing a bcakup ingress of an MPLS TE P2MP LSP and an MPLS TE P2P LSP.¶

    o I ( Backup Ingress bit - 1 bit):
        0: This indicates that this is not PCReq/PCRep
           for backup ingress.
        1: This indicates that this is PCReq or PCRep message
           for backup ingress.

The IANA request is referenced in Section below (Request Parameter Bit Flags) of this document.¶

This I bit with the N bit defined in RFC6006 can indicate whether the request/reply is for a bcakup ingress of an MPLS TE P2MP LSP or an MPLS TE P2P LSP.¶

    o I = 1 and N = 1: This indicates that this is a PCReq/PCRep
                       message for backup ingress of an MPLS TE
                       P2MP LSP.
    o I = 1 and N = 0: This indicates that this is a PCReq/PCRep
                       message for backup ingress of an MPLS TE
                       P2P LSP.

4.2.2. External Source Node

In addition to the information about the path that an MPLS TE P2MP LSP or an MPLS TE P2P LSP traverses, a request message may comprise other information that may be used for computing the backup ingress for the P2MP LSP or P2P LSP. For example, the information about an external source node, from which data traffic is delivered to the ingress node of the P2MP LSP or P2P LSP and transported to the egress node(s) via the P2MP LSP or P2P LSP, is useful for computing a backup ingress node.¶

The PCC can specify an external source node (ESN) Object. The ESN Object has the same format as the IRO object defined in [RFC5440] except that it only supports IPv4 and IPv6 prefix sub-objects.¶

The object can only be carried in a PCReq message. A Path Request may carry at most one external source node Object.¶

The Object-Class and Object-types will need to be allocated by IANA. The IANA request is documented in Section below. (PCEP Objects).¶

Alternatively, we may use END-POINTS to represent an external source node in a request message for computing a backup ingress node of MPLS LSP.¶

To represent an external source node efficiently, we define a new type of END-POINTS objects for computing a backup ingress node of MPLS LSP. The format of the new END-POINTS object body for IPv4 (Object-Type 3) 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  External Source Type (11)                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                 External Source IPv4 address                  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The new type of END-POINTS is External Source Node Type (11). The final value for the type will be assigned by IANA. This new type of END-POINTS object contains an external source node IPv4 address.¶

4.2.3. Constraints between Ingress and Backup Ingress

A request message sent to a PCE from a PCC for computing a backup ingress of an MPLS TE P2MP LSP or an MPLS TE P2P LSP may comprise a constraint indicating that there must be a path from the backup ingress node to be computed to the ingress node of the P2MP LSP or P2P LSP and that the length of the path is within a given hop limit such as one hop.¶

This constraint can be considered as default by a PCE or explicitly sent to the PCE by a PCC [TBD].¶

4.2.4. Constraints for Backup Path

A request message sent to a PCE from a PCC for computing a backup ingress of a P2MP LSP or P2P LSP may comprise a constraint indicating that the backup ingress node to be computed may not be a node on the P2MP LSP or P2P LSP. In addition, the request message may comprise a list of nodes, each of which is a candidate for the backup ingress node.¶

A request message sent to a PCE from a PCC for computing a backup ingress of a P2MP LSP or P2P LSP may comprise a constraint indicating that there must be a path from the backup ingress node to be computed to the next-hop nodes of the ingress node of the P2MP LSP or P2P LSP and that there is not an internal node of the path from the backup ingress to the next-hop nodes on the P2MP LSP or P2P LSP .¶

Most of these constraints for the backup path can be considered as default by a PCE. The constraints for the backup path may be explicitly sent to the PCE by a PCC [TBD].¶

4.2.5. Backup Ingress Node

The PCE may send a reply message to the PCC in return to the request message for computing a new backup ingress node. The reply message may comprise information about the computed backup ingress node, which is contained in the path from the backup ingress computed to the next-hop node(s) of the ingress node of the P2MP LSP or P2P LSP.¶

The backup ingress node is the root or head node of the backup path computed.¶

4.2.6. Backup Ingress PCEP Error Objects and Types

In some cases, the PCE may not complete the backup ingress computation as requested, for example based on a set of constraints. As such, the PCE may send a reply message to the PCC that indicates an unsuccessful backup ingress computation attempt. The reply message may comprise a PCEP-error object, which may comprise an error-value, error-type and some detail information.¶

4.2.7. Request Message Format

The PCReq message is encoded as follows using RBNF as defined in [RFC5511].¶

Below is the message format for a request message:¶

            <PCReq Message>::= <Common Header>
                               [<svec-list>]
                               <request>
            <request>::= <RP> <end-point-rro-pair-list> [<OF>]
                         [<LSPA>] [<BANDWIDTH>] [<metric-list>]
                         [<ESNO>]
                         [<IRO>]
                         [<LOAD-BALANCING>]
       where:
             <ESNO> is an external source node object.

The definitions for svec-list, RP, end-point-rro-pair-list, OF, LSPA, BANDWIDTH, metric-list, IRO, and LOAD-BALANCING are described in RFC5440 and RFC6006.¶

4.2.8. Reply Message Format

The PCRep message is encoded as follows using RBNF as defined in [RFC5511].¶

Below is the message format for a reply message:¶

            <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>::= [<OF>] [<LSPA>] [<BANDWIDTH>]
                               [<metric-list>] [<IRO>]

The definitions for RP, NO-PATH, END-POINTS, OF, LSPA, BANDWIDTH, metric-list, IRO, and SERO are described in RFC5440, RFC6006 and RFC4875.¶