draft-ietf-pce-architecture-02.txt   draft-ietf-pce-architecture-03.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: March 2006 Cisco Systems, Inc. Expires: June 2006 Cisco Systems, Inc.
Jerry Ash Jerry Ash
AT&T AT&T
September 2005 December 2005
draft-ietf-pce-architecture-02.txt draft-ietf-pce-architecture-03.txt
Path Computation Element (PCE) Architecture Path Computation Element (PCE) 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.
skipping to change at page 2, line 16 skipping to change at page 2, line 16
2. Terminology .................................................... 3 2. Terminology .................................................... 3
3. Definitions .................................................... 4 3. Definitions .................................................... 4
4. Motivation for a PCE-based Architecture ........................ 6 4. Motivation for a PCE-based Architecture ........................ 6
4.1. CPU-intensive Path Computation ............................. 6 4.1. CPU-intensive Path Computation ............................. 6
4.2. Partial Visibility ......................................... 7 4.2. Partial Visibility ......................................... 7
4.3. Absence of the TED or Use of Non-TE-Enabled IGP ............ 7 4.3. Absence of the TED or Use of Non-TE-Enabled IGP ............ 7
4.4. Node Outside the Routing Domain ............................ 8 4.4. Node Outside the Routing Domain ............................ 8
4.5. Network Element Lacks Control Plane or Routing Capability .. 8 4.5. Network Element Lacks Control Plane or Routing Capability .. 8
4.6. Backup Path Computation for Bandwidth Protection ........... 8 4.6. Backup Path Computation for Bandwidth Protection ........... 8
4.7. Multi-Layer Networks ....................................... 8 4.7. Multi-Layer Networks ....................................... 8
4.8. Non-Motivations ............................................ 9 4.8. Path Selection Policy ...................................... 9
4.8.1. The Whole Internet .................................... 9 4.9. Non-Motivations ........................................... 10
4.8.2. Guaranteed TE LSP Establishment ....................... 9 4.9.1. The Whole Internet ................................... 10
4.9.2. Guaranteed TE LSP Establishment ...................... 10
5. Overview of the PCE-Based Architecture ........................ 10 5. Overview of the PCE-Based Architecture ........................ 10
5.1. Composite PCE Node ........................................ 10 5.1. Composite PCE Node ........................................ 10
5.2. External PCE .............................................. 11 5.2. External PCE .............................................. 11
5.3. Multiple PCE Path Computation ............................. 11 5.3. Multiple PCE Path Computation ............................. 12
5.4. Multiple PCE Path Computation with Inter-PCE Communication 12 5.4. Multiple PCE Path Computation with Inter-PCE Communication 13
5.5. Management-Based PCE Usage ................................ 13 5.5. Management-Based PCE Usage ................................ 14
5.6. Areas for Standardization ................................. 14 5.6. Areas for Standardization ................................. 15
6. PCE Architectural Considerations .............................. 14 6. PCE Architectural Considerations .............................. 15
6.1. Centralized Computation Model ............................. 14 6.1. Centralized Computation Model ............................. 16
6.2. Distributed Computation Model ............................. 15 6.2. Distributed Computation Model ............................. 16
6.3. Synchronization ........................................... 15 6.3. Synchronization ........................................... 17
6.4. PCE Discovery and Load Balancing .......................... 16 6.4. PCE Discovery and Load Balancing .......................... 17
6.5. Detecting PCE Liveness .................................... 17 6.5. Detecting PCE Liveness .................................... 19
6.6. PCC-PCE & PCE-PCE Communication ........................... 17 6.6. PCC-PCE & PCE-PCE Communication ........................... 19
6.7. PCE TED Synchronization ................................... 18 6.7. PCE TED Synchronization ................................... 21
6.8. Stateful Versus Stateless PCEs ............................ 20 6.8. Stateful Versus Stateless PCEs ............................ 22
6.9. Monitoring ................................................ 21 6.9. Monitoring ................................................ 24
6.10. Policy and Confidentiality .............................. 22 6.10. Confidentiality .......................................... 24
6.11. Unsolicited Interactions ................................. 23 6.11. Policy ................................................... 24
6.12. Relationship with Crankback .............................. 23 6.11.1. PCE Policy Architecture ............................ 25
7. The View from the Path Computation Client ..................... 24 6.11.2. Policy Realization ................................. 26
8. Evaluation Metrics ............................................ 25 6.11.3 Type of Policies .................................... 27
9. Manageability Considerations .................................. 26 6.11.4. Relationship to Signaling .......................... 27
9.1. Control of Function and Policy ............................ 26 6.12. Unsolicited Interactions ................................. 28
9.2. Information and Data Models ............................... 26 6.13. Relationship with Crankback .............................. 28
9.3. Liveness Detection and Monitoring ......................... 27 7. The View from the Path Computation Client ..................... 29
9.5. Verifying Correct Operation ............................... 27 8. Evaluation Metrics ............................................ 30
9.5. Requirements on Other Protocols and Functional Components . 28 9. Manageability Considerations .................................. 31
9.6. Impact on Network Operation ............................... 29 9.1. Control of Function and Policy ............................ 31
10. Security Considerations ...................................... 29 9.2. Information and Data Models ............................... 32
11. IANA Considerations .......................................... 30 9.3. Liveness Detection and Monitoring ......................... 32
12. Acknowledgements ............................................. 30 9.5. Verifying Correct Operation ............................... 33
13. Intellectual Property Considerations ......................... 30 9.5. Requirements on Other Protocols and Functional Components . 33
14. Normative References ......................................... 30 9.6. Impact on Network Operation ............................... 34
15. Informational References ..................................... 31 10. Security Considerations ...................................... 34
16. Contact Information .......................................... 31 11. IANA Considerations .......................................... 34
17. Full Copyright Statement ..................................... 32 12. Acknowledgements ............................................. 35
13. Intellectual Property Considerations ......................... 35
14. Normative References ......................................... 35
15. Informational References ..................................... 36
16. Contact Information .......................................... 37
17. Full Copyright Statement ..................................... 37
1. Introduction 1. Introduction
Constraint-based path computation is a fundamental building block for Constraint-based path computation is a fundamental building block for
traffic engineering in MPLS and GMPLS networks. Path computation in traffic engineering in MPLS and GMPLS networks. Path computation in
large, multi-domain networks is complex and may require large, multi-domain networks is complex and may require
special computational components and cooperation between the elements special computational components and cooperation between the elements
in different domains. This document specifies the architecture for a in different domains. This document specifies the architecture for a
Path Computation Element (PCE)-based model to address this problem Path Computation Element (PCE)-based model to address this problem
space. space.
skipping to change at page 4, line 36 skipping to change at page 4, line 44
computation responsibility may also exist as sub-domains of areas or computation 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 correlation of
topology and routing information between domains. topology, routing and policy information between domains.
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 9, line 26 skipping to change at page 9, line 27
In this case, the PCEs are responsible for resolving address space In this case, the PCEs are responsible for resolving address space
issues, handling differences in policy and control parameters, and issues, handling differences in policy and control parameters, and
coordinating resources between the networks. Note that, because of coordinating resources between the networks. Note that, because of
the differences in bandwidth granularity, connectivity across the the differences in bandwidth granularity, connectivity across the
server-layer network may be provided through virtual TE links or server-layer network may be provided through virtual TE links or
Forwarding Adjacencies: the PCE may offer a point of control Forwarding Adjacencies: the PCE may offer a point of control
responsible for the decision to provision new TE links or Forwarding responsible for the decision to provision new TE links or Forwarding
Adjacencies across the server-layer network. Adjacencies across the server-layer network.
4.8. Non-Motivations 4.8 Path Selection Policy
4.8.1. The Whole Internet A PCE may have a local policy that impacts path computation and
selection in response to a path computation request. Such policy may
act on information provided by the requesting PCC. The result of
applying such policy includes, for example, rejection of the path
computation request, or provision of a path that does not meet all
of the requested constraints. Further, the policy may support
administratively configured paths, or selection among transit
providers. Inclusion of policy within PCE may simplify the
application of policy within the path computation/selection process.
Similarly, a PCC may apply local policy to the selection of a PCE to
compute a specific path, and to the constraints that are requested.
In a PCE context, the policy may be sensitive to the type of path
that is being computed. For example, a different set of policies may
be applied for an intra-area or single-layer path, than would be
provided for an inter-area or multi-layer path.
4.9. Non-Motivations
4.9.1. The Whole Internet
PCE is not considered to be a solution that is applicable to the PCE is not considered to be a solution that is applicable to the
entire Internet. That is, the applicability of PCE is limited to a entire Internet. That is, the applicability of PCE is limited to a
set of domains with known relationships. The scale of this limitation set of domains with known relationships. The scale of this limitation
is similar to the peering relationships between Service Providers. is similar to the peering relationships between Service Providers.
4.8.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 Back-off times, alternate path computations, and crankback can help
to mitigate this sort of problem, and PCE may also improve the to mitigate this sort of problem, and PCE may also improve the
chances of successful TE LSP setup. However, a single, centralized chances of successful TE LSP setup. However, a single, centralized
skipping to change at page 10, line 20 skipping to change at page 10, line 45
model. model.
5.1. Composite PCE Node 5.1. Composite PCE Node
Figure 1 below shows the components of a typical composite PCE node Figure 1 below shows the components of a typical composite PCE node
(that is, a router that also implements the PCE functionality) that (that is, a router that also implements the PCE functionality) that
utilizes path computation. The routing protocol is used to exchange utilizes path computation. The routing protocol is used to exchange
TE information from which the TED is constructed. Service requests to TE information from which the TED is constructed. Service requests to
provision TE LSPs are received by the node and converted into provision TE LSPs are received by the node and converted into
signaling requests, but this conversion may require path computation signaling requests, but this conversion may require path computation
which is requested from a PCE. The PCE operates on the TED in order which is requested from a PCE. The PCE operates on the TED subject to
to respond with the requested path. local policy in order to respond with the requested path.
--------------- ---------------
| --------- | Routing ---------- | --------- | Routing ----------
| | | | Protocol | | | | | | Protocol | |
| | TED |<-+----------+-> | | | TED |<-+----------+-> |
| | | | | | | | | | | |
| --------- | | | | --------- | | |
| | | | | | | | | |
| | Input | | | | | Input | | |
| v | | | | v | | |
skipping to change at page 11, line 11 skipping to change at page 11, line 43
Note that the routing adjacency between the composite PCE node and Note that the routing adjacency between the composite PCE node and
any other router may be performed by means of direct connectivity or any other router may be performed by means of direct connectivity or
any tunneling mechanism. any tunneling mechanism.
5.2. External PCE 5.2. External PCE
Figure 2 shows a PCE that is external to the requesting network Figure 2 shows a PCE that is external to the requesting network
element. A service request is received by the head-end node and element. A service request is received by the head-end node and
before it can initiate signaling to establish the service, it makes before it can initiate signaling to establish the service, it makes
a path computation request to the external PCE. The PCE uses the TED a path computation request to the external PCE. The PCE uses the TED
as input to the computation and returns a response. subject to local policy as input to the computation and returns a
response.
---------- ----------
| ----- | | ----- |
| | TED |<-+------------> | | TED |<-+----------->
| ----- | TED synchronization | ----- | TED synchronization
| | | mechanism (for example, routing protocol) | | | mechanism (for example, routing protocol)
| | | | | |
| v | | v |
| ----- | | ----- |
| | PCE | | | | PCE | |
| ----- | | ----- |
---------- ----------
^ ^
| Request/ | Request/
skipping to change at page 11, line 51 skipping to change at page 12, line 43
5.3. Multiple PCE Path Computation 5.3. Multiple PCE Path Computation
Figure 3 illustrates how multiple PCE path computations may be Figure 3 illustrates how multiple PCE path computations may be
performed along the path of a signaled service. As in the previous 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 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 path that is returned is such that the next network element finds it
necessary to perform further computation. This may be the case when necessary to perform further computation. This may be the case when
the path returned is a partial path that does not reach the intended the path returned is a partial path that does not reach the intended
destination or when the computed path is loose. The downstream destination or when the computed path is loose. The downstream
network element consults another PCE to establish the next hop(s) in network element consults another PCE to establish the next hop(s) in
the path. 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 Note that either or both PCEs in this case could be composite PCE
nodes as in Section 5.1. nodes as in Section 5.1.
---------- ---------- ---------- ----------
| | | | | | | |
| PCE | | PCE | | PCE | | PCE |
| | | | | | | |
| ----- | | ----- | | ----- | | ----- |
| | TED | | | | TED | | | | TED | | | | TED | |
skipping to change at page 13, line 20 skipping to change at page 14, line 20
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.
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 5.5 Management-Based PCE Usage
It must be observed that the PCC is not necessarily an LSR. For 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 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 computed explicit path for the TE LSP that it is to establish through
signaling. The NMS uses a management plane mechanism to send this signaling. The NMS uses a management plane mechanism to send this
request such as the TE MIB module [RFC3812]. request such as the TE MIB module [RFC3812].
The NMS constructs the explicit path that it supplies to the head-end The NMS constructs the explicit path that it supplies to the head-end
LSR using information provided by the operator. It consults the PCE LSR using information provided by the operator. It consults the PCE
which returns a path for the NMS to use. which returns a path for the NMS to use.
Although Figure 5 shows the PCE as remote from the NMS it could, of Although Figure 5 shows the PCE as remote from the NMS it could, of
course, be collocated with the NMS. course, be collocated with the NMS.
----------- -----------
| ----- | | ----- |
Service | | TED |<-+------------> Service | | TED |<-+----------->
Request | ----- | TED synchronization Request | ----- | TED synchronization
| | | | mechanism (for example, | | | | mechanism (for example,
v | | | routing protocol) v | | | routing protocol)
------------- Request/ | v | ------------- Request/ | v |
| | Response| ----- | | | Response| ----- |
| NMS |<--------+->| PCE | | | NMS |<--------+>| PCE | |
| | | ----- | | | | ----- |
------------- ----------- ------------- -----------
Service | Service |
Request | Request |
v v
---------- Signaling ---------- ---------- Signaling ----------
| Head-End | Protocol | Adjacent | | Head-End | Protocol | Adjacent |
| Node |<---------->| Node | | Node |<---------->| Node |
---------- ---------- ---------- ----------
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
- requirements for extensions to existing routing and/or signaling - requirements for extensions to existing routing and/or signaling
protocols in support of PCE discovery and signaling of inter-domain protocols 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 and robustness of path computation models responsiveness, robustness and policy support of path computation
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
This section provides a list of the PCE architectural components. This section provides a list of the PCE architectural components.
Specific realizations and implementation details (state machines or Specific realizations and implementation details (state machines or
algorithms, etc.) of PCE-based solutions are out of the scope of this algorithms, etc.) of PCE-based solutions are out of the scope of this
document. document.
skipping to change at page 15, line 8 skipping to change at page 16, line 30
external PCE node), or a designated router (for example, a composite 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 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 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 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 sub-group of network nodes that is defined by its dependence on the
PCE. PCE.
This model has a single point of failure: the PCE. In order to avoid This model has a single point of failure: the PCE. In order to avoid
this issue, the centralized computation model may designate a backup this issue, the centralized computation model may designate a backup
PCE that can take over the computation responsibility in a controlled PCE that can take over the computation responsibility in a controlled
manner in the event of a failure of the primary PCE. Note that at any 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. moment in time there is only one active PCE in any domain.
6.2. Distributed Computation Model 6.2. Distributed Computation Model
A "distributed computation model" refers to a domain or network that A "distributed computation model" refers to a domain or network that
may include multiple PCEs, and where computation of paths is shared 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 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 ("single PCE path computation") or multiple PCEs ("multiple PCE path
computation"). A PCC may be linked to a particular PCE, or may be computation"). A PCC may be linked to a particular PCE, or may be
able to choose freely among several PCEs - the method of choice 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 between PCEs is out of scope of this document, but see Section 6.4
for a discussion of PCE discovery which impacts on this choice. It for a discussion of PCE discovery which impacts on this choice.
will often be the case that the computation of an individual path is Implementation of policy should be consistent across the set of
performed entirely by a single PCE. For example, this is usually the available PCEs.
case in MPLS TE within a single IGP area where the ingress LSR /
It will often be the case that 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 composite PCE node is responsible for computing the path or for
contacting an external PCE. Conversely, multiple PCE path computation contacting an external PCE. Conversely, multiple PCE path computation
implies that more than one PCE is involved in the computation of a 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 single path. An example of this is where loose hop expansion is
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
skipping to change at page 16, line 9 skipping to change at page 17, line 36
Conversely, the PCC may issue a single request to the PCE asking for Conversely, the PCC may issue a single request to the PCE asking for
all of the paths to be computed in a synchronized manner. The PCE all of the paths to be computed in a synchronized manner. The PCE
will then perform simultaneous computation of the set of requested will then perform simultaneous computation of the set of requested
path. Such synchronized computation can often provide more optimal path. Such synchronized computation can often provide more optimal
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
should the establishment of the TE LSP using the principal path fail should the establishment of the TE LSP using the principal path fail
to complete. While alternate paths may not always be successful if to complete. While alternate paths may not always be successful if
the first path fails, including alternate paths in a PCE response the first path fails, including alternate paths in a PCE response
could have less overhead than having the PCC make separate requests could have less overhead than having the PCC make separate requests
for subsequent path computations as the need arises. This technique for subsequent path computations as the need arises. This technique
is used in some existing CSPF implementations. is used in some existing CSPF implementations.
6.4. PCE Discovery and Load Balancing 6.4. PCE Discovery and Load Balancing
The PCE architecture requires that the PCC/PCE know the location of In order that a PCC can communicate efficiently with a PCE, it must
one or more PCEs that it can use for the computation of a path. Such know the location of the PCE. That is, it is an architectural
knowledge may come through a discovery mechanism that simply relies decision made here that PCC requests are targeted to a specific PCE,
on local configuration, or can imply dynamic PCE discovery along with and not broadcast to the network for any PCE to respond. This
various static (for example, Boolean capability) or dynamically decision means that only the selected PCE will operate on any single
computed variables (for example, computing resources). Proxy PCE request, and saves network resources during request propagation and
advertisement whereby the existence of a PCE is advertised via a processing resources at the PCEs that are not required to respond.
proxy PCE is a viable alternative, should the PCE be incapable of
such advertisement itself. In this later case, it is a requirement The knowledge of the location of a PCE may be achieved through local
for the proxy to adequately advertise the PCE status and capability configuration at the PCC, or may rely on a protocol-based discovery
in a timely and synchronized fashion. mechanism that may be governed by policy.
Where there is more than one PCE 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 for
the proxy to 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 In the event that multiple PCEs are available to serve a particular
path computation request, the PCC must select a PCE to satisfy the path computation request, the PCC must select a PCE to satisfy the
request. The details of such a selection, in order for instance to request. The details of such a selection, in order for instance to
efficiently share the computation load across multiple PCEs, is local efficiently share the computation load across multiple PCEs, is local
to the PCC and out of the scope of this document. to the PCC, may be based on policy and out of the scope of this
document.
A PCE SHOULD advertise its capabilities, such as: PCE capabilities that may be advertised or configured could include
(and not be limited to):
- set of constraints that it can account for (diversity, SRLGs, - set of constraints that it can account for (diversity, SRLGs,
Optical impairments, wavelength continuity, etc.) Optical impairments, wavelength continuity, etc.)
- computational capacity (for example, the number of computations it - computational capacity (for example, the number of computations it
can perform per second) can perform per second)
- number of switching capability layers (and which ones) - number of switching capability layers (and which ones)
- number of path selection criteria (and which ones) - number of path selection criteria (and which ones)
- whether it is a stateless PCE or it can send updates about - whether it is a stateless PCE or it can send updates about
better paths that might be available in the future better paths that might be available in the future
- whether it can compute P2MP trees (and which types) - whether it can compute P2MP trees (and which types)
- whether it can ensure resource sharing between backup tunnels. - whether it can ensure resource sharing between backup tunnels.
This information would help a PCC that dynamically learns about This information would help a PCC to decide which PCE to use.
PCEs available on the network to decide which of them to use.
Alternatively, a PCC might ask a PCE to perform a particular type Requirements for PCE advertisement will be documented separately.
of service and receive a response that says that the PCE is unable to Note that there is no restriction within the architecture about how
perform the service, but specifying the things that the PCE can do. location and capabilities are advertised, and the two elements should
Note that the parameters mentioned above are not meant to be be considered to be functionally distinct.
exhaustive and are listed for the sake of illustration.
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 6.5. Detecting PCE Liveness
The ability to detect a PCE's liveness is a mandatory piece of the 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 overall architecture and could be achieved by several means. If some
form of regular advertisement (such as through IGP extensions) is form of regular advertisement (such as through IGP extensions) is
used for PCE discovery, it is expected that the PCE liveness will be used for PCE discovery, it is expected that the PCE liveness will be
determined by means of status advertisement (for example, IGP determined by means of status advertisement (for example, IGP
LSA/LSPs). LSA/LSPs).
skipping to change at page 17, line 50 skipping to change at page 19, line 53
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 level of robustness of the path resources
- policy related information
- and so on. - and so on.
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.
skipping to change at page 18, line 34 skipping to change at page 20, line 39
would be returned to the requesting PCE. In the event of a failure to 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 compute the desired path(s), an error is returned together with as
much information as possible about the reasons for the failure, and much information as possible about the reasons for the failure, and
potentially advice about which constraints might be relaxed to be potentially advice about which constraints might be relaxed to be
more likely to achieve a positive result. Note that the resultant more likely to achieve a positive result. Note that the resultant
path(s) may be made up of a set of strict or loose hops, or any 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 combination of strict and loose hops. Moreover, a hop may have the
form of a non-explicit abstract node. form of a non-explicit abstract node.
An important feature of PCEs that are cooperating to compute a path An important feature of PCEs that are cooperating to compute a path
is that they apply compatible or identical computation algorithms. is that they apply compatible or identical computation algorithms and
This may require coordination through the communication between the coordinated policies. This may require coordination through the
PCEs. communication between the PCEs.
Note that when multiple PCEs cooperate to compute a path it is Note that when multiple PCEs cooperate to compute a path it is
important that they have a coordinated view of the meaning of important that they have a coordinated view of the meaning of
constraints such as costs, resource affinities and class of service. constraints such as costs, resource affinities and class of service.
This is particularly significant where the PCEs are responsible for This is particularly significant where the PCEs are responsible for
different domains. It is assumed that this is a matter of policy different domains. It is assumed that this is a matter of policy
between domains and between PCEs, and is achieved through between domains and between PCEs.
configuration not through protocol communications.
No assumption is made in this architecture about whether the PCC-PCE No assumption is made in this architecture about whether the PCC-PCE
and PCE-PCE communication protocols are identical. and PCE-PCE communication protocols are identical.
6.7. PCE TED Synchronization 6.7. PCE TED Synchronization
As previously described, the PCE operates on a TED. Information on As previously described, the PCE operates on a TED. Information on
network status to build the TED may be provided in the domain by network status to build the TED may be provided in the domain by
various means: various means:
skipping to change at page 22, line 5 skipping to change at page 24, line 15
6.9. Monitoring 6.9. Monitoring
PCE Monitoring is undoubtedly of the utmost importance in any PCE PCE Monitoring is undoubtedly of the utmost importance in any PCE
architecture. This must include the collection of variables related architecture. This must include the collection of variables related
to the PCE status and operation. For example, it will be necessary to 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 understand the way in which the TED is being kept synchronized, the
rate of arrival of new requests and the computation times, the range 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 of PCCs that are using the PCE, and the operation of any PCC-PCE
protocol. protocol.
6.10. Policy and Confidentiality 6.10. Confidentiality
As stated in [INTER-AS], the case of inter-provider TE LSP As stated in [RFC4216], the case of inter-provider TE LSP
computation requires the ability to compute a path while preserving computation requires the ability to compute a path while preserving
confidentiality across multiple Service Providers cores. Thus any PCE confidentiality across multiple Service Providers cores. Thus any PCE
architecture solution must support the ability to return partial architecture solution must support the ability to return partial
paths by means of loose hops (for example, where each loose hops paths by means of loose hops (for example, where each loose hops
would for instance identify a boundary LSR). Confidentiality and would for instance identify a boundary LSR). Confidentiality and
security of PCC-PCE and PCE-PCE messages must also be ensured. security of PCC-PCE and PCE-PCE messages must also be ensured.
The ability to compute a path at the request of the head end PCC, but 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 to supply the path in segments to the domain boundary PCCs may also
be desirable. be desirable.
The use of the PCE architecture makes the need for proper 6.11. Policy
consideration of Policy more obvious. There is clearly no change in
the requirements for appropriate Policy mechanisms for inter-domain
TE LSPs. This application of Policy is required to protect the
resources of one domain from requests initiated in another domain and
may involve considerations of inter-provider agreements, billing
regimes, resource scarcity, and client priority. Policy as directly
applicable to TE LSPs forms part of the signaling mechanism for the
establishment of the TE LSPs.
When a path for an inter-domain TE LSP is being computed it is not Policy impacts multiple aspects of the PCE architecture. There are
required to consider Policy. However, failure to do so may result in two applications of policy for consideration:
the TE LSP failing to be established or being assigned fewer - application of policy within an architectural entity (PCC or PCE)
resources than intended resulting in a substandard service. Thus, - application of policy to PCE related communications.
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 (equivalent to another constraint) 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 such context Policy
violation during inter-domain TE LSP computation may lead to path
computation interruption which should be notified to the requester
along with the cause.
At the same time, interactions between cooperating PCEs may Policy as directly applicable to TE LSPs forms part of the signaling
themselves be subject to Policy. For example, a PCE may not wish to mechanism for the establishment of the TE LSPs and is not described
divulge answers or full details in response to a request from a PCE here.
in another domain. Similarly, a PCE may wish to apply Policy to the
way that it services requests from an individual PCC - it may decide
that a particular PCC should be assigned lower priority in the queue
of computation requests, be given access to a specific subset of the
available computation algorithms, or have paths computed using a
restricted TED.
Thus there are multiple dimensions to Policy in the PCE context and It is envisioned that policy will be largely applied as a local
this needs to form part of the protocol solutions that are developed. 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.
6.11. Unsolicited Interactions 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.
Note that policy information may be conveyed on the internal
interfaces, and on the external protocol interfaces.
------------------------------
| --------- | 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
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 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 to appear 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
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 such context policy violation during
inter-domain TE LSP computation may lead to path computation
interruption which should be notified to the requester along with the
cause.
6.12. Unsolicited Interactions
It may be that the PCC-PCE communications (see Section 6.6) can be It may be that the PCC-PCE communications (see Section 6.6) can be
usefully extended beyond a simple request/response interaction. For usefully extended beyond a simple request/response interaction. For
example, the PCE and PCC could exchange capabilities using this example, the PCE and PCC could exchange capabilities using this
protocol. Additionally, the protocol could be used to collect and protocol. Additionally, the protocol could be used to collect and
report information in support of a stateful PCE. report information in support of a stateful PCE.
Further, it may be the case that a PCE is able to update a path that Further, 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), it computed earlier (perhaps in reaction to a change in the network
and in this case the PCE-PCC communication could support an or a change in policy), and in this case the PCE-PCC communication
"unsolicited" path computation message to supply this new path to the could support an "unsolicited" path computation message to supply
PCC. It should be noted, however, that this function would require this new path to the PCC. It should be noted, however, that this
that the PCE retained a record of previous computations and had a function would require that the PCE retained a record of previous
clear trigger for performing recomputations. The PCC would also need computations and had a clear trigger for performing recomputations.
to be able to identify the new path with the old path and determine The PCC would also need to be able to identify the new path with the
whether it should act on the new path. Furthermore, the PCC should be old path and determine whether it should act on the new path.
able to report the outcome of such path changes to the requesting Furthermore, the PCC should be able to report the outcome of such
PCE. Note that the PCE-PCC interaction is not a management path changes to the requesting PCE. Note that the PCE-PCC interaction
interaction and the PCC is not obliged to utilize any additional path is not a management interaction and the PCC is not obliged to utilize
supplied by the PCE. any additional path supplied by the PCE.
These functions fit easily within the architecture described here These functions fit easily within the architecture described here
but are left for further discussion within separate requirements but are left for further discussion within separate requirements
documents. documents.
6.12. Relationship with Crankback 6.13. Relationship with Crankback
Crankback routing is a mechanism whereby a failure to establish a 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, or a failure of an existing path may be corrected by a new
path computation and fresh signaling. Crankback routing relies on the path computation and fresh signaling. Crankback routing relies on the
distribution of crankback information along with the failure distribution of crankback information along with the failure
notification so that the new computation can be performed avoiding notification so that the new computation can be performed avoiding
the failure or blockage point. the failure or blockage point.
In the context of PCE, crankback information may be passed back to In the context of PCE, crankback information may be passed back to
the head-end where the process of computation and signaling can be the head-end where the process of computation and signaling can be
skipping to change at page 26, line 11 skipping to change at page 31, line 11
network topology and resource states. network topology and resource states.
- Speed with which TED synchronization is achieved. - Speed with which TED synchronization is achieved.
- Impact of the synchronization process on the data flows in the - Impact of the synchronization process on the data flows in the
network. network.
- Ability to deal with situations where paths satisfying a required - Ability to deal with situations where paths satisfying a required
set of constraints cannot be found by the PCE. set of constraints cannot be found by the PCE.
- Policy: Application of Policy to the PCC-PCE and PCE-PCE - Policy: Application of policy to the PCC-PCE and PCE-PCE
communications as well as to the computation of paths that respect communications as well as to the computation of paths that respect
inter-domain TE LSP establishment Policies. inter-domain TE LSP establishment policies.
Note that other metrics may also be considered. Such metrics should Note that other metrics may also be considered. Such metrics should
be used when evaluating a particular PCE-based architecture. It must be used when evaluating a particular PCE-based architecture. It must
also be highlighted that the potential tradeoffs of the optimization also be highlighted that the potential tradeoffs of the optimization
of such metrics should be evaluated (for instance, increasing the of such metrics should be evaluated (for instance, increasing the
path optimality is likely to have consequences on the computation path optimality is likely to have consequences on the computation
time). time).
9. Manageability Considerations 9. Manageability Considerations
skipping to change at page 26, line 43 skipping to change at page 31, line 43
It must be possible to enable and disable the PCE function at a PCE, 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 and this will lead to the PCE accepting, rejecting, or simply not
receiving requests from PCCs. Graceful shutdown of the PCE function receiving requests from PCCs. Graceful shutdown of the PCE function
should also be considered so that in controlled circumstances (such should also be considered so that in controlled circumstances (such
as software upgrade) a PCE does not just 'disappear' but warns its as software upgrade) a PCE does not just 'disappear' but warns its
PCCs and gracefully handles any queued computation requests (perhaps PCCs and gracefully handles any queued computation requests (perhaps
by completing them, forwarding them to another PCE, or rejecting by completing them, forwarding them to another PCE, or rejecting
them). them).
Similarly it must be possible to control the application of Policy at Similarly it must be possible to control the application of policy at
the PCE through configuration. This control may include the the PCE through configuration. This control may include the
restriction of certain functions or algorithms, the configuration of restriction of certain functions or algorithms, the configuration of
access rights and priorities for PCCs, and the relationships with access rights and priorities for PCCs, and the relationships with
other PCEs both inside and outside the domain. 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 may be supported via a
standardized interface (such as, a MIB module).
9.2. Information and Data Models 9.2. Information and Data Models
It is expected that the operations of PCEs and PCCs will be modeled It is expected that the operations of PCEs and PCCs will be modeled
and controlled through appropriate MIB modules. The tables in the new and controlled through appropriate MIB modules. The tables in the new
MIB modules will need to reflect the relationships between entities MIB modules will need to reflect the relationships between entities
and to control and report on configurable options. and to control and report on configurable options.
Statistics gathering will form an important part of the operation of Statistics gathering will form an important part of the operation of
PCEs. The operator must be able to determine the historical PCEs. The operator must be able to determine the historical
interactions of a PCC with its PCEs, the performance that it has interactions of a PCC with its PCEs, the performance that it has
skipping to change at page 29, line 5 skipping to change at page 34, line 10
As well as allowing the PCC management described in the previous As well as allowing the PCC management described in the previous
sections, an LSR must be configurable to determine whether it will 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 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 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 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 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 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 supplied in a signaling message whether it was enhanced or expanded
by a PCE. 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 9.6. Impact on Network Operation
This architecture may have two impacts on the operation of a network. This architecture may have two impacts on the operation of a network.
It increases TE LSP setup times while requests are sent to and It increases TE LSP setup times while requests are sent to and
processed by a remote PCE, and it may cause congestion within the processed by a remote PCE, and it may cause congestion within the
network if a significant number of computation requests are issued in network if a significant number of computation requests are issued in
a small period of time. These issues are most severe in busy networks a small period of time. These issues are most severe in busy networks
and after network failures, although the effect may be mitigated if and after network failures, although the effect may be mitigated if
the protection paths are precomputed or if the path computation load the protection paths are precomputed or if the path computation load
is distributed among a set of PCEs. is distributed among a set of PCEs.
skipping to change at page 29, line 27 skipping to change at page 34, line 40
mitigated through the use of pre-established protection schemes such mitigated through the use of pre-established protection schemes such
as fast reroute. as fast reroute.
It is important that network congestion be managed proactively It is important that network congestion be managed proactively
because it may be impossible to manage it reactively once the network 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 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 requests that a PCC sends to a PCE, and a PCE should be able to
report impending congestion (according to a configured threshold) report impending congestion (according to a configured threshold)
both to the operator and to its PCCs. both to the operator and to its PCCs.
9.7. Other Considerations
No other management considerations arise.
10. Security Considerations 10. Security Considerations
The impact of the use of a PCE-based architecture must be considered 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 in the light of the impact that it has on the security of the
existing routing and signaling protocols and techniques in use within existing routing and signaling protocols and techniques in use within
the network. There is unlikely to be any impact on intra-domain the network. There is unlikely to be any impact on intra-domain
security, but an increase in inter-domain information flows and the security, but an increase in inter-domain information flows and the
facilitation of inter-domain path establishment may increase the facilitation of inter-domain path establishment may increase the
vulnerability to security attacks. vulnerability to security attacks.
skipping to change at page 29, line 53 skipping to change at page 35, line 21
Applicability statements for particular combinations of signaling, Applicability statements for particular combinations of signaling,
routing and path computation techniques are expected to contain routing and path computation techniques are expected to contain
detailed security sections. detailed security sections.
It should be observed that the use of a non-local PCE (that is, not It should be observed that the use of a non-local PCE (that is, not
co-resident with the PCC) does introduce additional security issues. co-resident with the PCC) does introduce additional security issues.
Most notable amongst these are: Most notable amongst these are:
- Interception of PCE requests or responses - Interception of PCE requests or responses
- Impersonation of PCE - Impersonation of PCE, or PCC
- Falsification of TE information, policy information or PCE
capabilities
- Falsification of TE information
- Denial of service attacks on PCE or PCE communication mechanisms. - Denial of service attacks on PCE or PCE communication mechanisms.
It is expected that PCE solutions will address these issues in detail It is expected that PCE solutions will address these issues in detail
using authentication and security techniques. using authentication and security techniques.
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, Takao Shimizu, and Raymond Zhang for their review and
suggestions. suggestions. Lou Berger provided valuable and 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 30, line 46 skipping to change at page 36, line 18
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
14. Normative References 14. Informational References
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004.
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
15. Informational References
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and
J. McManus, "Requirements for Traffic Engineering over J. McManus, "Requirements for Traffic Engineering over
MPLS", RFC 2702, September 1999. MPLS", RFC 2702, September 1999.
[RFC2547] Rosen, E. and Rekhter, Y. "BGP/MPLS VPNs", RFC 2547, [RFC2547] Rosen, E. and Rekhter, Y. "BGP/MPLS VPNs", RFC 2547,
March 1999. March 1999.
[RFC3209] Awduche, D., et. all, "Extensions to RSVP for LSP [RFC3209] Awduche, D., et. all, "Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
skipping to change at page 31, line 38 skipping to change at page 36, line 51
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Traffic "Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) Management Information Base (MIB)", Engineering (TE) Management Information Base (MIB)",
RFC 3812, June 2004. RFC 3812, June 2004.
[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.
[INTER-AS] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic [RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic
Engineering requirements", Engineering requirements", RFC 4216, November 2005.
draft-ietf-tewg-interas-mpls-te-req, work in progress.
[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-shiomoto-ccamp-gmpls-mrn-reqs, work in progress.
16. 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
Boxborough , MA - 01719 Boxborough , MA - 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
Jerry Ash Jerry Ash
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: +1-(732)-420-4578 Phone: (732)-420-4578
Fax: +1-(732)-368-8659 Fax: (732)-368-8659
Email: gash@att.com Email: gash@att.com
17. Full Copyright Statement 16. Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2005). 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
 End of changes. 54 change blocks. 
158 lines changed or deleted 373 lines changed or added

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