difference that they can be applied to a group of users rather than
an individual user. One example of domain-specific policy is a
restriction on what information a PCE publishes within a given
domain. In such a case, PCEs in some domains may advertise just
their presence, while others may advertise details regarding their
capabilities, client authentication process, and computation
resource availability.
6.11.4. Relationship to Signaling
When a path for an inter-domain TE LSP is being computed, it is not
required to consider signaling plane policy. However, failure to do
so may result in the TE LSP failing to be established, or being
assigned fewer resources than intended resulting in a substandard
service. Thus, where a PCE invoked by a head-end LSR has visibility
into other domains, it should be capable of applying policy
considerations to the computation and should be aware of the inter-
domain policy agreements. Where path computation is the result of
cooperation between PCEs, each of which is responsible for a
particular domain, the policy issues should, where possible, be
resolved at the time of computation so that the TE LSP is more likely
to be signaled successfully. In this context, policy violation
during inter-domain TE LSP computation may lead to path computation
interruption, about which the requester should be notified along with
the cause.
6.12. Unsolicited Interactions
It may be that the PCC-PCE communications (see Section 6.6) can be
usefully extended beyond a simple request/response interaction. For
example, the PCE and PCC could exchange capabilities using this
protocol. Additionally, the protocol could be used to collect and
report information in support of a stateful PCE.
Furthermore, it may be the case that a PCE is able to update a path
that it computed earlier (perhaps in reaction to a change in the
network or a change in policy), and in this case the PCE-PCC
communication could support an "unsolicited" path computation message
to supply this new path to the PCC. Note, however, that this
function would require that the PCE retained a record of previous
computations and had a clear trigger for performing recomputations.
The PCC would also need to be able to identify the new path with the
old path and determine whether it should act on the new path.
Further, the PCC should be able to report the outcome of such path
changes to the requesting PCE. Note that the PCE-PCC interaction is
not a management interaction and the PCC is not obliged to utilize
any additional path supplied by the PCE.
These functions fit easily within the architecture described here but
are left for further discussion within separate requirements
documents.
6.13. Relationship with Crankback
Crankback routing is a mechanism whereby a failure to establish a
path or a failure of an existing path may be corrected by a new path
computation and fresh signaling. Crankback routing relies on the
distribution of crankback information along with the failure
notification so that the new computation can be performed avoiding
the failure or blockage point.
In the context of PCE, crankback information may be passed back to
the head-end where the process of computation and signaling can be
repeated using the failed resource as an exclusion in the computation
process. But crankback may be used to attempt to correct the problem
at intermediate points along the path. Such crankback recomputation
nodes are most likely to be domain boundaries where the PCC had
already invoked a PCE. Thus, a failure within a domain is reported
to the ingress domain boundary, which will attempt to compute an
alternate path across the domain. Failing this, the problem may be
reported to the previous domain and communicated to the ingress
boundary for that domain, which may attempt to select a more
successful path either by choosing a different entry point into the
next domain, or by selecting a route through a different set of
domains.
7. The View from the Path Computation Client
The view of the PCE architecture, and particularly the functional
model, is subtly different from the PCC’s perspective. This is
partly because the PCC has limited knowledge of the way in which the
PCEs cooperate to answer its requests, but depends more on the fact
that the PCC is concerned with different questions.
The PCC is interested in the following:
- Selecting a PCE that is able to promptly provide a computed path
that meets the supplied constraints.
- How many computation requests will the PCC have to send? Will the
desired path be computed by the first PCE contacted (possibly in
cooperation with other PCEs), or will the PCC have to consult other
PCEs to fill in gaps in the path?
- How many other path computations will need to be issued from within
the network in order to establish the TE LSP?
This last question might be considered out of scope for the head-end
LSR, but an important constraint that the PCC may wish to apply is
that the path should be computed in its entirety and supplied without
loose hops or non-simple abstract nodes.
Thus, with its limited perspective, the PCC will see Multiple PCE
Path Computation (Section 5.3) as important and will distinguish two
subcases. The first is as shown in Figure 3 with subsequent
computation requests made by other PCCs along the path of the TE LSP.
In the second, multiple computation requests are issued by the head-
end LSR. On the other hand, the PCC will not be aware of Multiple
PCE Path Computation with Inter-PCE Communication (Section 5.4),
which it will perceive as no different from the simple External PCE
Node case (Section 5.2).
The PCC, therefore, will be acutely aware that a Centralized PCE
Model (Section 6.1) might still require Multiple PCE Path
Computations with the head-end or subsequent PCCs required to issue
further requests to the central PCE. Conversely, the PCC may be
protected from the Distributed PCE Model (Section 6.2) because the
first PCE it consults uses inter-PCE communication to achieve a
complete computation result so that no further computation requests
are required.
These distinctions can be completely classified by determining
whether the computation response includes all necessary paths, and
whether those paths are fully explicit (that is, containing only
strict hops between simple abstract nodes).
8. Evaluation Metrics
Evaluation metrics that may be used to evaluate the efficiency and
applicability of any PCE-based solution are listed below. Note that
these metrics are not being used to determine paths, but are used to
evaluate potential solutions to the PCE architecture.
- Optimality: The ability to maximize network utilization and
minimize cost, considering QoS objectives, multiple regions, and
network layers. Note that models that require the sequential
involvement of multiple PCEs (for example, the multiple PCE model
described in Section 5.3) might create path loops unless careful
policy is applied.
- Scalability: The implications of routing, TE LSP signaling, and PCE
communication overhead, such as the number of messages and the size
of messages (including LSAs, crankback information, queries,
distribution mechanisms, etc.).
- Load sharing: The ability to allow multiple PCEs to spread the path
computation load by allowing multiple PCEs each to take
responsibility for a subset of the total path computation requests.
- Multi-path computation: The ability to compute multiple and
potentially diverse paths to satisfy load-sharing of traffic and
protection/restoration needs including end-to-end diversity and
protection within individual domains.
- Reoptimization: The ability to perform TE LSP path reoptimization.
This also includes the ability to perform inter-layer correlation
when considering the reoptimization at any specific layer.
- Path computation time: The time to compute individual paths and
multiple diverse paths and to satisfy bulk path computation
requests. (Note that such a metric can only be applied to problems
that are not NP-complete.)
- Network stability: The ability to minimize any perturbation on
existing TE state resulting from the computation and establishment
of new TE paths.
- Ability to maintain accurate synchronization between TED and
network topology and resource states.
- Speed with which TED synchronization is achieved.
- Impact of the synchronization process on the data flows in the
network.
- Ability to deal with situations where paths satisfying a required
set of constraints cannot be found by the PCE.
- Policy: Application of policy to the PCC-PCE and PCE-PCE
communications as well as to the computation of paths that respect
inter-domain TE LSP establishment policies.
Note that other metrics may also be considered. Such metrics should
be used when evaluating a particular PCE-based architecture. The
potential tradeoffs of the optimization of such metrics should be
evaluated (for instance, increasing the path optimality is likely to
have consequences on the computation time).
9. Manageability Considerations
The PCE architecture introduces several elements that are subject to
manageability. The PCE itself must be managed, as must its
communications with PCCs and other PCEs. The mechanism by which PCEs
and PCCs discover each other are also subject to manageability.
Many of the issues of manageability are already covered in other
sections of this document.
9.1. Control of Function and Policy
It must be possible to enable and disable the PCE function at a PCE,
and this will lead to the PCE accepting, rejecting, or simply not
receiving requests from PCCs. Graceful shutdown of the PCE function
should also be considered so that in controlled circumstances (such
as software upgrade) a PCE does not just ’disappear’ but warns its
PCCs and gracefully handles any queued computation requests (perhaps
by completing them, forwarding them to another PCE, or rejecting
them).
Similarly it must be possible to control the application of policy at
the PCE through configuration. This control may include the
restriction of certain functions or algorithms, the configuration of
access rights and priorities for PCCs, and the relationships with
other PCEs both inside and outside the domain.
The policy configuration interface is yet to be determined. The
interface may be purely a local matter, or it may be supported via a
standardized interface (such as a MIB module).
9.2. Information and Data Models
It is expected that the operations of PCEs and PCCs will be modeled
and controlled through appropriate MIB modules. The tables in the
new MIB modules will need to reflect the relationships between
entities and to control and report on configurable options.
Statistics gathering will form an important part of the operation of
PCEs. The operator must be able to determine the historical
interactions of a PCC with its PCEs, the performance that it has
seen, and the success rate of its requests. Similarly, it is
important for an operator to be able to inspect a PCE and determine
its load and whether an individual PCC is responsible for a
disproportionate amount of the load. It will also be important to be
able to record and inspect statistics about the communications
between the PCC and PCE, including issues such as malformed messages,
unauthorized messages, and messages discarded because of congestion.
In this respect, there is clearly an overlap between manageability
and security.
Statistics for the PCE architecture can be made available through
appropriate tables in the new MIB modules.
The new MIB modules should also be used to provide notifications when
key thresholds are crossed or when important events occur. Great
care must be exercised to ensure that the network is not flooded with
Simple Network Management Protocol (SNMP) notifications. Thus, it
might be inappropriate to issue a notification every time a PCE
receives a request to compute a path. In any case, full control must
be provided to allow notifications to be disabled using, for example,
the mechanisms defined in the SNMP-NOTIFICATION-MIB module in
[RFC3413].
9.3. Liveness Detection and Monitoring
Section 6.5 discusses the importance of a PCC being able to detect
the liveness of a PCE. PCE-PCC communications techniques must enable
a PCC to determine the liveness of a PCE both before it sends a
request and in the period between sending a request and receiving a
response.
It is less important for a PCE to know about the liveness of PCCs,
and within the simple request/response model, this is only helpful
- to gain a predictive view of the likely loading of a PCE in the
future, or
- to allow a PCE to abandon processing of a received request.
9.4. Verifying Correct Operation
Correct operation for the PCE architecture can be classified as
determining the correct point-to-point connectivity between PCCs and
PCEs, and as assessing the validity of the computed paths. The
former is a security issue that may be enhanced by authentication and
monitored through event logging and records as described in Section
9.1. It may also be a routing issue to ensure that PCC-PCE
connectivity is possible.
Verifying computed paths is more complex. The information to perform
this function can, however, be made available to the operator through
MIB tables, provided that full records are kept of the constraints
passed on the request, the path computed and provided on the
response, and any additional information supplied by the PCE such as
the constraint relaxation policies applied.
9.5. Requirements on Other Protocols and Functional Components
At the architectural stage, it is impossible to make definitive
statements about the impact on other protocols and functional
components since the solution’s work has not been completed.
However, it is possible to make some observations.
- Dependence on underlying transport protocols
PCE-PCC communications may choose to utilize underlying protocols
to provide transport mechanisms. In this case, some of the
manageability considerations described in the previous sections may
be devolved to those protocols.
- Re-use of existing protocols for discovery
Without prejudicing the requirements and solutions work for PCE
discovery (see Section 6.4), it is possible that use will be made
of existing protocols to facilitate this function. In this case
some of the manageability considerations described in the previous
sections may be devolved to those protocols.
- Impact on LSRs and TE LSP signaling
The primary example of a PCC identified in this architecture is an
MPLS or a GMPLS LSR. Consideration must therefore be given to the
manageability of the LSRs and the additional manageability
constraints applicable to the TE LSP signaling protocols.
In addition to allowing the PCC management described in the
previous sections, an LSR must be configurable to determine whether
it will use a remote PCE at all, the options being to use hop-by-
hop routing or to supply the PCE function itself. It is likely to
be important to be able to distinguish within an LSR whether the
route used for a TE LSP was supplied in a signaling message from
another LSR, by an operator, or by a PCE, and, in the case where it
was supplied in a signaling message, whether it was enhanced or
expanded by a PCE.
- Reuse of existing policy models and mechanisms
As policy support mechanisms can be quite extensive, it is
worthwhile to explore to what extent this prior work can be
leveraged and applied to PCE. This desire to leverage prior work
should not be interpreted as a requirement to use any particular
solution or protocol.
9.6. Impact on Network Operation
This architecture may have two impacts on the operation of a network.
It increases TE LSP setup times while requests are sent to and
processed by a remote PCE, and it may cause congestion within the
network if a significant number of computation requests are issued in
a small period of time. These issues are most severe in busy
networks and after network failures, although the effect may be
mitigated if the protection paths are precomputed or if the path
computation load is distributed among a set of PCEs.
Issues of potential congestion during recovery from failures may be
mitigated through the use of pre-established protection schemes such
as fast reroute.
It is important that network congestion be managed proactively
because it may be impossible to manage it reactively once the network
is congested. It should be possible for an operator to rate limit
the requests that a PCC sends to a PCE, and a PCE should be able to
report impending congestion (according to a configured threshold)
both to the operator and to its PCCs.
9.7. Other Considerations
No other management considerations have been identified.
10. Security Considerations
The impact of the use of a PCE-based architecture must be considered
in the light of the impact that it has on the security of the
existing routing and signaling protocols and techniques in use within
the network. The impact may be less likely to be an issue in the
case of intra-domain use of PCE, but an increase in inter-domain
information flows and the facilitation of inter-domain path
establishment may increase the vulnerability to security attacks.
Of particular relevance are the implications for confidentiality
inherent in a PCE-based architecture for multi-domain networks. It
is not necessarily the case that a multi-domain PCE solution will
compromise security, but solutions MUST examine their effects in this
area.
Applicability statements for particular combinations of signaling,
routing and path computation techniques are expected to contain
detailed security sections.
Note that the use of a non-local PCE (that is, one not co-resident
with the PCC) does introduce additional security issues. Most
notable among these are:
- interception of PCE requests or responses;
- impersonation of PCE or PCC;
- falsification of TE information, policy information, or PCE
capabilities; and
- denial-of-service attacks on PCE or PCE communication mechanisms.
It is expected that PCE solutions will address these issues in detail
using authentication and security techniques.
11. Acknowledgements
The authors would like to extend their warmest thanks to (in
alphabetical order) Arthi Ayyangar, Zafar Ali, Lou Berger, Mohamed
Boucadair, Igor Bryskin, Dean Cheng, Vivek Dubey, Kireeti Kompella,
Jean-Louis Le Roux, Stephen Morris, Eiji Oki, Dimitri Papadimitriou,
Richard Rabbat, Payam Torab, Takao Shimizu, and Raymond Zhang for
their review and suggestions. Lou Berger provided valuable and
detailed contributions to the discussion of policy in this document.
Thanks also to Pekka Savola, Russ Housley and Dave Kessens for review
and constructive discussions during the final stages of publication.
12. Informative References
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O’Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September
2003.
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network
Management Protocol (SNMP) Applications", STD 62, RFC
3413, December 2002.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3748] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004.
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Traffic Engineering
(TE) Management Information Base (MIB)", RFC 3812, June
2004.
[RFC4105] Le Roux, J.-L., Vasseur, J.-P., and J. Boyle,
"Requirements for Inter-Area MPLS Traffic Engineering",
RFC 4105, June 2005.
[RFC4216] Zhang, R. and J.-P. Vasseur, "MPLS Inter-Autonomous System
(AS) Traffic Engineering (TE) Requirements", RFC 4216,
November 2005.
[MLN] Shiomoto, K., Papdimitriou, D., Le Roux, J.-L., Vigoureux,
M., and D. Brungard, "Requirements for GMPLS-based multi-
region and multi-layer networks (MRN/MLN)", Work in
Progress, June 2006.
Authors’ Addresses
Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.uk
Jean-Philippe Vasseur
1414 Massachussetts Avenue
Boxborough, MA 01719
USA
EMail: jpv@cisco.com
Jerry Ash
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748,
USA
Phone: (732)-420-4578
Fax: (732)-368-8659
EMail: gash@att.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).