request cannot be reported in this way. Furthermore, in the case of
excessive load, the PCE may not have sufficient resources to send a
failure message. Thus, the PCC should employ other mechanisms, such
as protocol timers, to determine the liveness of the PCE. This is
particularly important in the case of inter-domain path computation
where the PCE liveness may not be detected by means of the IGP that
runs in the PCC’s domain.
6.6. PCC-PCE and PCE-PCE Communication
Once the PCC has selected a PCE, and provided that the PCE is not
local to the PCC, a request/response protocol is required for the PCC
to communicate the path computation requests to the PCE and for the
PCE to return the path computation response. Discussion of the
security requirements and implications for this protocol is provided
in Section 10 of this document.
The path computation request may include a significant set of
requirements, including the following:
- the source and destination of the path
- the bandwidth and other Quality of Service (QoS) parameters desired
- resources, resource affinities, and shared risk link groups (SRLGs)
to use/avoid
- the number of disjoint paths required and whether near-disjoint
paths are acceptable
- the levels of resiliency, reliability, and robustness of the path
resources
- policy-related information
The level of robustness of the path resources covers a qualitative
assessment of the vulnerability of the resources that may be used.
For example, one might grade resources based on empirical evidence
(mean time between failures), on known risks (there is major building
work going on near this conduit), or on prejudice (vendor X’s
software is always crashing). A PCC could request that only robust
resources be used, or it could allow any resource.
In case of a positive response from the PCE, one or more paths would
be returned to the requesting node. In the event of a failure to
compute the desired path(s), an error is returned together with as
much information as possible about the reasons for the failure(s),
and potentially with advice about which constraints might be relaxed
so that a positive result is more likely in a future request.
Note that the resultant path(s) may be made up of a set of strict or
loose hops, or any combination of strict and loose hops. Moreover, a
hop may have the form of a non-explicit abstract node.
A request/response protocol is also required for a PCE to communicate
path computation requests to another PCE and for the PCE to return
the path computation response. The path computation request may
include a significant set of requirements including those defined
above. In case of a positive response from the PCE, one or more
paths would be returned to the requesting PCE. In the event of a
failure to compute the desired path(s), an error is returned together
with as much information as possible about the reasons for the
failure, and potentially advice about which constraints might be
relaxed so that a positive result is more likely. Note that the
resultant path(s) may be made up of a set of strict or loose hops, or
any combination of strict and loose hops. Moreover, a hop may have
the form of a non-explicit abstract node.
An important feature of PCEs that are cooperating to compute a path
is that they apply compatible or identical computation algorithms and
coordinated policies. This may require coordination through the
communication between the PCEs.
Note that when multiple PCEs cooperate to compute a path, it is
important that they have a coordinated view of the meaning of
constraints such as costs, resource affinities, and class of service.
This is particularly significant where the PCEs are responsible for
different domains. It is assumed that this is a matter of policy
between domains and between PCEs.
No assumption is made in this architecture about whether the PCC-PCE
and PCE-PCE communication protocols are identical.
6.7. PCE TED Synchronization
As previously described, the PCE operates on a TED. Information on
network status to build the TED may be provided in the domain by
various means:
1) Participation in IGP distribution of TE information. The standard
method of distribution of TE information within an IGP area is
through the use of extensions to the IGP [RFC3630, RFC3748]. This
mechanism allows participating nodes to build a TED, and this is
the standard technique, for example, within a single area MPLS or
GMPLS network. A node that hosts the PCE function may collect TE
information in this way by maintaining at least one routing
adjacency with a router in the domain. The PCE node may be
adjacent or non-adjacent (via some tunneling techniques) to the
router. Such a technique provides a mechanism for ensuring that
the TED is efficiently synchronized with the network state and is
the normal case, for example, when the PCE is co-resident with the
LSRs in an MPLS or GMPLS network.
2) Out-of-band TED synchronization. It may not be convenient or
possible for a PCE to participate in the IGPs of one or more
domains (for example, when there are very many domains, when IGP
participation is not desired, or when some domains are not running
TE-aware IGPs). In this case, some mechanism may need to be
defined to allow the PCE node to retrieve the TED from each
domain. Such a mechanism could be incremental (like the IGP in
the previous case), or it could involve a bulk transfer of the
complete TED. The latter might significantly limit the capability
to ensure TED synchronization, which might result in an increase
in the failure rate of computed paths, or the computation of sub-
optimal paths. Consideration should also be given to the impact
of the TED distribution on the network and on the network node
within the domain that is asked to distribute the database. This
is particularly relevant in the case of frequent network state
changes.
3) Information in the TED can include information obtained from
sources other than the IGP. For example, information about link
usage policies can be configured by the operator. Path
computation can also act on a far wider set of information that
includes data about the TE LSPs provisioned within the network.
This information can include TE LSP routes, reserved bandwidth,
and measured traffic volume passing through the TE LSP.
Such TE LSP information can enhance TE LSP (re)optimization to
provide "full network" (re)optimization and can allow traffic
fluctuations to be taken into account. Detailed TE LSP
information may also facilitate reconfiguration of the Virtual
Network Topology (VNT) [MLN], in which lower-layer TE LSPs, such
as optical paths, provide TE links for use by the higher layer,
since this reconfiguration is also a "full network" problem.
Note that synchronization techniques may apply to both intra- and
inter-domain TEDs. Furthermore, the techniques can be mixed for use
in different domains. The degree of synchronization between the PCE
and the network is subject to implementation and/or policy. However,
better synchronization generally leads to paths that are more likely
to succeed.
Note also that the PCE may have access to only a partial TED: for
instance, in the case of inter-domain path computation where each
such domain may be managed by different entities. In such cases,
each PCE may have access to a partial TED, and cooperative techniques
between PCEs may be used to achieve end-to-end path computation
without any requirement that any PCE handle the complete TED related
to the set of traversed domains by the TE LSP in question.
6.8. Stateful versus Stateless PCEs
A PCE can be either stateful or stateless. In the former case, there
is a strict synchronization between the PCE and not only the network
states (in term of topology and resource information), but also the
set of computed paths and reserved resources in use in the network.
In other words, the PCE utilizes information from the TED as well as
information about existing paths (for example, TE LSPs) in the
network when processing new requests. Note that although this allows
for optimal path computation and increased path computation success,
stateful PCEs require reliable state synchronization mechanisms, with
potentially significant control plane overhead and the maintenance of
a large amount of data/states (for example, full mesh of TE LSPs).
For example, if there is only one PCE in the domain, all TE LSP
computation is done by this PCE, which can then track all the
existing TE LSPs and stay synchronized (each TE LSP state change must
be tracked by the PCE). However, this model could require
substantial control plane resources. If there are multiple PCEs in
the network, TE LSP computation and information are distributed among
PCEs and so the resources required to perform the computations are
also distributed. However, synchronization issues discussed in
Section 6.7 also come into play.
The maintenance of a stateful database can be non-trivial. However,
in a single centralized PCE environment, a stateful PCE is almost a
simple matter of remembering all the TE LSPs the PCE has computed,
that the TE LSPs were actually set up (if this can be known), and
when they were torn down. Out-of-band TED synchronization can also
be complex, with multiple PCE setup in a distributed PCE computation
model, and could be prone to race conditions, scalability concerns,
etc. Even if the PCE has detailed information on all paths,
priorities, and layers, taking such information into account for path
computation could be highly complex. PCEs might synchronize state by
communicating with each other, but when TE LSPs are set up using
distributed computation performed among several PCEs, the problems of
synchronization and race condition avoidance become larger and more
complex.
There is benefit in knowing which TE LSPs exist, and their routing,
to support such applications as placing a high-priority TE LSP in a
crowded network such that it preempts as few other TE LSPs as
possible (also known as the "minimal perturbation" problem). Note
that preempting based on the minimum number of links might not result
in the smallest number of TE LSPs being disrupted. Another
application concerns the construction and maintenance of a Virtual
Network Topology [MLN]. It is also helpful to understand which other
TE LSPs exist in the network in order to decide how to manage the
forward adjacencies that exist or need to be set up. The cost-
benefit of stateful PCE computation would be helpful to determine if
the benefit in path computation is sufficient to offset the
additional drain on the network and computational resources.
Conversely, stateless PCEs do not have to remember any computed path
and each set of request(s) is processed independently of each other.
For example, stateless PCEs may compute paths based on current TED
information, which could be out of sync with actual network state
given other recent PCE-computed paths changes. Note that a PCC may
include a set of previously computed paths in its request, in order
to take them into account, for instance, to avoid double bandwidth
accounting or to try to minimize changes (minimum perturbation
problem).
Note that the stateless PCE does operate on information about network
state. The TED contains link state and bandwidth availability
information as distributed by the IGPs or collected through some
other means. This information could be further enhanced to provide
increased granularity and more detail to cover, for example, the
current bandwidth usage on certain links according to resource
affinities or forwarding equivalence classes. Such information is,
however, not PCE state information and so a model that uses it is
still described as stateless in the PCE context.
A limited form of statefulness might be applied within an otherwise
stateless PCE. The PCE may retain some context from paths it has
recently computed so that it avoids suggesting the use of the same
resources for other TE LSPs.
6.9. Monitoring
PCE monitoring is undoubtedly of the utmost importance in any PCE
architecture. This must include the collection of variables related
to the PCE status and operation. For example, it will be necessary
to understand the way in which the TED is being kept synchronized,
the rate of arrival of new requests and the computation times, the
range of PCCs that are using the PCE, and the operation of any PCC-
PCE protocol.
6.10. Confidentiality
As stated in [RFC4216], the case of inter-provider TE LSP computation
requires the ability to compute a path while preserving
confidentiality across multiple Service Providers cores. That is,
one Service Provider must not be required to divulge any information
about its resources or topology in order to support inter-provider TE
LSP path computation. Thus, any PCE architecture solution must
support the ability to return partial paths by means of loose hops
(for example, where each loose hop would, for instance, identify a
boundary LSR).
This requirement is not a security issue, but relates to Service
Provider policy. Confidentiality, integrity, and authentication of
PCC-PCE and PCE-PCE messages must also be ensured and are described
in Section 10.
The ability to compute a path at the request of the head-end PCC, but
to supply the path in segments to the domain boundary PCCs, may also
be desirable.
6.11. Policy
Policy impacts multiple aspects of the PCE architecture. There are
two applications of policy for consideration:
- application of policy within an architectural entity (PCC or PCE)
- application of policy to PCE-related communications
As directly applicable to TE LSPs, policy forms part of the signaling
mechanism for the establishment of the TE LSPs and is not described
here.
It is envisioned that policy will be largely applied as a local
matter within each PCC and PCE. However, this document needs to
define policy models that can be supported within the PCE
architecture and by PCE-related communication.
Some example policies include:
- selection of a PCE by a PCC
- rejection of a request by the PCE based on the identity of the
requesting PCC
- selection by the PCE of a path or application of additional
constraints to a computation based on the PCC, the computation
target, the time of day, etc.
6.11.1. PCE Policy Architecture
Two examples of the use of policy components within the PCE
architecture are illustrated in Figures 6 and 7. Policy components
could equally be applied to the other PCE configurations shown in
Section 5. In each configuration, policy may be consulted before a
response is provided by a PCE and may also be consulted by the
PCC/PCE that receives the response.
A PCE may have a local policy that impacts the paths selected to
satisfy a particular PCE request. A policy may be applied based on
any information provided from a PCC.
In Figure 6, the policy component is shown providing input to the PCE
component. This policy component may consult an external policy
database, but this is outside the scope of this document.
------------------------------
| --------- | Routing ----------
| | | | Protocol | |
| | TED |<-+----------+-> |
| | | | | |
| --------- | | |
| | | | |
| | Input | | |
| v | | |
| --------- --------- | | |
| | Policy | | | | | Adjacent |
| |Component|--->| PCE | | | Node |
| | | | | | | |
| --------- --------- | | |
| ^ | | |
| |Request | | |
| |Response| | |
| v | | |
| --------- | | |
Service | | | | Signaling| |
Request | |Signaling| | Protocol | |
------+---------------->| Engine |<-+----------+-> |
| | | | | |
| --------- | ----------
------------------------------
Figure 6. Policy Component in the Composite PCE Node
Note that policy information may be conveyed on the internal
interfaces, and on the external protocol interfaces.
Figure 7 displays the case of a distinct PCE function through the
example of the multiple PCE with inter-PCE communication example
(compare with Figure 4). Each PCE takes input from local policy as
part of the router computation/determination process. The local
policy components may consult external policy components or
databases, but that is out of the scope of this document.
Note that policy information may be conveyed on the external protocol
interfaces, including the inter-PCE interface.
------------------ ------------------
| | Inter-PCE Request/Response| |
| PCE |<------------------------->| PCE |
| | | |
| ------ ----- | | ------ ----- |
| |Policy| | TED | | | |Policy| | TED | |
| ------ ----- | | ------ ----- |
------------------ ------------------
^
| Request/
| Response
v
Service ---------- Signaling ---------- Signaling ----------
Request| Head-End | Protocol | Adjacent | Protocol | Adjacent |
---->| Node |<---------->| Node |<---------->| Node |
---------- ---------- ----------
Figure 7. Policy Components in Multiple PCEs
6.11.2. Policy Realization
There are multiple options for how policy information is coordinated.
- Policy decisions may be made by PCCs before consulting PCEs. This
type of decision includes selection of PCE, application of
constraints, and interpretation of service requests.
- Policy decisions may be made independently at a PCE, or at each
cooperating PCE. That is, the PCE(s) may make policy decisions
independent of other policy decisions made at PCCs or other PCEs.
- There may also be explicit communication of policy information
between PCC and PCE, or between PCEs to achieve some level of
coordination of policy between entities. The type of information
conveyed to support policy has important implications on what
policies may be applied at each PCE, and the requirements for the
exchange of policy information inform the choice or implementation
of communication protocols including PCC-PCE, PCE-PCE, and
discovery protocols.
6.11.3. Type of Policies
Within the context of PCE, we identify several types of policies:
o User-specific policies operate on information that is specific to
the user of a service or the service itself, that is, the service
for which the path is being computed, not the computation service.
Examples of such information includes the contents of objects of a
signaling or provisioning message, the port ID over which the
message was received, a VPN ID, a reference point type, or the
identity of the user initiating the request. User-specific
policies could be applied by a PCC while building a path
computation request, or by a PCE while processing the request
provided that sufficient information is supplied by the PCC to the
PCE.
o Request-specific policies operate on information that is specific
to a path computation request and is carried in the request.
Examples of such information include constraints, diversities,
constraint and diversity relaxation strategies, and optimization
functions. Request-specific policies directly affect the path
selection process because they specify which links, nodes, path
segments, and/or paths are not acceptable or, on the contrary, may
be desirable in the resulting paths.
o Domain-specific policies operate on the identify of the domain in
which the requesting PCC exists, and upon the identities of the
domains through which the resulting paths are routed. These
policies have the same effect as user-specific policies, with the