Computing paths across large multi-domain environments may require special computational components and cooperation between entities in different domains capable of complex path computation.
Issues that may exist when routing in multi-domain networks include the following:
There is often a lack of full topology and TE information across domains.
No single node has the full visibility to determine an optimal or even feasible end-to-end path across domains.
Knowing how to evaluate and select the exit point and next domain boundary from a domain.
Understanding how the ingress node determines which domains should be used for the end-to-end path.
An information exchange across multiple domains is often limited due to the lack of trust relationship, security issues, or scalability issues, even if there is a trust relationship between domains.
The Path Computation Element (PCE) [RFC 4655
] provides an architecture and a set of functional components to address the problem space and the issues highlighted above.
A PCE may be used to compute end-to-end paths across multi-domain environments using a per-domain path computation technique [RFC 5152
]. The so-called backward recursive PCE-based computation (BRPC) mechanism [RFC 5441
] defines a path computation procedure to compute inter-domain constrained Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic-Engineered (TE) networks. However, both per-domain and BRPC techniques assume that the sequence of domains to be crossed from source to destination is known, either fixed by the network operator or obtained by other means.
In more advanced deployments (including multi-area and multi-Autonomous System (multi-AS) environments), the sequence of domains may not be known in advance, and the choice of domains in the end-to-end domain sequence might be critical to the determination of an optimal end-to-end path. In this case, the use of the hierarchical PCE [RFC 6805
] architecture and mechanisms may be used to discover the intra-area path and select the optimal end-to-end domain sequence.
This document describes the processes and procedures available when using the PCE architecture and protocols for computing inter-area and inter-AS MPLS and GMPLS Traffic-Engineered paths.
The scope of this document does not include discussions of deployment scenarios for stateful PCE, active PCE, remotely initiated PCE, or PCE as a central controller (PCECC).
Generally, a domain can be defined as a separate administrative, geographic, or switching environment within the network. A domain may be further defined as a zone of routing or computational ability. Under these definitions, a domain might be categorized as an Autonomous System (AS) or an Interior Gateway Protocol (IGP) area (as per [RFC 4726
] and [RFC 4655
For the purposes of this document, a domain is considered to be a collection of network elements within an area or AS that has a common sphere of address management or path computational responsibility. Wholly or partially overlapping domains are not within the scope of this document.
In the context of GMPLS, a particularly important example of a domain is the Automatically Switched Optical Network (ASON) subnetwork [G-8080
]. In this case, computation of an end-to-end path requires the selection of nodes and links within a parent domain where some nodes may, in fact, be subnetworks. Furthermore, a domain might be an ASON routing area [G-7715
]. A PCE may perform the path computation function of an ASON Routing Controller as described in [G-7715-2
It is assumed that the PCE architecture is not applied to a large group of domains, such as the Internet.
For the purpose of this document, it is assumed that path computation is the sole responsibility of the PCE as per the architecture defined in [RFC 4655
]. When a path is required, the Path Computation Client (PCC) will send a request to the PCE. The PCE will apply the required constraints, compute a path, and return a response to the PCC. In the context of this document, it may be necessary for the PCE to cooperate with other PCEs in adjacent domains (as per BRPC [RFC 5441
]) or with a parent PCE (as per [RFC 6805
It is entirely feasible that an operator could compute a path across multiple domains without the use of a PCE if the relevant domain information is available to the network planner or network management platform. The definition of what relevant information is required to perform this network planning operation and how that information is discovered and applied is outside the scope of this document.
As highlighted, the PCE is an entity capable of computing an inter-domain TE path upon receiving a request from a PCC. There could be a single PCE per domain or a single PCE responsible for all domains. A PCE may or may not reside on the same node as the requesting PCC. A path may be computed by either a single PCE node or a set of distributed PCE nodes that collaborate during path computation.
According to [RFC 4655
], a PCC should send a path computation request to a particular PCE using [RFC 5440
] (PCC-to-PCE communication). This negates the need to broadcast a request to all the PCEs. Each PCC can maintain information about the computation capabilities of the PCEs it is aware of. The PCC-PCE capability awareness can be configured using static configurations or by automatic and dynamic PCE discovery procedures.
If a network path is required, the PCC will send a path computation request to the PCE. A PCE may then compute the end-to-end path if it is aware of the topology and TE information required to compute the entire path. If the PCE is unable to compute the entire path, the PCE architecture provides cooperative PCE mechanisms for the resolution of path computation requests when an individual PCE does not have sufficient TE visibility.
End-to-end path segments may be kept confidential through the application of Path-Keys to protect partial or full path information. A Path-Key is a token that replaces a path segment in an explicit route. The Path-Key mechanism is described in [RFC 5520
Networks are often constructed from multiple areas or ASes that are interconnected via multiple interconnect points. To maintain network confidentiality and scalability, the TE properties of each area and AS are not generally advertised outside each specific area or AS.
TE aggregation or abstraction provide a mechanism to hide information but may cause failed path setups or the selection of suboptimal end- to-end paths [RFC 4726
]. The aggregation process may also have significant scaling issues for networks with many possible routes and multiple TE metrics. Flooding TE information breaks confidentiality and does not scale in the routing protocol.
The PCE architecture and associated mechanisms provide a solution to avoid the use of TE aggregation and abstraction.
This document highlights the PCE techniques and mechanisms that exist for establishing TE packet and optical Label Switched Paths (LSPs) across multiple areas (inter-area TE LSP) and ASes (inter-AS TE LSP). In this context and within the remainder of this document, we consider all LSPs to be constraint based and traffic engineered.
Three signaling options are defined for setting up an inter-area or inter-AS LSP [RFC 4726
All three signaling methods are applicable to the architectures and procedures discussed in this document.
When using a PCE-based approach for inter-area and inter-AS path computation, a PCE in one area or AS may need to learn information related to inter-AS-capable PCEs located in other ASes. The PCE discovery mechanism defined in [RFC 5088
] and [RFC 5089
] facilitates the discovery of PCEs and disclosure of information related to inter-area and inter-AS-capable PCEs.
An Objective Function (OF) [RFC 5541
] or a set of OFs specifies the intentions of the path computation and so defines the "optimality" in the context of the computation request.
An OF specifies the desired outcome of a computation. It does not describe or specify the algorithm to use. Also, an implementation may apply any algorithm or set of algorithms to achieve the result indicated by the OF. A number of general OFs are specified in [RFC 5541
Various OFs may be included in the PCE computation request to satisfy the policies encoded or configured at the PCC, and a PCE may be subject to policy in determining whether it meets the OFs included in the computation request or whether it applies its own OFs.
During inter-domain path computation, the selection of a domain sequence, the computation of each (per-domain) path fragment, and the determination of the end-to-end path may each be subject to different OFs and policies.