(that is, a router that also implements the PCE functionality) that
utilizes path computation. The routing protocol is used to exchange
TE information from which the TED is constructed. Service requests
to provision TE LSPs are received by the node and converted into
signaling requests, but this conversion may require path computation
that is requested from a PCE. The PCE operates on the TED subject to
local policy in order to respond with the requested path.
---------------
| --------- | Routing ----------
| | | | Protocol | |
| | TED |<-+----------+-> |
| | | | | |
| --------- | | |
| | | | |
| | Input | | |
| v | | |
| --------- | | |
| | | | | Adjacent |
| | PCE | | | Node |
| | | | | |
| --------- | | |
| ^ | | |
| |Request | | |
| |Response| | |
| v | | |
| --------- | | |
Service | | | | Signaling| |
Request | |Signaling| | Protocol | |
------+->| Engine |<-+----------+-> |
| | | | | |
| --------- | ----------
---------------
Figure 1. Composite PCE Node
Note that the routing adjacency between the composite PCE node and
any other router may be performed by means of direct connectivity or
any tunneling mechanism.
5.2. External PCE
Figure 2 shows a PCE that is external to the requesting network
element. A service request is received by the head-end node, and
before it can initiate signaling to establish the service, it makes a
path computation request to the external PCE. The PCE uses the TED
subject to local policy as input to the computation and returns a
response.
----------
| ----- |
| | TED |<-+----------->
| ----- | TED synchronization
| | | mechanism (for example, routing protocol)
| | |
| v |
| ----- |
| | PCE | |
| ----- |
----------
^
| Request/
| Response
v
Service ---------- Signaling ----------
Request | Head-End | Protocol | Adjacent |
---->| Node |<---------->| Node |
---------- ----------
Figure 2. External PCE Node
Note that in this case, the node that supports the PCE function may
also be an LSR or router performing forwarding in its own right
(i.e., it may be a composite PCE node), but those functions are
purely orthogonal to the operation of the function in the instance
being considered here.
5.3. Multiple PCE Path Computation
Figure 3 illustrates how multiple PCE path computations may be
performed along the path of a signaled service. As in the previous
example, the head-end PCC makes a request to an external PCE, but the
path that is returned is such that the next network element finds it
necessary to perform further computation. This may be the case when
the path returned is a partial path that does not reach the intended
destination or when the computed path is loose. The downstream
network element consults another PCE to establish the next hop(s) in
the path. In this case, all policy decisions are made independently
at each PCE based on information passed from the PCC.
Note that either or both PCEs in this case could be composite PCE
nodes, as in Section 5.1.
---------- ----------
| | | |
| PCE | | PCE |
| | | |
| ----- | | ----- |
| | TED | | | | TED | |
| ----- | | ----- |
---------- ----------
^ ^
| Request/ | Request/
| Response | Response
v v
Service -------- Signaling ------------ Signaling ------------
Request |Head-End| Protocol |Intermediate| Protocol |Intermediate|
---->| Node |<--------->| Node |<--------->| Node |
-------- ------------ ------------
Figure 3. Multiple PCE Path Computation
5.4. Multiple PCE Path Computation with Inter-PCE Communication
The PCE in Section 5.3 was not able to supply a full path for the
requested service, and as a result the adjacent node needs to make
its own computation request. As illustrated in Figure 4, the same
problem may be solved by introducing inter-PCE communication, and
cooperation between PCEs so that the PCE consulted by the head-end
network node makes a request of another PCE to help with the
computation.
---------- ----------
| | Inter-PCE Request/Response | |
| PCE |<--------------------------------->| PCE |
| | | |
| ----- | | ----- |
| | TED | | | | TED | |
| ----- | | ----- |
---------- ----------
^
| Request/
| Response
v
Service ---------- Signaling ---------- Signaling ----------
Request | Head-End | Protocol | Adjacent | Protocol | Adjacent |
---->| Node |<---------->| Node |<---------->| Node |
---------- ---------- ----------
Figure 4. Multiple PCE Path Computation with Inter-PCE Communication
Multiple PCE path computation with inter-PCE communication involves
coordination between distinct PCEs such that the result of the
computation performed by one PCE depends on path fragment information
supplied by other PCEs. This model does not provide a distributed
computation algorithm, but it allows distinct PCEs to be responsible
for computation of parts (segments) of the path.
PCE-PCE communication is discussed further in Section 6.6.
Note that a PCC might not see the difference between centralized
computation and multiple PCE path computation with inter-PCE
communication. That is, the PCC network node or component that
requests the computation makes a single request and receives a full
or partial path in response, but the response is actually achieved
through the coordinated, cooperative efforts of more than one PCE.
In this model, all policy decisions may be made independently at each
PCE based on computation information passed from the previous PCE.
Alternatively, there may be explicit communication of policy
information between PCEs.
5.5. Management-Based PCE Usage
It must be observed that the PCC is not necessarily an LSR. For
example, in Figure 5 the NMS supplies the head-end LSR with a fully
computed explicit path for the TE LSP that it is to establish through
signaling. The NMS uses a management plane mechanism to send this
request and encodes the data using a representation such as the TE
MIB module [RFC3812].
The NMS constructs the explicit path that it supplies to the head-end
LSR using information provided by the operator. It consults the PCE,
which returns a path for the NMS to use.
Although Figure 5 shows the PCE as remote from the NMS, it could, of
course, be collocated with the NMS.
-----------
| ----- |
Service | | TED |<-+----------->
Request | ----- | TED synchronization
| | | | mechanism (for example,
v | | | routing protocol)
------------- Request/ | v |
| | Response| ----- |
| NMS |<--------+> | PCE | |
| | | ----- |
------------- -----------
Service |
Request |
v
---------- Signaling ----------
| Head-End | Protocol | Adjacent |
| Node |<---------->| Node |
---------- ----------
Figure 5. Management-Based PCE Usage
5.6. Areas for Standardization
The following areas require standardization within the PCE
architecture.
- communication between PCCs and PCEs, and between cooperating PCEs,
including the communication of policy-related information
- requirements for extending existing routing and signaling protocols
in support of PCE discovery and signaling of inter-domain paths
- definition of metrics to evaluate path quality, scalability,
responsiveness, robustness, and policy support of path computation
models.
- MIB modules related to communication protocols, routing and
signaling extensions, metrics, and PCE monitoring information
6. PCE Architectural Considerations
This section provides a list of the PCE architectural components.
Specific realizations and implementation details (state machines or
algorithms, etc.) of PCE-based solutions are out of the scope of this
document.
Note also that PCE-based path computation does not affect in any way
the use of the computed paths. For example, the use of PCE does not
change the way in which Traffic Engineering LSPs are signaled,
maintained, and torn down, but it strictly relates to the path
computation aspects of such TE LSPs.
This section presents an architectural view of PCE. That is, it
describes the components that exist and how they interact. Note that
the architectural model, and in particular the functional model, may
be perceived differently by different components of the PCE system.
For example, the PCC will not be aware of whether a PCE consults
other PCEs. The PCC view of the PCE architecture is discussed in
Section 7.
6.1. Centralized Computation Model
A "centralized computation model" considers that all path
computations for a given domain will be performed by a single,
centralized PCE. This may be a dedicated server (for example, an
external PCE node), or a designated router (for example, a composite
PCE node) in the network. In this model, all PCCs in the domain
would send their path computation requests to the central PCE. While
a domain in this context might be an IGP area or AS, it might also be
a sub-group of network nodes that is defined by its dependence on the
PCE.
This model has a single point of failure: the PCE. In order to avoid
this issue, the centralized computation model may designate a backup
PCE that can take over the computation responsibility in a controlled
manner in the event of a failure of the primary PCE. Any policies
present on the primary PCE should also be present on the backup,
although the primary policies may themselves be subject to policy
governing how they are implemented on the backup. Note that at any
moment in time there is only one active PCE in any domain.
6.2. Distributed Computation Model
A "distributed computation model" refers to a domain or network that
may include multiple PCEs, and where computation of paths is shared
among the PCEs. A given path may in turn be computed by a single PCE
("single PCE path computation") or multiple PCEs ("multiple PCE path
computation"). A PCC may be linked to a particular PCE or may be
able to choose freely among several PCEs; the method of choice
between PCEs is out of scope of this document, but see Section 6.4
for a discussion of PCE discovery that affects this choice.
Implementation of policy should be consistent across the set of
available PCEs.
Often, the computation of an individual path is performed entirely by
a single PCE. For example, this is usually the case in MPLS TE
within a single IGP area where the ingress LSR/composite PCE node is
responsible for computing the path or for contacting an external PCE.
Conversely, multiple PCE path computation implies that more than one
PCE is involved in the computation of a single path. An example of
this is where loose hop expansion is performed by transit
LSRs/composite PCE nodes on an MPLS TE LSP. Another example is the
use of multiple cooperating PCEs to compute the path of a single TE
LSP across multiple domains.
6.3. Synchronization
Often, multiple paths need to be computed to support a single service
(for example, for protection or load sharing). A PCC that determines
that it requires more than one path to be computed may send a series
of individual requests to the PCE. In this case of non-synchronized
path computation requests, the PCE may make multiple individual path
computations to generate the paths, and the PCC may send its
individual requests to different PCEs.
Alternatively, the PCC may send a single request to a PCE asking for
a set of paths to be computed, but specifying that non-synchronized
path computation is acceptable. The PCE may compute each path in
turn exactly as it would have done had the PCC made multiple
requests, and the PCE may devolve some computations to other PCEs if
it chooses. On the other hand, the PCE is not prohibited from
performing all computations together in a synchronized manner as
described below.
The PCC may also issue a single request to the PCE asking for all the
paths to be computed in a synchronized manner. The PCE will then
perform simultaneous computation of the set of requested paths. Such
synchronized computation can often provide better results.
The involvement of more than one PCE in the computation of a series
of paths is by its nature non-synchronized. However, a set of
cooperating PCEs may be synchronized under the control of a single
PCE. For example, a PCC may send a request to a PCE that invokes
domain-specific computations by other PCEs before supplying a result
to the PCC.
It is desirable to add a parameter to the PCC-PCE protocol to request
that the PCE supply a set of alternate paths for use by the PCC,
should the establishment of the TE LSP using the principal path fail
to complete. While alternate paths may not always be successful if
the first path fails, including alternate paths in a PCE response
could have less overhead than having the PCC make separate requests
for subsequent path computations as the need arises. This technique
is used in some existing CSPF implementations.
6.4. PCE Discovery and Load Balancing
In order that a PCC can communicate efficiently with a PCE, it must
know the location of the PCE. That is, it is an architectural
decision made here that PCC requests be targeted to a specific PCE,
and not broadcast to the network for any PCE to respond. This
decision means that only the selected PCE will operate on any single
request, and it saves network resources during request propagation
and processing resources at the PCEs that are not required to
respond.
The knowledge of the location of a PCE may be achieved through local
configuration at the PCC or may rely on a protocol-based discovery
mechanism that may be governed by policy.
Where more than one PCE is known to a PCC, the PCC must have
sufficient information to select an appropriate PCE for its purposes,
under the control of policy. Such a selection procedure allows for
load sharing between PCEs and supports PCEs with different
computation capabilities including different visibility scopes.
Thus, the information available to the PCC must include details of
the PCE capabilities, which may be fixed or may vary dynamically in
time.
The PCC may learn PCE capabilities through static configuration, or
it may discover the information dynamically. Note that even when the
location of the PCE is configured at the PCC, the PCC may still
discover the PCE capabilities dynamically. Dynamic PCE capabilities
cannot be configured and can only be discovered.
Proxy PCE advertisement whereby the existence of a PCE is advertised
via a proxy PCE is a viable alternative, should the PCE be incapable
of such advertisement itself. In this case, it is a requirement that
the proxy adequately advertise the PCE status and capability in a
timely and synchronized fashion.
In the event that multiple PCEs are available to serve a particular
path computation request, the PCC must select a PCE to satisfy the
request. The details of such a selection (for instance, to
efficiently share the computation load across multiple PCEs or to
request secondary computations after partial or failed computations)
are local to the PCC, may be based on policy, and are out of the
scope of this document.
PCE capabilities that may be advertised or configured could include
(and are not be limited to):
- a set of constraints that it can account for (diversity, shared
risk link groups (SRLGs), optical impairments, wavelength
continuity, etc.)
- computational capacity (for example, the number of computations it
can perform per second)
- the number of switching capability layers (and which ones)
- the number of path selection criteria (and which ones)
- whether it is a stateless PCE or it can send updates about better
paths that might be available in the future
- whether it can compute P2MP trees (and which types)
- whether it can ensure resource sharing between backup tunnels
This information would help a PCC to decide which PCE to use.
Requirements for PCE advertisement will be documented separately.
Note that there is no restriction within the architecture about how
location and capabilities are advertised, and the two elements should
be considered functionally distinct.
A PCC might also ask a PCE to perform a particular type of service
without knowledge of the PCE’s capabilities and receive a response
that says that the PCE is unable to perform the service. The
response could specify the capabilities of the PCE and might also
suggest another PCE that has the requested capabilities.
6.5. Detecting PCE Liveness
The ability to detect a PCE’s liveness is a mandatory piece of the
overall architecture and could be achieved by several means. If some
form of regular advertisement (such as through IGP extensions) is
used for PCE discovery, it is expected that the PCE liveness will be
determined by means of status advertisement (for example, IGP
LSA/LSPs).
The inability of a PCE to service a request (perhaps due to excessive
load) may be reported to the PCC through a failure message, but the
failure of a PCE or the communications mechanism while processing a