A Backward-Recursive PCE-Based
Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain
Traffic Engineering Label Switched PathsCisco Systems, Inc1414 Massachusetts AvenueBoxborough01719MAUSAjpv@cisco.comBT Infonet2160 E. Grand Ave.El Segundo90025CAUSAraymond.zhang@bt.comVerizon117 West StreetWaltham02451MAUSAnabil.n.bitar@verizon.comFrance Telecom2, Avenue Pierre-MarzinLannion22307FRANCEjeanlouis.leroux@orange-ftgroup.com
Routing Area
Networking Working GroupSample
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November 10,
2008. The person(s) controlling the copyright in some of this material
may not have granted the IETF Trust the right to allow modifications
of such material outside the IETF Standards Process. Without
obtaining an adequate license from the person(s) controlling the
copyright in such materials, this document may not be modified outside
the IETF Standards Process, and derivative works of it may not be
created outside the IETF Standards Process, except to format it for
publication as an RFC or to translate it into languages other than
English.
The ability to compute shortest constrained Traffic
Engineering Label Switched Paths (TE LSPs) in Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks
across multiple domains has been identified as a key
requirement. In this context, a domain is a collection of
network elements within a common sphere of address management or
path computational responsibility such as an IGP area or an
Autonomous Systems. This document specifies a procedure relying
on the use of multiple Path Computation Elements (PCEs) to
compute such inter-domain shortest constrained paths across a
predetermined sequence of domains, using a backward-recursive
path computation technique. This technique preserves
confidentiality across domains, which is sometimes required when
domains are managed by different service providers.The requirements for inter-area and inter-AS MPLS Traffic Engineering
(TE) have been developed by the Traffic Engineering Working Group (TE
WG) and have been stated in and , respectively.The framework for inter-domain Multiprotocol Label Switching (MPLS)
Traffic Engineering (TE) has been provided in . defines a technique for establishing
an inter-domain Generalized MPLS (GMPLS) TE Label Switched Path (LSP)
whereby the path is computed during the signaling process on a
per-domain basis by the entry boundary node of each domain (each node
responsible for triggering the computation of a section of an
inter-domain TE LSP path is always along the path of such TE LSP). This
path computation technique fulfills some of the requirements stated in
and but
not all of them. In particular, it cannot guarantee to find an optimal
(shortest) inter-domain constrained path. Furthermore, it cannot be
efficiently used to compute a set of inter-domain diversely routed TE
LSPs.The Path Computation Element (PCE) architecture is defined in . The aim of this document is to describe a
PCE-based path computation procedure to compute optimal inter-domain
constrained (G)MPLS TE LSPs.Qualifying a path as optimal requires some clarification. Indeed, a
globally optimal TE LSP placement usually refers to a set of TE LSPs
whose placements optimize the network resources with regards to a
specified objective function (e.g., a placement that reduces the maximum
or average network load while satisfying the TE LSP constraints). In
this document, an optimal inter-domain constrained TE LSP is defined as
the shortest path satisfying the set of required constraints that would
be obtained in the absence of multiple domains (in other words, in a
totally flat IGP network between the source and destination of the TE
LSP). Note that this requires the use of consistent metric schemes in each
domain (see ).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.ABR: Area Border Routers. Routers used to connect two IGP areas
(areas in OSPF or levels in IS-IS).ASBR: Autonomous System Border Router. Router used to connect
together ASes of the same or different service providers via one or more
inter-AS links.Boundary Node (BN): a boundary node is either an ABR in the context
of inter-area Traffic Engineering or an ASBR in the context of inter-AS
Traffic Engineering.Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along
a determined sequence of domains.Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along
a determined sequence of domains.Inter-area TE LSP: A TE LSP that crosses an IGP area boundary.Inter-AS TE LSP: A TE LSP that crosses an AS boundary.LSP: Label Switched Path.LSR: Label Switching Router.PCC: Path Computation Client. Any client application requesting a
path computation to be performed by a Path Computation Element.PCE: Path Computation Element. An entity (component, application, or
network node) that is capable of computing a network path or route based
on a network graph and applying computational constraints.PCE(i) is a PCE with the scope of domain(i).TED: Traffic Engineering Database.VSPT: Virtual Shortest Path Tree.The notion of contiguous, stitched, and nested TE LSPs is defined in
and will not be repeated here.In the rest of this document, we make the following set of
assumptions common to inter-area and inter-AS MPLS TE:Each IGP area or Autonomous System (AS) is assumed to be Traffic
Engineering enabled.No topology or resource information is distributed between
domains (as mandated per and ), which is critical to preserve IGP/BGP
scalability and confidentiality.While certain constraints like bandwidth can be used across
different domains, other TE constraints (such as resource affinity,
color, metric, etc. )
could be translated at domain boundaries. If required, it is assumed
that, at the domain boundary nodes, there will exist some sort of
local mapping based on policy agreement, in order to translate such
constraints across domain boundaries during the inter-PCE
communication process.Each AS can be made of several IGP areas. The path computation
procedure described in this document applies to the case of a single
AS made of multiple IGP areas, multiple ASes made of a single IGP
area, or any combination of the above. For the sake of simplicity,
each AS will be considered to be made of a single area in this
document. The case of an inter-AS TE LSP spanning multiple ASes,
where some of those ASes are themselves made of multiple IGP areas,
can be easily derived from this case by applying the BRPC procedure
described in this document, recursively.The domain path (the set of domains traversed to reach the
destination domain) is either administratively predetermined or
discovered by some means that is outside of the scope of this
document.The BRPC procedure is a multiple-PCE path computation technique as
described in . A possible model consists
of hosting the PCE function on boundary nodes (e.g., ABR or ASBR), but
this is not mandated by the BRPC procedure.The BRPC procedure relies on communication between cooperating PCEs.
In particular, the PCC sends a PCReq to a PCE in its domain. The request
is forwarded between PCEs, domain-by-domain, until the PCE responsible
for the domain containing the LSP destination is reached. The PCE in the
destination domain creates a tree of potential paths to the destination
(the Virtual Shortest Path Tree - VSPT) and passes this back to the
previous PCE in a PCRep. Each PCE in turn adds to the VSPT and passes it
back until the PCE in the source domain uses the VSPT to select an
end-to-end path that the PCE sends to the PCC.The BRPC procedure does not make any assumption with regards to the
nature of the inter-domain TE LSP that could be contiguous, nested, or
stitched.Furthermore, no assumption is made on the actual path computation
algorithm in use by a PCE (e.g., it can be any variant of Constrained Shortest Path First (CSPF) or an
algorithm based on linear programming to solve multi-constraint
optimization problems).The PCE-based BRPC procedure applies to the computation of an
optimal constrained inter-domain TE LSP. The sequence of domains to be
traversed is either administratively predetermined or discovered by
some means that is outside of the scope of this document. The PCC MAY
indicate the sequence of domains to be traversed using the
Include Route Object (IRO) defined
in so that it is available to
all PCEs. Note also that a sequence of PCEs MAY be enforced by policy
on the PCC, and this constraint can be carried in the PCEP path
computation request (as defined in ).The BRPC procedure guarantees to compute the optimal path across a
specific sequence of traversed domains (which constitutes an
additional constraint). In the case of an arbitrary set of meshed
domains, the BRPC procedure can be used to compute the optimal path
across each domain set in order to get the optimal constrained path
between the source and the destination of the TE LSP. The BRPC
procedure can also be used across a subset of all domain sequences,
and the best path among these sequences can then be selected.Definition of VSPT(i)In each domain i:There is a set of X-en(i) entry BNs noted BN-en(k,i) where
BN&nbhy;en(k,i) is the kth entry BN of domain(i).There is a set of X-ex(i) exit BNs noted BN-ex(k,i) where
BN&nbhy;ex(k,i) is the kth exit BN of domain(i).
Each link of tree VSPT(i) represents the shortest
constrained path between BN-en(j,i) and the TE LSP destination that
satisfies the set of required constraints for the TE LSP (bandwidth,
affinities, etc.). These are path segments to reach the TE LSP
destination from BN&nbhy;en(j,i).Note that PCE(i) only considers the entry BNs of domain(i), i.e.,
only the BNs that provide connectivity from domain(i-1). In
other words, the
set BN-en(k,i) is only made of those BNs that provide connectivity
from domain (i-1) to domain(i). Furthermore, some BNs may be excluded
according to policy constraints (either due to local policy or
policies signaled in the path computation request).Step 1:
First, the PCC needs to determine the PCE capable of serving
its path computation request (this can be done with local
configuration or via IGP discovery (see
and )). The path computation request is
then relayed until reaching a PCE(n) such that the TE LSP destination
resides in the domain(n). At each step of the process, the next PCE
can either be statically configured or dynamically discovered via
IGP/BGP extensions. If no next PCE can be found or the next-hop PCE of
choice is unavailable, the procedure stops and a path computation
error is returned (see ). If PCE(i-1)
discovers multiple PCEs for the adjacent domain(i), PCE(i) may select
a subset of these PCEs based on some local policies or heuristics. The
PCE selection process is outside of the scope of this document.Step 2:
PCE(n) computes VSPT(n), the tree made of the list of shortest
constrained paths between every BN-en(j,n) and the TE LSP destination
using a suitable path computation algorithm (e.g., CSPF) and returns
the computed VSPT(n) to PCE(n-1).Step i:
For i=n-1 to 2: PCE(i) computes VSPT(i), the tree made of the
shortest constrained paths between each BN-en(j,i) and the TE LSP
destination. It does this by considering its own TED and the
information in VSPT(i+1).In the case of inter-AS TE LSP computation, this also
requires adding the inter-AS TE links that connect the domain(i) to the
domain(i+1).Step n:
Finally, PCE(1) computes the end-to-end shortest constrained path
from the source to the destination and returns the corresponding path
to the requesting PCC in the form of a PCRep message as defined in
.Each branch of the VSPT tree (path) may be returned in the form of
an explicit path (in which case, all the hops along the path segment
are listed) or a loose path (in which case, only the BN is specified)
so as to preserve confidentiality along with the respective cost. In
the latter case, various techniques can be used in order to retrieve
the computed explicit paths on a per-domain basis during the signaling
process, thanks to the use of path keys as described in .A PCE that can compute the requested path for more than one
consecutive domain on the path SHOULD perform this computation for all
such domains before passing the PCRep to the previous PCE in the
sequence.BRPC guarantees to find the optimal (shortest) constrained
inter-domain TE LSP according to a set of defined domains to be
traversed. Note that other variants of the BRPC procedure relying on
the same principles are also possible.Note also that in case of Equal Cost Multi-Path (ECMP) paths, more than one path could be
returned to the requesting PCC.The BRPC procedure requires the specification of a new flag of the RP
object carried within the PCReq message (defined in ) to specify that the shortest paths
satisfying the constraints from the destination to the set of entry
boundary nodes are requested (such a set of paths forms the downstream
VSPT as specified in ).The following new flag of the RP object is defined:When set, the VSPT Flag indicates that the PCC requests the
computation of an inter-domain TE LSP using the BRPC procedure defined
in this document.Because path segments computed by a downstream PCE in the context of
the BRPC procedure MUST be provided along with their respective path
costs, the C flag of the METRIC object carried within the PCReq message
MUST be set. It is the choice of the requester to appropriately set the
O bit of the RP object.The VSPT is returned within a PCRep message. The encoding consists of
a non-ordered list of Explicit Route Objects (EROs) where each ERO represents a path segment
from a BN to the destination specified in the END-POINT object of the
corresponding PCReq message.Example:In the simple example shown in Figure 2, if we make the assumption
that a constrained path exists between each ABR and the destination D,
the VSPT computed by a PCE serving area 2 consists of the following
non-ordered set of EROs:ERO1: ABR1(TE Router ID)-A(Interface IP address)-B(Interface IP
address)-D(TE Router ID)ERO2: ABR2(TE Router ID)-D(TE Router ID)ERO3: ABR3(TE Router ID)-C(interface IP address)-D(TE Router
ID)The PCReq message, PCRep message, PCEP END-POINT object, and ERO
object are defined in .In the case of inter-AS TE LSP path computation, the BRPC procedure
requires the knowledge of the traffic engineering attributes of the
inter-AS TE links. The process by which the PCE acquires this
information is out of the scope of the BRPC procedure, which is
compliant with the PCE architecture defined in .That said, a straightforward solution consists of allowing the ASBRs
to flood the TE information related to the inter-ASBR links although no
IGP TE is enabled over those links (there is no IGP adjacency over the
inter-ASBR links). This allows the PCE of a domain to get entire TE
visibility up to the set of entry ASBRs in the downstream domain (see
the IGP extensions defined in and ).The BRPC procedure may be used to compute path segments in
conjunction with other path computation techniques (such as the
per-domain path computation technique defined in ) to compute the end-to-end path. In this case,
end-to-end path optimality can no longer be guaranteed.If the BRPC procedure cannot be completed because a PCE along the
domain does not recognize the procedure (VSPT flag of the RP object), as
stated in , the PCE sends a
PCErr message to the upstream PCE with an Error-Type=4 (Not supported
object), Error-value=4 (Unsupported parameter). The PCE may include the
parent object (RP object) up to and including (but no further than) the
unknown or unsupported parameter. In this case where the unknown or
unsupported parameter is a bit flag (VSPT flag), the included RP object
should contain the whole bit flag field with all bits after the
parameter at issue set to zero. The corresponding path computation
request is then cancelled by the PCE without further notification.If the BRPC procedure cannot be completed because a PCE along the
domain path recognizes but does not support the procedure, it MUST
return a PCErr message to the upstream PCE with an Error-Type "BRPC
procedure completion failure".The PCErr message MUST be relayed to the requesting PCC.PCEP-ERROR objects are used to report a PCEP protocol error and are
characterized by an Error-Type that specifies the type of error and an
Error-value that provides additional information about the error type.
Both the Error-Type and the Error-value are managed by IANA. A new
Error-Type is defined that relates to the BRPC procedure.As discussed in , the requirements
for inter-area and inter-AS MPLS Traffic Engineering have been developed
by the Traffic Engineering Working Group (TE WG) and have been stated in
and ,
respectively. Among the set of requirements, both documents indicate the
need for some solution that provides the ability to compute an optimal
(shortest) constrained inter-domain TE LSP and to compute a set of
diverse inter-domain TE LSPs.PCEP (see ) allows a PCC to
request the computation of a set of diverse TE LSPs by setting
the SVEC
object's flags L, N, or S to request link, node, or SRLG
(Shared Risk Link Group)
diversity, respectively. Such requests MUST be taken into account by
each PCE along the path computation chain during the VSPT computation.
In the context of the BRPC procedure, a set of diversely routed TE
LSPs between two LSRs can be computed since the path segments of the
VSPT are simultaneously computed by a given PCE. The BRPC procedure
allows for the computation of diverse paths under various objective
functions (such as minimizing the sum of the costs of the N diverse
paths, etc.).By contrast, with a 2-step approach consisting of computing the
first path followed by computing the second path after having
removed the set of network elements traversed by the first path (if
that does not violate confidentiality preservation), one cannot
guarantee that a solution will be found even if such solution exists.
Furthermore, even if a solution is found, it may not be the most
optimal one with respect to an objective function such as minimizing
the sum of the paths' costs, bounding the path delays of both paths, and
so on. Finally, it must be noted that such a 2-step path computation
approach is usually less efficient in terms of signaling delays since
it requires that two serialized TE LSPs be set up.BRPC guarantees that the optimal (shortest) constrained
inter-domain path will always be found, subject to policy constraints.
Both in the case where local path computation techniques are
used (such as to build stitched or nested TE LSPs), and
in the case where a domain has
more than one BN-en or more than one BN-ex, it is only
possible to guarantee optimality after some
network change within the domain by completely
re-executing the BRPC procedure.The ability to reoptimize an existing inter-domain TE LSP path has
been explicitly listed as a requirement in and . In the case
of a TE LSP reoptimization request, the reoptimization procedure defined
in applies when the path in
use (if available on the head-end) is provided as part of the path
computation request so that the PCEs involved in the reoptimization
request can avoid double bandwidth accounting.If a PCE requires to relay a path computation request according to
the BRPC procedure defined in this document to a downstream PCE and no
such PCE is available, the PCE MUST send a negative path computation
reply to the requester using a PCReq message as specified in that contains a NO-PATH object. In
such case, the NO&nbhy;PATH object MUST carry a NO-PATH-VECTOR TLV (defined
in ) with the newly defined bit
named "BRPC path computation chain unavailable" set.In the case of inter-area TE, the same IGP/TE metric scheme is
usually adopted for all the IGP areas (e.g., based on the link-speed,
propagation delay, or some other combination of link attributes). Hence,
the proposed set of mechanisms always computes the shortest path across
multiple areas that obey the required set of constraints with respect to a
specified objective function. Conversely, in the case of inter-AS TE, in
order for this path computation to be meaningful, metric normalization
between ASes may be required. One solution to avoid IGP metric
modification would be for the service providers to agree on a TE metric
normalization scheme and use the TE metric for TE LSP path computation
(in that case, the use of the TE metric must be requested in the PCEP path computation
request) using the METRIC object (defined in ).This section follows the guidance of .The only configurable item is the support of the BRPC procedure on
a PCE. The support of the BRPC procedure by the PCE MAY be controlled
by a policy module governing the conditions under which a PCE should
participate in the BRPC procedure (origin of the requests, number of
requests per second, etc.). If the BRPC is not supported/allowed on a
PCE, it MUST send a PCErr message as specified in .A BRPC MIB module will be specified in a separate document.The BRPC procedure is a multiple-PCE path computation technique and,
as such, a set of PCEs are involved in the path computation chain. If
the path computation chain is not operational either because at least
one PCE does not support the BRPC procedure or because one of the PCEs
that must be involved in the path computation chain is not available,
procedures are defined to report such failures in Sections and , respectively. Furthermore, a
built-in diagnostic tool to check the availability and performances of
a PCE chain is defined in .Verifying the correct operation of BRPC can be performed by
monitoring a set of parameters. A BRPC implementation SHOULD provide
the following parameters:Number of successful BRPC procedure completions on a per-PCE-peer
basisNumber of BRPC procedure completion failures because the VSPT
flag was not recognized (on a per-PCE-peer basis)Number of BRPC procedure completion failures because the BRPC
procedure was not supported (on a per-PCE-peer basis)The BRPC procedure does not put any new requirements on other
protocols. That said, since the BRPC procedure relies on the PCEP
protocol, there is a dependency between BRPC and PCEP; consequently,
the BRPC procedure inherently makes use of the management functions
developed for PCEP.The BRPC procedure does not have any significant impact on network
operation: indeed, BRPC is a multiple-PCE path computation scheme as
defined in and does not differ from any
other path computation request. specifies a set of
mechanisms that can be used to gather PCE state metrics. Because BRPC
is a multiple-PCE path computation technique, such mechanisms could be
advantageously used in the context of the BRPC procedure to check the
liveness of the path computation chain, locate a faulty component,
monitor the overall performance, and so on. A new flag of the RP object (specified in ) is
defined in this document. IANA maintains a registry of RP object
flags in the "RP Object Flag Field" sub-registry of the "Path
Computation Element Protocol (PCEP) Numbers" registry.IANA has allocated the following value:
IANA maintains a registry of Error-Types and Error-values for use in
PCEP messages. This is maintained as the "PCEP-ERROR Object Error
Types and Values" sub-registry of the "Path Computation Element
Protocol (PCEP) Numbers" registry.
A new Error-value is defined for the Error-Type "Not supported object" (type 4).
A new Error-Type is defined in this document as follows:
A new flag of the NO-PATH-VECTOR TLV defined in )
is specified in this document.
IANA maintains a registry of flags for the NO-PATH-VECTOR TLV in the
"NO-PATH-VECTOR TLV Flag Field" sub-registry of the "Path Computation
Element Protocol (PCEP) Numbers" registry.
IANA has allocated the following allocation value:
The BRPC procedure relies on the use of the PCEP protocol and as such
is subjected to the potential attacks listed in Section 10 of . In addition to the security
mechanisms described in with
regards to spoofing, snooping, falsification, and denial of service, an
implementation MAY support a policy module governing the conditions
under which a PCE should participate in the BRPC procedure.The BRPC procedure does not increase the information exchanged
between ASes and preserves topology confidentiality, in compliance with
and .The authors would like to thank Arthi Ayyangar, Dimitri
Papadimitriou, Siva Sivabalan, Meral Shirazipour, and Mach Chen for their
useful comments. A special thanks to Adrian Farrel for his useful
comments and suggestions.Path Computation Element (PCE) Communication Protocol (PCEP)Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based MechanismInclusion of Manageability Sections in PCE Working Group DraftsA set of monitoring tools for Path Computation Element based ArchitectureOSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering