Extensions to the Path Computation Element Communication Protocol (PCEP)
for Backup Egress of a Traffic Engineering Label Switched Path
Futurewei
BostonMAUSAHuaimo.chen@futurewei.com
General
Internet Engineering Task Forcetemplate
This document presents extensions to the Path Computation Element Communication Protocol (PCEP)
for a PCC to send a request for computing a backup egress for an MPLS TE P2MP LSP or
an MPLS TE P2P LSP
to a PCE and for a PCE to compute the backup egress and reply to the PCC with
a computation result for the backup egress.
RFC 4655 "A Path Computation Element-(PCE) Based Architecture"
describes a set of building blocks for constructing solutions to
compute Point-to-Point (P2P) Traffic Engineering (TE) label switched
paths across multiple areas or Autonomous System (AS) domains.
A typical PCE-based system comprises one or more path computation
servers, traffic engineering databases (TED), and a number of
path computation clients (PCC). A routing protocol is used to
exchange traffic engineering information from which the TED is
constructed. A PCC sends a Point-to-Point traffic engineering Label
Switched Path (LSP) computation request to the path computation
server, which uses the TED to compute the path and responses to
the PCC with the computed path. A path computation server is
named as a PCE. The communications between a PCE and a PCC for
Point-to-Point label switched path computations follow the PCE
communication protocol (PCEP).
RFC6006 "Extensions to PCEP
for Point-to-Multipoint Traffic Engineering Label Switched Paths"
describes extensions to PCEP to
handle requests and responses for the computation of paths for P2MP TE LSPs.
This document defines extensions to the Path Computation Element
Communication Protocol (PCEP) for a PCC to send a request for computing
a backup egress node for an MPLS TE P2MP LSP or an MPLS TE P2P LSP
to a PCE and for a PCE to compute the backup egress node and
reply to the PCC with a computation result for the backup egress node.
This document uses terminologies defined in RFC5440, and RFC4875.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
This section describes the extensions to PCEP for computing
a backup egress of an MPLS TE P2MP LSP and an MPLS TE P2P LSP.
An option for advertising a PCE capability for computing
a backup egress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP
is to define two new flags.
One new flag in the OSPF and IS-IS PCE Capability Flags
indicates the capability that a PCE is capable to compute
a backup egress for an MPLS TE P2MP LSP;
and another new flag in the OSPF and IS-IS PCE Capability Flags
indicates the capability that a PCE is capable to compute
a backup egress for an MPLS TE P2P LSP.
The format of the PCE-CAP-FLAGS sub-TLV is as follows:
Reserved bits SHOULD be set to zero on transmission and MUST be
ignored on receipt.
For the backup egress capabilities,
one bit such as bit 13 may be assigned to indicate that
a PCE is capable to compute a backup egress for
an MPLS TE P2MP LSP and another bit such as
bit 14 may be assigned to indicate that
a PCE is capable to compute a backup egress for an MPLS TE P2P LSP
as follows.
If a PCE does not advertise its backup egress 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 egress
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 egress computation 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 Egress Capability TLV").
The description is "backup egress capable",
and the length value is 2 bytes.
The value field is set to indicate the capability of a PCE for
backup egress computation 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 egress computation 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.
This section describes extensions to the existing RP (Request Parameters)
object to allow a PCC to request a PCE for computing a backup egress
of an MPLS TE P2MP LSP or an MPLS TE P2P LSP when the PCE receives
the PCEP request.
The following flags are added into the RP Object:
The T 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 egress of an MPLS TE P2MP LSP and an MPLS TE P2P LSP.
The IANA request is referenced in Section below (Request Parameter Bit
Flags) of this document.
This T bit with the N bit defined in RFC 6006 can indicate whether
a request/reply is for a bcakup egress of an MPLS TE P2MP LSP
or an MPLS TE P2P LSP.
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 egress for the P2MP LSP
or P2P LSP.
For example,
the information about an external destination node,
to which data traffic is delivered from an egress node of
the P2MP LSP or P2P LSP,
is useful for computing a backup egress node.
The PCC can specify an external destination nodes (EDN) Object.
In order to represent the external destination nodes efficiently,
we define two types of encodes for the external destination nodes
in the object.
One encode indicates that the EDN object contains an external destination
node for every egress node of an MPLS TE P2MP LSP
or an MPLS TE P2P LSP. The order of the external destination nodes
in the object is the same as the egress node(s) of the P2MP LSP
or P2P LSP contained in the PCE messages.
Another encode indicates that the EDN object contains
a list of egress node and external destination node pairs.
For an egress node and external destination node pair,
the data traffic is delivered to the external destination node
from the egress node of the LSP.
The format of the external destination nodes (EDN) object boby for
IPv4 with the first type of encodes is illustrated as follows:
The format of the external destination nodes (EDN) object boby for
IPv4 with the second type of encodes is illustrated below:
The format of the external destination nodes (EDN) object boby for
IPv6 with the first type of encodes is illustrated as follows:
The format of the external destination nodes (EDN) object boby for
IPv6 with the second type of encodes is illustrated below:
The object can only be carried in a PCReq message. A Path Request
may carry at most one external destination nodes 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
external destination nodes in a request message
for computing backup egress nodes of MPLS LSP.
The format of the external destination nodes (EDN) END-POINTS object boby for
IPv4 with the first type of encodes is illustrated as follows:
The new type of END-POINTS is Compact External Destination Nodes Type (12).
The final value for the type will be assigned by IANA.
The EDN END-POINTS object of type 12 contains an external destination
node for every egress node of an MPLS TE P2MP LSP
or an MPLS TE P2P LSP. The order of the external destination nodes
in the object is the same as the egress node(s) of the P2MP LSP
or P2P LSP contained in the PCE messages.
The format of the external destination nodes END-POINTS object boby for
IPv4 with the second type of encodes is illustrated below:
The new type of END-POINTS is External Destination Nodes Type (13).
The final value for the type will be assigned by IANA.
The EDN END-POINTS object of type 13 contains
a list of egress node and external destination node pairs.
For an egress node and external destination node pair,
the data traffic is delivered to the external destination node
from the egress node of the LSP.
A request message sent to a PCE from a PCC for computing
a backup egress 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 egress node
to be computed to the egress 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].
A request message sent to a PCE from a PCC for computing
a backup egress of a P2MP LSP or P2P LSP may comprise a constraint
indicating that the backup egress 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 egress node.
A request message sent to a PCE from a PCC for computing
a backup egress of a P2MP LSP or P2P LSP may comprise a constraint
indicating that there must be a path from the previous hop node of
the egress node of the P2MP LSP or P2P LSP
to the backup egress node to be computed
and that there is not an internal node of the path
from the previous hop node of the egress node of the P2MP LSP or P2P LSP
to the backup egress that is on the path of 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].
The PCE may send a reply message to the PCC in return to
the request message for computing a new backup egress node
or a number of backup egress nodes.
The reply message may comprise information about the computed
backup egress node(s),
which is contained in the path(s) from the previous-hop node of
the egress node of the P2MP LSP or P2P LSP to the
backup egress node(s) computed.
In some cases, the PCE may not complete the backup egress
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 egress
computation attempt.
The reply message may comprise a PCEP-error object, which may
comprise an error-value, error-type and some detail information.
The PCReq message is encoded as follows using RBNF as defined in
[RFC5511].
Below is the message format for a request message:
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.
The PCRep message is encoded as follows using RBNF as defined in
[RFC5511].
Below is the message format for a reply message:
The definitions for RP, NO-PATH, END-POINTS, OF,
LSPA, BANDWIDTH, metric-list, IRO, and SERO
are described in RFC5440, RFC6006 and RFC4875.
The mechanism described in this document does not raise any new
security issues for the PCEP, OSPF or IS-IS protocols.
This section specifies requests for IANA allocation.
Two new OSPF Capability Flags are defined in this document
to indicate the capabilities for computing a backup egress
for an MPLS TE P2MP LSP and an MPLS TE P2P LSP.
IANA is requested to
make the assignment from the "OSPF Parameters Path Computation
Element (PCE) Capability Flags" registry:
A new backup egress capability TLV is defined in this document
to allow a PCE to advertize its backup egress computation capability.
IANA is requested to make the following allocation from the "PCEP
TLV Type Indicators" sub-registry.
A new RP Object Flag has been defined in this document.
IANA is requested to make the following allocation
from the "PCEP RP Object Flag Field" Sub-Registry:
An External Destination Nodes Object-Type is defined in this document.
IANA is requested to make the following Object-Type
allocation from the "PCEP Objects" sub-registry:
The author would like to thank
Ramon Casellas, Dhruv Dhody
and Quintin Zhao
for their valuable comments on this draft.