draft-ietf-pce-architecture-03.txt   draft-ietf-pce-architecture-04.txt 
Network Working Group Adrian Farrel Network Working Group Adrian Farrel
IETF Internet Draft Old Dog Consulting IETF Internet Draft Old Dog Consulting
Proposed Status: Informational Jean-Philippe Vasseur Proposed Status: Informational Jean-Philippe Vasseur
Expires: June 2006 Cisco Systems, Inc. Expires: July 2006 Cisco Systems, Inc.
Jerry Ash Jerry Ash
AT&T AT&T
December 2005 January 2006
draft-ietf-pce-architecture-03.txt draft-ietf-pce-architecture-04.txt
Path Computation Element (PCE) Architecture A Path Computation Element (PCE) Based Architecture
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 4, line 33 skipping to change at page 4, line 33
applying computational constraints during the computation. The PCE applying computational constraints during the computation. The PCE
entity is an application that can be located within a network node or entity is an application that can be located within a network node or
component, on an out-of-network server, etc. For example, a PCE would component, on an out-of-network server, etc. For example, a PCE would
be able to compute the path of a TE LSP by operating on the TED and be able to compute the path of a TE LSP by operating on the TED and
considering bandwidth and other constraints applicable to the TE LSP considering bandwidth and other constraints applicable to the TE LSP
service request. service request.
A domain is any collection of network elements within a common sphere A domain is any collection of network elements within a common sphere
of address management or path computation responsibility. Examples of of address management or path computation responsibility. Examples of
domains include IGP areas, Autonomous Systems (ASs), and multiple ASs domains include IGP areas, Autonomous Systems (ASs), and multiple ASs
within a Service Provider network. However, domains of path within a Service Provider network. Domains of path computation
computation responsibility may also exist as sub-domains of areas or responsibility may also exist as sub-domains of areas or ASs.
ASs.
In order to fully characterize a PCE and clarify these definitions, In order to fully characterize a PCE and clarify these definitions,
the following important considerations must also be examined: the following important considerations must also be examined:
1) Path computation is applicable in intra-domain, inter-domain, and 1) Path computation is applicable in intra-domain, inter-domain, and
inter-layer contexts. inter-layer contexts.
a. Inter-domain path computation may involve the correlation of a. Inter-domain path computation may involve the association of
topology, routing and policy information between domains. topology, routing and policy information from multiple domains
from which relationships may be deduced in order to help in
performing path computation.
b. Inter-layer path computation refers to the use of PCE where b. Inter-layer path computation refers to the use of PCE where
multiple layers are involved and when the objective is to multiple layers are involved and when the objective is to
perform path computation at one or multiple layers while taking perform path computation at one or multiple layers while taking
into account topology and resource information at these layers. into account topology and resource information at these layers.
Overlapping domains are not within the scope of this document. In Overlapping domains are not within the scope of this document. In
the inter-domain case, the domains may belong to a single or the inter-domain case, the domains may belong to a single or
multiple Service Providers. multiple Service Providers.
skipping to change at page 10, line 22 skipping to change at page 10, line 22
is similar to the peering relationships between Service Providers. is similar to the peering relationships between Service Providers.
4.9.2. Guaranteed TE LSP Establishment 4.9.2. Guaranteed TE LSP Establishment
When two or more paths for TE LSPs are computed on the same set of TE When two or more paths for TE LSPs are computed on the same set of TE
link state information, it is possible that the resultant paths will link state information, it is possible that the resultant paths will
compete for limited resources within the network. This may result in compete for limited resources within the network. This may result in
success for only the first TE LSP to be signaled, or might even mean success for only the first TE LSP to be signaled, or might even mean
that no TE LSP can be established. that no TE LSP can be established.
Back-off times, alternate path computations, and crankback can help Batch processing of computation requests, back-off times, computation
to mitigate this sort of problem, and PCE may also improve the of alternate paths, and crankback can help to mitigate this sort of
chances of successful TE LSP setup. However, a single, centralized problem, and PCE may also improve the chances of successful TE LSP
PCE is not viewed as a solution that can guarantee TE LSP setup. However, a single, centralized PCE is not viewed as a solution
establishment since the potential for network failures or contention that can guarantee TE LSP establishment since the potential for
for resources still exists where the centralized TED cannot fully network failures or contention for resources still exists where the
reflect current (i.e., real-time) network state. centralized TED cannot fully reflect current (i.e., real-time)
network state.
5. Overview of the PCE-Based Architecture 5. Overview of the PCE-Based Architecture
This section gives an overview of the architecture of the PCE This section gives an overview of the architecture of the PCE
model. It needs to be read in conjunction with the details provided model. It needs to be read in conjunction with the details provided
in the next section to provide a full view of the flexibility of the in the next section to provide a full view of the flexibility of the
model. model.
5.1. Composite PCE Node 5.1. Composite PCE Node
skipping to change at page 14, line 5 skipping to change at page 14, line 5
| Request/ | Request/
| Response | Response
v v
Service ---------- Signaling ---------- Signaling ---------- Service ---------- Signaling ---------- Signaling ----------
Request | Head-End | Protocol | Adjacent | Protocol | Adjacent | Request | Head-End | Protocol | Adjacent | Protocol | Adjacent |
---->| Node |<---------->| Node |<---------->| Node | ---->| Node |<---------->| Node |<---------->| Node |
---------- ---------- ---------- ---------- ---------- ----------
Figure 4. Multiple PCE Path Computation with Inter-PCE Communication Figure 4. Multiple PCE Path Computation with Inter-PCE Communication
Multiple PCE path computation with inter-PCE communication involves Multiple PCE path computation with inter-PCE communication involves
coordination between distributed PCEs such that the result of the coordination between distinct PCEs such that the result of the
computation performed by one PCE depends on information supplied by computation performed by one PCE depends on path fragment information
other PCEs. This model does not provide a distributed computation supplied by other PCEs. This model does not provide a distributed
algorithm, but allows distinct PCEs to be responsible for computation computation algorithm, but allows distinct PCEs to be responsible for
of parts (segments) of the path. computation of parts (segments) of the path.
PCE-PCE communication is discussed further in Section 6.6. PCE-PCE communication is discussed further in Section 6.6.
Note that a PCC might not see the difference between centralized Note that a PCC might not see the difference between centralized
computation, and multiple PCE path computation with inter-PCE computation, and multiple PCE path computation with inter-PCE
communication. That is, the PCC network node or component that communication. That is, the PCC network node or component that
requests the computation makes a single request and receives a full requests the computation makes a single request and receives a full
or partial path in response, but the response is actually achieved or partial path in response, but the response is actually achieved
through the coordinated, cooperative efforts of more than one PCE. through the coordinated, cooperative efforts of more than one PCE.
skipping to change at page 15, line 34 skipping to change at page 15, line 34
Figure 5. Management-based PCE Usage Figure 5. Management-based PCE Usage
5.6 Areas for Standardization 5.6 Areas for Standardization
The following areas require standardization within the PCE The following areas require standardization within the PCE
architecture. architecture.
- communication between PCCs and PCEs, and between cooperating PCEs, - communication between PCCs and PCEs, and between cooperating PCEs,
including the communication of policy related information including the communication of policy related information
- requirements for extensions to existing routing and/or signaling - requirements for extening existing routing and signaling protocols
protocols in support of PCE discovery and signaling of inter-domain in support of PCE discovery and signaling of inter-domain paths
paths
- definition of metrics to evaluate path quality, scalability, - definition of metrics to evaluate path quality, scalability,
responsiveness, robustness and policy support of path computation responsiveness, robustness and policy support of path computation
models models
- MIB modules related to communication protocols, routing and - MIB modules related to communication protocols, routing and
signaling extensions and metrics. signaling extensions and metrics.
6. PCE Architectural Considerations 6. PCE Architectural Considerations
skipping to change at page 17, line 16 skipping to change at page 17, line 15
performed by transit LSRs / composite PCE nodes on an MPLS TE LSP. performed by transit LSRs / composite PCE nodes on an MPLS TE LSP.
Another example is the use of multiple cooperating PCEs to compute Another example is the use of multiple cooperating PCEs to compute
the path of a single TE LSP across multiple domains. the path of a single TE LSP across multiple domains.
6.3. Synchronization 6.3. Synchronization
It is often the case that multiple paths need to be computed to It is often the case that multiple paths need to be computed to
support a single service (for example, for protection or load support a single service (for example, for protection or load
sharing). A PCC that determines that it requires more than one path 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. to be computed may send a series of individual requests to the PCE.
In this case of non-synchronized path computation, the PCE will make In this case of non-synchronized path computation requests, the PCE
multiple individual path computations to generate the paths and the may make multiple individual path computations to generate the paths
PCC may send its individual requests to different PCEs. and the PCC may send its individual requests to different PCEs.
Alternatively, the PCC may send a single request to a PCE asking for 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 a set of paths to be computed, but specifying that non-synchronized
path computation is acceptable. The PCE may compute each path in turn 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 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. 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.
Conversely, the PCC may issue a single request to the PCE asking for The PCC may also issue a single request to the PCE asking for all of
all of the paths to be computed in a synchronized manner. The PCE the paths to be computed in a synchronized manner. The PCE will then
will then perform simultaneous computation of the set of requested perform simultaneous computation of the set of requested paths. Such
path. Such synchronized computation can often provide more optimal synchronized computation can often provide better results.
results.
The involvement of more than one PCE in the computation of a series 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 of paths is by its nature non-synchronized. However, a set of
cooperating PCEs may be synchronized under the control of a single cooperating PCEs may be synchronized under the control of a single
PCE. For example, a PCC may send a request to a PCE which invokes PCE. For example, a PCC may send a request to a PCE which invokes
domain-specific computations by other PCEs before supplying a result domain-specific computations by other PCEs before supplying a result
to the PCC. to the PCC.
It is desirable to add a parameter to the PCC-PCE protocol to request It is desirable to add a parameter to the PCC-PCE protocol to request
that the PCE supplies a set of alternate paths for use by the PCC that the PCE supplies a set of alternate paths for use by the PCC
skipping to change at page 19, line 52 skipping to change at page 19, line 52
The path computation request may include a significant set of The path computation request may include a significant set of
requirements including: requirements including:
- the source and destination of the path - the source and destination of the path
- the bandwidth and other QoS parameters desired - the bandwidth and other QoS parameters desired
- resources, resource affinities and shared risk link groups (SRLGs) - resources, resource affinities and shared risk link groups (SRLGs)
to use/avoid to use/avoid
- the number of disjoint paths required and if near-disjoint paths - the number of disjoint paths required and if near-disjoint paths
are acceptable are acceptable
- the level of robustness of the path resources - the levels of resiliency, reliability and robustness of the path
- policy related information resources
- and so on. - policy related information.
The level of robustness of the path resources covers a qualitative The level of robustness of the path resources covers a qualitative
assessment of the vulnerability of the resources that may be used. assessment of the vulnerability of the resources that may be used.
For example, one might grade resources based on empirical evidence For example, one might grade resources based on empirical evidence
(mean time between failures), on known risks (there is major building (mean time between failures), on known risks (there is major building
work going on near this conduit), or on prejudice (vendor X's work going on near this conduit), or on prejudice (vendor X's
software is always crashing). A PCC could request that only robust software is always crashing). A PCC could request that only robust
resources be used, or allow any resource. resources be used, or allow any resource.
In case of a positive response from the PCE, one or more paths would In case of a positive response from the PCE, one or more paths would
skipping to change at page 35, line 41 skipping to change at page 35, line 41
11. IANA Considerations 11. IANA Considerations
This informational document makes no requests for IANA action. This informational document makes no requests for IANA action.
12. Acknowledgements 12. Acknowledgements
The authors would like to extend their warmest thanks to (in The authors would like to extend their warmest thanks to (in
alphabetical order) Arthi Ayyangar, Zafar Ali, Lou Berger, Mohamed alphabetical order) Arthi Ayyangar, Zafar Ali, Lou Berger, Mohamed
Boucadair, Igor Bryskin, Dean Cheng, Vivek Dubey, Kireeti Kompella, Boucadair, Igor Bryskin, Dean Cheng, Vivek Dubey, Kireeti Kompella,
Jean-Louis Le Roux, Stephen Morris, Eiji Oki, Dimitri Papadimitriou, Jean-Louis Le Roux, Stephen Morris, Eiji Oki, Dimitri Papadimitriou,
Richard Rabbat, Takao Shimizu, and Raymond Zhang for their review and Richard Rabbat, Payam Torab, Takao Shimizu, and Raymond Zhang for
suggestions. Lou Berger provided valuable and detailed contributions their review and suggestions. Lou Berger provided valuable and
to the discussion of policy in this document. detailed contributions to the discussion of policy in this document.
13. Intellectual Property Considerations 13. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 37, line 7 skipping to change at page 37, line 7
[RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for [RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for
Support of Inter-Area and Inter-AS MPLS Traffic Support of Inter-Area and Inter-AS MPLS Traffic
Engineering", RFC 4105, June 2005. Engineering", RFC 4105, June 2005.
[RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic [RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic
Engineering requirements", RFC 4216, November 2005. Engineering requirements", RFC 4216, November 2005.
[MRN] Shiomoto, K., et. al., "Requirements for GMPLS-based [MRN] Shiomoto, K., et. al., "Requirements for GMPLS-based
multi-region and multi-layer networks", multi-region and multi-layer networks",
draft-shiomoto-ccamp-gmpls-mrn-reqs, work in progress. draft-ietf-ccamp-gmpls-mln-reqs, work in progress.
15. Contact Information 15. Contact Information
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Jean-Philippe Vasseur Jean-Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
skipping to change at page 37, line 34 skipping to change at page 37, line 34
AT&T AT&T
Room MT D5-2A01 Room MT D5-2A01
200 Laurel Avenue 200 Laurel Avenue
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
Phone: (732)-420-4578 Phone: (732)-420-4578
Fax: (732)-368-8659 Fax: (732)-368-8659
Email: gash@att.com Email: gash@att.com
16. Full Copyright Statement 16. Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 17 change blocks. 
42 lines changed or deleted 44 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/