Extensions to Path Computation Element Communication Protocol (PCEP)
for Backup Ingress of a Traffic Engineering Label Switched Path
FutureweiBoston, MAUSAHuaimo.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 ingress for an MPLS TE P2MP LSP or
an MPLS TE P2P LSP
to a PCE and for a PCE to compute the backup ingress and reply to the PCC with
a computation result for the backup ingress.
RFC4090 "Fast Reroute Extensions to RSVP-TE for LSP Tunnels" describes two methods
to protect P2P LSP tunnels or paths at local repair points.
The local repair points may comprise a number of intermediate nodes between an
ingress node and an egress node along the path.
The first method is a one-to-one backup method, where a detour backup P2P LSP for
each protected P2P LSP is created at each potential point of local repair.
The second method is a facility bypass backup protection method, where a bypass backup
P2P LSP tunnel is created using MPLS label stacking to protect a potential failure
point for a set of P2P LSP tunnels. The bypass backup tunnel can protect a set of
P2P LSPs that have similar backup constraints.
RFC4875 "Extensions to RSVP-TE for P2MP TE LSPs" describes
how to use the one-to-one backup method and facility bypass backup method to protect
a link or intermediate node failure on the path of a P2MP LSP.
However, there is no mention of locally protecting an ingress node
failure in a protected P2MP LSP or P2P LSP.
The methods for protecting an ingress node of a P2MP LSP or P2P LSP
may be classified into two categories.
A first category uses a backup P2MP LSP that is from a backup ingress node to
the number of destination nodes for the P2MP LSP,
and a backup P2P LSP that is from a backup ingress node to
the destination node for the P2P LSP.
The disadvantages of this class of methods include more network resource such as
computer power and link bandwidth consumption since the backup P2MP LSP or P2P LSP
is from the backup ingress node to the number of destination nodes or the destination
respectively.
A second category uses a local P2MP LSP or P2P LSP for protecting
the ingress of a P2MP LSP or P2P LSP locally.
The local P2MP LSP is from a backup ingress node to the next hop nodes of
the ingress of the P2MP LSP.
The local P2P LSP is from a backup ingress node to the next hop node of
the ingress of the P2P LSP.
It is desirable to let PCE compute these backup ingress nodes.
This document defines extensions to the Path Computation Element
Communication Protocol (PCEP) for a PCC to send a request for computing
a backup ingress node for an MPLS TE P2MP LSP or an MPLS TE P2P LSP
to a PCE and for a PCE to compute the backup ingress node and
reply to the PCC with a computation result for the backup ingress node.
This document uses terminologies defined in RFC5440, RFC4090,
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 RFC2119.
This section describes the extensions to PCEP for computing
a backup ingress of an MPLS TE P2MP LSP and an MPLS TE P2P LSP.
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:
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.
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.
This section describes extensions to the existing RP (Request Parameters)
object to allow a PCC to request a PCE for computing a backup ingress
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 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.
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.
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:
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.
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].
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].
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.
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.
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 and 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 ingress
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 ingress capability TLV is defined in this document
to allow a PCE to advertize its backup ingress 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 Source Node 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 Cyril Margaria,
Ramon Casellas, Dhruv Dhody
and Quintin Zhao
for their valuable comments and suggestions on this draft.