draft-ietf-pce-architecture-01.txt   draft-ietf-pce-architecture-02.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: January 2006 Cisco Systems, Inc. Expires: March 2006 Cisco Systems, Inc.
Jerry Ash Jerry Ash
AT&T AT&T
July 2005 September 2005
draft-ietf-pce-architecture-01.txt draft-ietf-pce-architecture-02.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 1, line 44 skipping to change at page 1, line 44
The list of Internet-Draft Shadow Directories can be The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html. accessed at http://www.ietf.org/shadow.html.
Abstract Abstract
Constraint-based path computation is a fundamental building block for Constraint-based path computation is a fundamental building block for
traffic engineering systems such as Multiprotocol Label Switching traffic engineering systems such as Multiprotocol Label Switching
(MPLS) and Generalized Multiprotocol Label Switching (GMPLS) (MPLS) and Generalized Multiprotocol Label Switching (GMPLS)
networks. Path computation in large, multi-domain, multi-region or networks. Path computation in large, multi-domain, multi-region or
multi-layer networks is highly complex and may require special multi-layer networks is complex and may require special
computational components and cooperation between the different computational components and cooperation between the different
network domains. network domains.
This document specifies the architecture for a Path Computation This document specifies the architecture for a Path Computation
Element (PCE)-based model to address this problem space. This Element (PCE)-based model to address this problem space. This
document does not attempt to provide a detailed description of all document does not attempt to provide a detailed description of all
the architectural components, but rather it describes a set of the architectural components, but rather it describes a set of
building blocks for the PCE architecture from which solutions may be building blocks for the PCE architecture from which solutions may be
constructed. constructed.
Table of Contents
1. Introduction ................................................... 3 1. Introduction ................................................... 3
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/Global Optimization ....... 6 4.1. CPU-intensive Path Computation ............................. 6
4.2. Partial Visibility ....................................... 6 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 .......................... 7 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
5. Overview of the PCE-Based Architecture ......................... 9 4.8. Non-Motivations ............................................ 9
5.1. Composite PCE Node ....................................... 9 4.8.1. The Whole Internet .................................... 9
5.2. External PCE ............................................ 10 4.8.2. Guaranteed TE LSP Establishment ....................... 9
5.3. Multiple PCE Path Computation ........................... 11 5. Overview of the PCE-Based Architecture ........................ 10
5.4. Multiple PCE Path Computation with Inter-PCE Communication 5.1. Composite PCE Node ........................................ 10
.............................................. 12 5.2. External PCE .............................................. 11
5.5. Areas for Standardization ............................... 13 5.3. Multiple PCE Path Computation ............................. 11
6. PCE Architectural Considerations .............................. 13 5.4. Multiple PCE Path Computation with Inter-PCE Communication 12
6.1. Centralized Computation Model ........................... 14 5.5. Management-Based PCE Usage ................................ 13
6.2. Distributed Computation Model ........................... 14 5.6. Areas for Standardization ................................. 14
6.3. Synchronization ......................................... 14 6. PCE Architectural Considerations .............................. 14
6.4. PCE Discovery and Load Balancing ........................ 15 6.1. Centralized Computation Model ............................. 14
6.5. Detecting PCE Liveness .................................. 16 6.2. Distributed Computation Model ............................. 15
6.6. PCC-PCE & PCE-PCE Communication ......................... 16 6.3. Synchronization ........................................... 15
6.7. PCE TED Synchronization ................................. 18 6.4. PCE Discovery and Load Balancing .......................... 16
6.8. Stateful Versus Stateless PCEs .......................... 19 6.5. Detecting PCE Liveness .................................... 17
6.9. Monitoring .............................................. 21 6.6. PCC-PCE & PCE-PCE Communication ........................... 17
6.10. Policy and Confidentiality ............................ 21 6.7. PCE TED Synchronization ................................... 18
6.11. Unsolicited Interactions ............................... 21 6.8. Stateful Versus Stateless PCEs ............................ 20
7. Evaluation Metrics ............................................ 22 6.9. Monitoring ................................................ 21
8. Manageability Considerations .................................. 23 6.10. Policy and Confidentiality .............................. 22
8.1 Information and Data Models .............................. 23 6.11. Unsolicited Interactions ................................. 23
8.2 Liveness Detection and Monitoring ........................ 24 6.12. Relationship with Crankback .............................. 23
8.3 Verifying Correct Operation .............................. 24 7. The View from the Path Computation Client ..................... 24
8.4 Requirements on Other Protocols and Functional Components 25 8. Evaluation Metrics ............................................ 25
8.5 Impact on Network Operation .............................. 25 9. Manageability Considerations .................................. 26
9. Security Considerations ....................................... 26 9.1. Control of Function and Policy ............................ 26
10. IANA Considerations .......................................... 26 9.2. Information and Data Models ............................... 26
11. Acknowledgements ............................................. 27 9.3. Liveness Detection and Monitoring ......................... 27
12. Intellectual Property Considerations ......................... 27 9.5. Verifying Correct Operation ............................... 27
13. Normative References ......................................... 27 9.5. Requirements on Other Protocols and Functional Components . 28
14. Informational References ..................................... 27 9.6. Impact on Network Operation ............................... 29
15. Authors' Addresses ........................................... 28 10. Security Considerations ...................................... 29
16. Full Copyright Statement ..................................... 29 11. IANA Considerations .......................................... 30
12. Acknowledgements ............................................. 30
13. Intellectual Property Considerations ......................... 30
14. Normative References ......................................... 30
15. Informational References ..................................... 31
16. Contact Information .......................................... 31
17. Full Copyright Statement ..................................... 32
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 highly 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.
This document describes a set of building blocks for the PCE This document describes a set of building blocks for the PCE
architecture from which solutions may be constructed. For example, it architecture from which solutions may be constructed. For example, it
discusses PCE-based implementations including composite, external, discusses PCE-based implementations including composite, external,
and multiple PCE path computation. Furthermore, it discusses and multiple PCE path computation. Furthermore, it discusses
architectural considerations including centralized computation, architectural considerations including centralized computation,
distributed computation, synchronization, PCE discovery and load distributed computation, synchronization, PCE discovery and load
balancing, detection of PCE liveness, PCC-PCE and PCE-PCE balancing, detection of PCE liveness, PCC-PCE and PCE-PCE
communication, TED synchronization, stateful and stateless PCEs, communication, TED synchronization, stateful and stateless PCEs,
monitoring, policy and confidentiality, and evaluation metrics. monitoring, policy and confidentiality, and evaluation metrics.
The model of the Internet is to distribute network functionality
(e.g., routing) within the network. PCE functionality is not intended
to contradict this model, and can be used to exactly match the model,
for example, when the PCE functionality co-exists with each LSR in
the network. PCE is also able to augment functionality in the network
where the Internet model cannot supply adequate solutions, for
example, where traffic engineering information is not exchanged
between network domains.
2. Terminology 2. Terminology
CSPF: Constraint-based Shortest Path First. CSPF: Constraint-based Shortest Path First.
LER: Label Edge Router. LER: Label Edge Router.
LSDB: Link State Database. LSDB: Link State Database.
LSP: Label Switched Path. LSP: Label Switched Path.
skipping to change at page 4, line 17 skipping to change at page 4, line 23
A Path Computation Element (PCE) is an entity that is capable of A Path Computation Element (PCE) is an entity that is capable of
computing a network path or route based on a network graph, and of computing a network path or route based on a network graph, and of
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 address management or path computation responsibility. Examples of
of domains include IGP areas, Autonomous Systems (ASs), multiple ASs domains include IGP areas, Autonomous Systems (ASs), and multiple ASs
within a service provider network, or multiple ASs across multiple within a Service Provider network. However, domains of path
service provider networks. However, 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 correlation of
topology and routing information between domains. topology and routing information between domains.
skipping to change at page 5, line 25 skipping to change at page 5, line 32
4) The PCE may or may not be located at the head-end of the path. For 4) The PCE may or may not be located at the head-end of the path. For
example, a conventional intra-domain solution is to have path example, a conventional intra-domain solution is to have path
computation performed by the head-end LSR of an MPLS TE LSP; in computation performed by the head-end LSR of an MPLS TE LSP; in
this case, the head-end LSR contains a PCE. But solutions also this case, the head-end LSR contains a PCE. But solutions also
exist where other nodes on the path must contribute to the path exist where other nodes on the path must contribute to the path
computation (for example, loose hops) making them PCEs in their computation (for example, loose hops) making them PCEs in their
own right. At the same time, the path computation may be made by own right. At the same time, the path computation may be made by
some other PCE physically distinct from the computed path. some other PCE physically distinct from the computed path.
5) The path computed by the PCE may be an "explicit PCE path" (that 5) The path computed by the PCE may be an "explicit path" (that
is, the full explicit path from start to destination, made of a is, the full explicit path from start to destination, made of a
list of strict hops) or a "strict/loose PCE path" (that is, a mix list of strict hops) or a "strict/loose path" (that is, a mix
of strict and loose hops comprising at least one loose hop of strict and loose hops comprising at least one loose hop
representing the destination), where a hop may be an abstract node representing the destination), where a hop may be an abstract node
such as an AS. such as an AS.
6) A PCE-based path computation model does not mean to be exclusive 6) A PCE-based path computation model does not mean to be exclusive
and can be used in conjunction with other path computation models. and can be used in conjunction with other path computation models.
For instance, the path of an inter-AS TE LSP may be computed using For instance, the path of an inter-AS TE LSP may be computed using
a PCE-based path computation model in some IGP areas, whereas the a PCE-based path computation model in some ASs, whereas the
set of traversed ASs may be specified by other means (not set of traversed ASs may be specified by other means (not
determined by a PCE). Furthermore, different path computation determined by a PCE). Furthermore, different path computation
models may be used for different TE LSPs. models may be used for different TE LSPs.
7) This document does not make any assumptions about the nature or 7) This document does not make any assumptions about the nature or
implementation of a PCE. A PCE could be implemented on a router, implementation of a PCE. A PCE could be implemented on a router,
an LSR, a dedicated network server, etc. Moreover, the PCE an LSR, a dedicated network server, etc. Moreover, the PCE
function is orthogonal to the forwarding capability of the node on function is orthogonal to the forwarding capability of the node on
which it is implemented. which it is implemented.
skipping to change at page 6, line 17 skipping to change at page 6, line 17
Several motivations for a PCE-based architecture (described in Several motivations for a PCE-based architecture (described in
Section 5) are listed below. This list is not meant to be exhaustive Section 5) are listed below. This list is not meant to be exhaustive
and is provided for the sake of illustration. and is provided for the sake of illustration.
It should be highlighted that the aim of this section is to provide It should be highlighted that the aim of this section is to provide
some application examples for which a PCE-based path may be suitable: some application examples for which a PCE-based path may be suitable:
this also clearly states that such a model does not aim to replace this also clearly states that such a model does not aim to replace
existing path computation models but would apply to specific existing existing path computation models but would apply to specific existing
or future situations. or future situations.
4.1. CPU-intensive Path Computation/Global Optimization As can be seen from these examples, PCE does not replace the existing
Internet model where intelligence is distributed within the network.
Instead, it builds on this model and makes use of distributed centers
of information or computational ability. PCE should not, therefore,
necessarily be seen as a centralized, "all-seeing oracle in the sky",
but as the cooperative operation of distributed functionality used to
address specific challenges such as the computation of a shortest
inter-domain constrained path.
4.1. CPU-intensive Path Computation
There are many situations where the computation of a path may be There are many situations where the computation of a path may be
highly CPU-intensive: examples of CPU-intensive path computations highly CPU-intensive: examples of CPU-intensive path computations
include the resolution of problems such as: include the resolution of problems such as:
- Global optimization in placing a set of TE LSPs within a domain so - Placing a set of TE LSPs within a domain so
as to optimize an objective function (for example, minimization of as to optimize an objective function (for example, minimization of
the maximum link utilization) the maximum link utilization)
- Multi-criteria path computation (for example, delay and link - Multi-criteria path computation (for example, delay and link
utilization, inclusion of switching capabilities, adaptation utilization, inclusion of switching capabilities, adaptation
features, encoding types and optical constraints within a GMPLS features, encoding types and optical constraints within a GMPLS
optical network) optical network)
- Computation of minimal cost Point to Multipoint trees (Steiner - Computation of minimal cost Point to Multipoint trees (Steiner
trees). trees).
In these situations, it may not be possible or desirable for a router In these situations, it may not be possible or desirable for some
to perform path computation because of the constraints on its CPU, in routers to perform path computation because of the constraints on
which case the path computation may be off-loaded to some other their CPUs, in which case the path computations may be off-loaded to
PCE(s). some other PCE(s) which may, themselves, be routers or may be
dedicated PCE servers.
4.2. Partial Visibility 4.2. Partial Visibility
There are several scenarios where the node responsible for path There are several scenarios where the node responsible for path
computation has limited visibility of the network topology to the computation has limited visibility of the network topology to the
destination. This limitation may occur, for instance, when an ingress destination. This limitation may occur, for instance, when an ingress
router attempts to establish an LSP to a destination that lies in a router attempts to establish a TE LSP to a destination that lies in a
separate domain, since TE information is not exchanged across the separate domain, since TE information is not exchanged across the
domain boundaries. In such cases, it is possible to use loose routes domain boundaries. In such cases, it is possible to use loose routes
to establish the LSP, relying on routers at the domain borders to to establish the TE LSP, relying on routers at the domain borders to
establish the next piece of the path, however, it is not possible to establish the next piece of the path, however, it is not possible to
guarantee that the optimal (shortest) path will be used, nor even guarantee that the optimal (shortest) path will be used, nor even
that a viable path will be discovered except, possibly, through that a viable path will be discovered except, possibly, through
repeated trial and error using crankback or other signaling repeated trial and error using crankback or other signaling
extensions. extensions.
This problem of inter-domain path computation may most probably be This problem of inter-domain path computation may most probably be
addressed through distributed computation with cooperation among PCEs addressed through distributed computation with cooperation among PCEs
within each of the domains, or perhaps by using a central within each of the domains, and potentially using crankback between
"all-seeing" PCE that has access to the complete set of topology the domains to dynamically resolve provisioning issues.
information. In this latter case there are challenges of scalability Alternatively, a central "all-seeing" PCE that has access to the
(both the size of the TED and the responsiveness of a single PCE complete set of topology information may be used, but in this case
handling requests for many domains) and of preservation of there are challenges of scalability(both the size of the TED and the
confidentiality when the domains belong to different Service responsiveness of a single PCE handling requests for many domains)
Providers. and of preservation of confidentiality when the domains belong to
different Service Providers.
Note that the issues described here can be further highlighted in the Note that the issues described here can be further highlighted in the
context of LSP reoptimization, or the establishment of multiple context of TE LSP reoptimization, or the establishment of multiple
diverse LSPs for protection or load sharing. diverse TE LSPs for protection or load sharing.
4.3. Absence of the TED or use of Non-TE-Enabled IGP 4.3. Absence of the TED or use of Non-TE-Enabled IGP
The traffic engineering database (TED) may be a large drain on the The traffic engineering database (TED) may be a large drain on the
resources of a network node (such as an edge router or LER) both from resources of a network node (such as an edge router or LER) both from
a memory perspective and because it may require non-negligible CPU a memory perspective and because it may require non-negligible CPU
activity to maintain. The use of a distinct PCE may be appropriate in activity to maintain. The use of a distinct PCE may be appropriate in
such circumstances, and a separate node can be used to establish and such circumstances, and a separate node can be used to establish and
maintain the TED, and to make it available for path computation. maintain the TED, and to make it available for path computation.
The IGPs run within some networks are not sufficient to build a full The IGPs run within some networks are not sufficient to build a full
TED. For example, a network may run OSPF/IS-IS without the TED. For example, a network may run OSPF/IS-IS without the
OSPF-TE/ISIS-TE extensions, or some routers in the network may not OSPF-TE/ISIS-TE extensions, or some routers in the network may not
support the TE extensions. In these cases, in order to successfully support the TE extensions. In these cases, in order to successfully
compute paths through the network, the TED must be constructed or compute paths through the network, the TED must be constructed or
supplemented through configuration action, and updated as network supplemented through configuration action, and updated as network
resources are reserved or released. Such a TED could be distributed resources are reserved or released. Such a TED could be distributed
to each router so that each router can perform path computation, or to the routers that need to perform path computation, or held
held centrally (on a distinct node that supports PCE) for centralized centrally (on a distinct node that supports PCE) for centralized
path computation. computation.
4.4. Node Outside the Routing Domain 4.4. Node Outside the Routing Domain
An LER might not be part of the routing domain for administrative An LER might not be part of the routing domain for administrative
reasons (for example, a customer-edge (CE) router connected to the reasons (for example, a customer-edge (CE) router connected to the
provider-edge (PE) router in the context of MPLS VPN [RFC2547] and provider-edge (PE) router in the context of MPLS VPN [RFC2547] and
for which it is desired to provide a CE to CE TE LSP path). for which it is desired to provide a CE to CE TE LSP path).
This scenario suggests a solution that does not involve doing This scenario suggests a solution that does not involve doing
computation on the ingress router, and that does not rely on static computation on the ingress (TE LSP head-end) router, and that does
loose hops configuration in which case optimal shortest paths could not rely on static loose hops configuration in which case optimal
not be achieved. A distinct PCE-based solution can help here. Note shortest paths could not be achieved. A distinct PCE-based solution
that the PCE in this case may, itself, provide a path that includes can help here. Note that the PCE in this case may, itself, provide a
loose hops. path that includes loose hops.
4.5. Network Element Lacks Control Plane or Routing Capability 4.5. Network Element Lacks Control Plane or Routing Capability
It is common in legacy optical networks for the network elements not It is common in legacy optical networks for the network elements not
to have a control plane or routing capability. Such network elements to have a control plane or routing capability. Such network elements
only have a data plane and a management plane, and all only have a data plane and a management plane, and all
cross-connections are made from the management plane. It is cross-connections are made from the management plane. It is
desirable in this case to run the path computation on the PCE, and desirable in this case to run the path computation on the PCE, and
send the cross-connection commands to each node on the computed path. send the cross-connection commands to each node on the computed path.
That is, the PCC would be an element of the management plane, perhaps That is, the PCC would be an element of the management plane, perhaps
residing in the NMS or OSS. residing in the NMS or OSS.
This scenario is important for ASON-capable networks, and may also be This scenario is important for ASON-capable networks, and may also be
used for interworking between GMPLS-capable and GMPLS-incapable used for interworking between GMPLS-capable and GMPLS-incapable
networks. networks.
4.6. Backup Path Computation for Bandwidth Protection 4.6. Backup Path Computation for Bandwidth Protection
A PCE can be used to compute backup paths in the context of fast A PCE can be used to compute backup paths in the context of fast
reroute protection of TE-LSPs. In this model all backup TE-LSPs reroute protection of TE LSPs. In this model all backup TE LSPs
protecting a given facility are computed in a coordinated manner by a protecting a given facility are computed in a coordinated manner by a
PCE. This allows complete bandwidth sharing between backup tunnels PCE. This allows complete bandwidth sharing between backup tunnels
protection independent elements, while avoiding any extensions to LSP protecting independent elements, while avoiding any extensions to TE
signaling. Both centralized and distributed computation models are LSP signaling. Both centralized and distributed computation models
applicable. In the distributed case each LSR can be a PCE to compute are applicable. In the distributed case each LSR can be a PCE to
the paths of backup tunnels to protect against the failure of compute the paths of backup tunnels to protect against the failure of
adjacent network links or nodes. adjacent network links or nodes.
4.7. Multi-Layer Networks 4.7. Multi-Layer Networks
A server-layer network of one switching capability may support A server-layer network of one switching capability may support
multiple networks of another (more granular) switching capability. multiple networks of another (more granular) switching capability.
For example, a TDM network may provide connectivity for client-layer For example, a TDM network may provide connectivity for client-layer
networks such as IP, MPLS or Layer 2 [MRN]. networks such as IP, MPLS or Layer 2 [MRN].
The server-layer network is unlikely to provide the same connectivity The server-layer network is unlikely to provide the same connectivity
skipping to change at page 9, line 14 skipping to change at page 9, line 26
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.1. The Whole Internet
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
set of domains with known relationships. The scale of this limitation
is similar to the peering relationships between Service Providers.
4.8.2. Guaranteed TE LSP Establishment
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
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
that no TE LSP can be established.
Back-off times, alternate path computations, and crankback can help
to mitigate this sort of problem, and PCE may also improve the
chances of successful TE LSP setup. However, a single, centralized
PCE is not viewed as a solution that can guarantee TE LSP
establishment since the potential for network failures or contention
for resources still exists where the 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 is 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
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
skipping to change at page 11, line 29 skipping to change at page 11, line 37
v v
Service ---------- Signaling ---------- Service ---------- Signaling ----------
Request| Head-End | Protocol | Adjacent | Request| Head-End | Protocol | Adjacent |
---->| Node |<---------->| Node | ---->| Node |<---------->| Node |
---------- ---------- ---------- ----------
Figure 2. External PCE Node Figure 2. External PCE Node
Note that in this case, the node that supports the PCE function may Note that in this case, the node that supports the PCE function may
also be an LSR or router performing forwarding in its own right (i.e. also be an LSR or router performing forwarding in its own right (i.e.
it may be a composit PCE node), but those functions are purely it may be a composite PCE node), but those functions are purely
orthogonal to the operation of the function in the instance being orthogonal to the operation of the function in the instance being
considered here. considered here.
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
skipping to change at page 13, line 7 skipping to change at page 13, line 7
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 distributed PCEs such that the result of the
computation performed by one PCE depends on information supplied by computation performed by one PCE depends on information supplied by
other PCEs. This model does not provide a distributed computaiton other PCEs. This model does not provide a distributed computation
algorithm, but allows distinct PCEs to be responsible for computation algorithm, but allows distinct PCEs to be responsible for computation
of parts (segments) of the path. 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.
5.5 Areas for Standardization 5.5 Management-Based PCE Usage
It must be observed that the PCC is not necessarily an LSR. For
example, in Figure 5 the NMS supplies the head-end LSR with a fully
computed explicit path for the TE LSP that it is to establish through
signaling. The NMS uses a management plane mechanism to send this
request such as the TE MIB module [RFC3812].
The NMS constructs the explicit path that it supplies to the head-end
LSR using information provided by the operator. It consults the PCE
which returns a path for the NMS to use.
Although Figure 5 shows the PCE as remote from the NMS it could, of
course, be collocated with the NMS.
-----------
| ----- |
Service | | TED |<-+------------>
Request | ----- | TED synchronization
| | | | mechanism (for example,
v | | | routing protocol)
------------- Request/ | v |
| | Response| ----- |
| NMS |<--------+->| PCE | |
| | | ----- |
------------- -----------
Service |
Request |
v
---------- Signaling ----------
| Head-End | Protocol | Adjacent |
| Node |<---------->| Node |
---------- ----------
Figure 5. Management-based PCE Usage
5.6 Areas for Standardization
The following areas require standardization within the PCE 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
- 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 and robustness of path computation models
- MIB modules related to communication protocols, routing and
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.
Note also that PCE-based path computation does not affect in any way Note also that PCE-based path computation does not affect in any way
the use of the computed paths. For example, the use of PCE does not the use of the computed paths. For example, the use of PCE does not
change the way in which Traffic Engineering LSPs are signaled, change the way in which Traffic Engineering LSPs are signaled,
maintained and torn down, but strictly relates to the path maintained and torn down, but strictly relates to the path
computation aspects of such TE LSPs. computation aspects of such TE LSPs.
This section presents an architectural view of PCE. That is, it
describes the components that exist and how they interact. Note that
the architectural model, and in particular the functional model, may
be perceived differently by different components of the PCE system.
For example, the PCC will not be aware of whether a PCE consults
other PCEs. The PCC view of the PCE architecture is discussed in
Section 7.
6.1. Centralized Computation Model 6.1. Centralized Computation Model
A "centralized computation model" considers that all path A "centralized computation model" considers that all path
computations for a given domain will be performed by a single, computations for a given domain will be performed by a single,
centralized PCE. This may be a dedicated server (for example, an centralized PCE. This may be a dedicated server (for example, an
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
skipping to change at page 14, line 42 skipping to change at page 15, line 30
for a discussion of PCE discovery which impacts on this choice. It for a discussion of PCE discovery which impacts on this choice. It
will often be the case that the computation of an individual path is 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 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 / 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 LSP. 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, the PCE will make
multiple individual path computations to generate the paths and the multiple individual path computations to generate the paths and the
PCC may send its individual requests to different PCEs. PCC may send its individual requests to different PCEs.
skipping to change at page 15, line 26 skipping to change at page 16, line 14
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 LSP using the principal path fail to should the establishment of the TE LSP using the principal path fail
complete. While alternate paths may not always be successful if the to complete. While alternate paths may not always be successful if
first path fails, including alternate paths in a PCE response could the first path fails, including alternate paths in a PCE response
have less overhead than having the PCC make separate requests for could have less overhead than having the PCC make separate requests
subsequent path computations as the need arises. This technique is for subsequent path computations as the need arises. This technique
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 The PCE architecture requires that the PCC/PCE know the location of
one or more PCEs that it can use for the computation of a path. Such one or more PCEs that it can use for the computation of a path. Such
knowledge may come through a discovery mechanism that simply relies knowledge may come through a discovery mechanism that simply relies
on local configuration, or can imply dynamic PCE discovery along with on local configuration, or can imply dynamic PCE discovery along with
various static (for example, Boolean capability) or dynamically various static (for example, Boolean capability) or dynamically
computed variables (for example, computing resources). Proxy PCE computed variables (for example, computing resources). Proxy PCE
advertisement whereby the existence of a PCE is advertised via a advertisement whereby the existence of a PCE is advertised via a
skipping to change at page 16, line 9 skipping to change at page 16, line 45
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 and out of the scope of this document.
A PCE SHOULD advertise its capabilities, such as: A PCE SHOULD advertise its capabilities, such as:
- 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
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 that dynamically learns about
PCEs available on the network to decide which of them 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 Alternatively, a PCC might ask a PCE to perform a particular type
skipping to change at page 17, line 6 skipping to change at page 17, line 41
runs in the PCC's domain. runs in the PCC's domain.
6.6. PCC-PCE & PCE-PCE Communication 6.6. PCC-PCE & PCE-PCE Communication
Once the PCC has selected a PCE, and provided that the PCE is not Once the PCC has selected a PCE, and provided that the PCE is not
local to the PCC, a request/response protocol is required for the PCC local to the PCC, a request/response protocol is required for the PCC
to communicate the path computation requests to the PCE and for the to communicate the path computation requests to the PCE and for the
PCE to return the path computation response. PCE to return the path computation response.
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
- and so on. - and so on.
skipping to change at page 18, line 7 skipping to change at page 18, line 40
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.
This may require coordination through the communication between the This may require coordination through the communication between the
PCEs. 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 resource affinities and class of service. This constraints such as costs, resource affinities and class of service.
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, and is achieved through
configuration not through protocol communications. 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:
1) Participation in IGP distribution of TE information. The standard 1) Participation in IGP distribution of TE information. The standard
method of distribution of TE information within an IGP area is method of distribution of TE information within an IGP area is
through the use of extensions to the IGP [RFC3630, RFC3748]. This through the use of extensions to the IGP [RFC3630, RFC3748]. This
mechanism allows participating nodes to build a TED, and this is mechanism allows participating nodes to build a TED, and this is
the standard technique, for example, within a single area MPLS the standard technique, for example, within a single area MPLS
network. A node that hosts the PCE function may collect TE or GMPLS network. A node that hosts the PCE function may collect
information in this way by maintaining at least one routing TE information in this way by maintaining at least one routing
adjacency with a router in the domain. The PCE node may be adjacency with a router in the domain. The PCE node may be
adjacent or non-adjacent (via some tunneling techniques) to the adjacent or non-adjacent (via some tunneling techniques) to the
router. Such a technique provides a mechanism for ensuring that router. Such a technique provides a mechanism for ensuring that
the TED is efficiently synchronized with the network state and is the TED is efficiently synchronized with the network state and is
the normal case, for example, when the PCE is co-resident with the the normal case, for example, when the PCE is co-resident with the
LSRs in an MPLS network. LSRs in an MPLS or GMPLS network.
2) Out-of-band TED synchronization. It may not be convenient or 2) Out-of-band TED synchronization. It may not be convenient or
possible for a PCE to participate in the IGPs of one or more possible for a PCE to participate in the IGPs of one or more
domains (for example, when there are very many domains, when IGP domains (for example, when there are very many domains, when IGP
participation is not desired, or when some domains are not running participation is not desired, or when some domains are not running
TE-aware IGPs). In this case some mechanism may need to be defined TE-aware IGPs). In this case some mechanism may need to be defined
to allow the PCE node to retrieve the TED from each domain. Such a to allow the PCE node to retrieve the TED from each domain. Such a
mechanism could be incremental (like the IGP in the previous mechanism could be incremental (like the IGP in the previous
case), or could involve a bulk transfer of the complete TED. The case), or could involve a bulk transfer of the complete TED. The
latter might significantly limit the capability to ensure TED latter might significantly limit the capability to ensure TED
synchronization which might result in an increase in the failure synchronization which might result in an increase in the failure
rate of computed paths. Consideration should also be given to the rate of computed paths, or the computation of sub-optimal paths.
impact of the TED distribution on the network and on the network Consideration should also be given to the impact of the TED
node within the domain that is asked to distribute the database. distribution on the network and on the network node within the
This is particularly relevant in the case of frequent network domain that is asked to distribute the database. This is
state changes. particularly relevant in the case of frequent network state
changes.
3) Information in the TED can include information obtained from 3) Information in the TED can include information obtained from
sources other than the IGP. For example, information about link sources other than the IGP. For example, information about link
usage policies can be configured by the operator. Path computation usage policies can be configured by the operator. Path computation
can also act on a far wider set of information that includes data can also act on a far wider set of information that includes data
about the LSPs provisioned within the network. This information about the TE LSPs provisioned within the network. This information
can include LSP routes, reserved bandwidth, and measured traffic can include TE LSP routes, reserved bandwidth, and measured
volume passing through the LSP. traffic volume passing through the TE LSP.
Such LSP information can enhance LSP reoptimization to provide Such TE LSP information can enhance TE LSP (re)optimization to
"full network" reoptimization, and can allow traffic fluctuations provide "full network" (re)optimization, and can allow traffic
to be taken into account. Detailed LSP information may also fluctuations to be taken into account. Detailed TE LSP information
facilitate reconfiguration of the Virtual Network Topology (VNT) may also facilitate reconfiguration of the Virtual Network
[MRN], in which lower layer LSPs such as optical paths provide TE Topology (VNT) [MRN], in which lower layer TE LSPs such as optical
links for use by the higher layer, since this reconfiguration is paths provide TE links for use by the higher layer, since this
also a "full network" problem. reconfiguration is also a "full network" problem.
Note that synchronization techniques may apply to both intra- and Note that synchronization techniques may apply to both intra- and
inter-domain TEDs. Further, the techniques can be mixed for use in inter-domain TEDs. Further, the techniques can be mixed for use in
different domains. The degree of synchronization between the PCE and different domains. The degree of synchronization between the PCE and
the network is subject to implementation and/or policy. However, the network is subject to implementation and/or policy. However,
better synchronization generally leads to paths that are more likely better synchronization generally leads to paths that are more likely
to succeed. to succeed.
It must also be highlighted that the PCE may have access to only a It must also be highlighted that the PCE may have access to only a
partial TED: for instance in the case of inter-domain path partial TED: for instance in the case of inter-domain path
computation where each such domain may be managed by different computation where each such domain may be managed by different
entities. In such cases, each PCE may have access to a partial TED entities. In such cases, each PCE may have access to a partial TED
and cooperative techniques between PCEs may be used to achieve and cooperative techniques between PCEs may be used to achieve
end-to-end path computation without any requirement for any PCE to end-to-end path computation without any requirement for any PCE to
handle the complete TED related to the set of traversed domains by handle the complete TED related to the set of traversed domains by
the LSP path in question. the TE LSP in question.
6.8. Stateful Versus Stateless PCEs 6.8. Stateful Versus Stateless PCEs
A PCE can be either stateful or stateless. In the former case, there A PCE can be either stateful or stateless. In the former case, there
is a strict synchronization between the PCE and not only the network is a strict synchronization between the PCE and not only the network
states (in term of topology and resource information), but also the states (in term of topology and resource information), but also the
set of computed paths and reserved resources in use in the network. set of computed paths and reserved resources in use in the network.
In other words, the PCE utilizes information from the TED as well as In other words, the PCE utilizes information from the TED as well as
information about existing paths (for example, TE LSPs) in the information about existing paths (for example, TE LSPs) in the
network when processing new requests. Note that although this allows network when processing new requests. Note that although this allows
for optimal path computation and increased path computation success, for optimal path computation and increased path computation success,
stateful PCEs require reliable state synchronization mechanisms, with stateful PCEs require reliable state synchronization mechanisms, with
potentially significant control plane overhead and the maintenance of potentially significant control plane overhead and the maintenance of
a large amount of data/states (for example, full mesh of TE LSPs). a large amount of data/states (for example, full mesh of TE LSPs).
For example, if there is only one PCE in the domain, all LSP For example, if there is only one PCE in the domain, all TE LSP
computation is done by this PCE, which can then track all the computation is done by this PCE, which can then track all the
existing LSPs and stay synchronized. However, this model could existing TE LSPs and stay synchronized (each TE LSP state change must
require substantial control plane resources. If there are multiple be tracked by the PCE). However, this model could require substantial
PCEs in the network, LSP computation and information is distributed control plane resources. If there are multiple PCEs in the network,
among PCEs and so the resources required to perform the computations TE LSP computation and information is distributed among PCEs and so
are also distributed. However, synchronization issues discussed in the resources required to perform the computations are also
Section 6.7 also come into play. distributed. However, synchronization issues discussed in Section 6.7
also come into play.
The maintenance of a stateful database can be non-trivial. However, The maintenance of a stateful database can be non-trivial. However,
in a single centralized PCE environment, a stateful PCE is almost a in a single centralized PCE environment, a stateful PCE is almost a
simple matter of remembering all of the LSPs the PCE has computed, simple matter of remembering all of the TE LSPs the PCE has computed,
if it can also be known that the LSPs were actually set up, and when if it can also be known that the TE LSPs were actually set up, and
they were torn down. Out-of-band TED synchronization can also be when they were torn down. Out-of-band TED synchronization can also be
complex with multiple PCE setup in a distributed PCE computation complex with multiple PCE setup in a distributed PCE computation
model, and could be prone to race conditions, scalability concerns, model, and could be prone to race conditions, scalability concerns,
etc. Even if the PCE has detailed information on all paths, etc. Even if the PCE has detailed information on all paths,
priorities, and layers, taking such information into account for path priorities, and layers, taking such information into account for path
computation could be highly complex. PCEs might synchronize state by computation could be highly complex. PCEs might synchronize state by
communicating with each other, but when LSPs are set up using communicating with each other, but when TE LSPs are set up using
distributed computation performed among several PCEs, the problem of distributed computation performed among several PCEs, the problems of
synchronization becomes larger and more complex. synchronization and race condition avoidance become larger and more
complex.
There is benefit in knowing which LSPs exist, and their routing, to There is benefit in knowing which TE LSPs exist, and their routing,
support such applications as placing a high priority LSP in a crowded to support such applications as placing a high priority TE LSP in a
network such that it preempts as few other LSPs as possible. Note crowded network such that it preempts as few other TE LSPs as
possible (also known as the "minimal perturbation" problem). Note
that preempting based on the minimum number of links might not result that preempting based on the minimum number of links might not result
in the smallest number of LSPs being disrupted. Another application in the smallest number of TE LSPs being disrupted. Another
concerns the construction and maintenance of a Virtual Network application concerns the construction and maintenance of a Virtual
Topology [MRN]. It is also helpful to understand which other LSPs Network Topology [MRN]. It is also helpful to understand which other
exist in the network in order to decide how to manage the forward TE LSPs exist in the network in order to decide how to manage the
adjacencies that exist or need to be set up. The cost-benefit of forward adjacencies that exist or need to be set up. The cost-benefit
stateful PCE computation would be helpful to determine if the benefit of stateful PCE computation would be helpful to determine if the
in path computation is sufficient to offset the additional drain on benefit in path computation is sufficient to offset the additional
the network and computational resources. drain on the network and computational resources.
Conversely, stateless PCEs do not have to remember any computed path Conversely, stateless PCEs do not have to remember any computed path
and each set of request(s) is processed independently of each other. and each set of request(s) is processed independently of each other.
For example, stateless PCEs may compute paths based on current TED For example, stateless PCEs may compute paths based on current TED
information, which could be out of sync with actual network state information, which could be out of sync with actual network state
given other recent PCE-computed paths changes. Note that a PCC may given other recent PCE-computed paths changes. Note that a PCC may
include a set of previously computed paths in its request, in order include a set of previously computed paths in its request, in order
to take them into account, for instance to avoid double bandwidth to take them into account, for instance to avoid double bandwidth
accounting, or to try to minimize changes (minimum perturbation accounting, or to try to minimize changes (minimum perturbation
problem). problem).
skipping to change at page 21, line 19 skipping to change at page 21, line 43
further enhanced to provide increased granularity and more detail to further enhanced to provide increased granularity and more detail to
cover, for example, the current bandwidth usage on certain links cover, for example, the current bandwidth usage on certain links
according to resource affinities or forwarding equivalence classes. according to resource affinities or forwarding equivalence classes.
Such information is, however, not PCE state information and so a Such information is, however, not PCE state information and so a
model that uses it is still described as stateless in the PCE model that uses it is still described as stateless in the PCE
context. context.
A limited form of statefulness might be applied within an otherwise A limited form of statefulness might be applied within an otherwise
stateful PCE. The PCE may retain some context from paths it has stateful PCE. The PCE may retain some context from paths it has
recently computed so that it avoid suggesting the use of the same recently computed so that it avoid suggesting the use of the same
resources for other LSPs. resources for other TE LSPs.
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. Policy and Confidentiality
As stated in [INTER-AS], the case of inter-provider TE LSP path As stated in [INTER-AS], 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
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
required to consider 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 (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
themselves be subject to Policy. For example, a PCE may not wish to
divulge answers or full details in response to a request from a PCE
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
this needs to form part of the protocol solutions that are developed.
6.11. Unsolicited Interactions 6.11. 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 and in this case the PCE-PCC communication could support an
"unsolicited" path computation message to supply this new path to the "unsolicited" path computation message to supply this new path to the
PCC. It should be noted, however, that this function would require PCC. It should be noted, however, that this function would require
that the PCE retained a record of previous computations and had a that the PCE retained a record of previous computations and had a
clear trigger for performing recomputations. The PCC would also need clear trigger for performing recomputations. The PCC would also need
to be able to identify the new path with the old path and determine to be able to identify the new path with the old path and determine
whether it should act on the new path. Note that the PCE-PCC whether it should act on the new path. Furthermore, the PCC should be
interaction is not a management interaction and the PCC is not able to report the outcome of such path changes to the requesting
obliged to utilize any additional path supplied by the PCE. PCE. Note that the PCE-PCC interaction is not a management
interaction and the PCC is not obliged to utilize any additional path
supplied by the PCE.
These functions fit easily within the architecture described here 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.
7. Evaluation Metrics 6.12. Relationship with Crankback
Crankback routing is a mechanism whereby a failure to establish a
path, or a failure of an existing path may be corrected by a new
path computation and fresh signaling. Crankback routing relies on the
distribution of crankback information along with the failure
notification so that the new computation can be performed avoiding
the failure or blockage point.
In the context of PCE, crankback information may be passed back to
the head-end where the process of computation and signaling can be
repeated using the failed resource as an exclusion in the computation
process. But crankback may be used to attempt to correct the
problem at intermediate points along the path. Such crankback
recomputation nodes are most likely to be domain boundaries where the
PCC had already invoked a PCE. Thus, a failure within a domain is
reported to the ingress domain boundary which will attempt to compute
an alternate path across the domain. Failing this, the problem may be
reported to the previous domain, and communicated to the ingress
boundary for that domain which may attempt to select a more
successful path either by choosing a different entry point into the
next domain, or by selecting a route through a different set of
domains.
7. The View from the Path Computation Client
The view of the PCE architecture, and particularly the functional
model, is subtly different from the PCC's perspective. This is partly
because the PCC has limited knowledge of the way in which the PCEs
cooperate to answer its requests, but depends more on the fact that
the PCC is concerned with different questions.
The PCC is interested in the following:
- Selecting a PCE that is able to promptly provide a computed path
meeting the supplied constraints.
- How many computation requests will the PCC have to send? Will the
desired path be computed by the first PCE contacted (possibly in
cooperation with other PCEs), or will the PCC have to consult other
PCEs to fill in gaps in the path?
- How many other path computations will need to be issued from within
the network in order to establish the TE LSP?
This last question might be considered to be out of scope for the
head-end LSR, but an important constraint that the PCC may wish to
apply is that the path should be computed in its entirety and
supplied without loose hops or non-simple abstract nodes.
Thus, with its limited perspective, the PCC will see Multiple PCE
Path Computation (Section 5.3) as important, and will distinguish
two subcases: the first is as shown in Figure 3 with subsequent
computation requests made by other PCCs along the path of the TE LSP;
the second having multiple computation requests issued by the
head-end LSR. On the other hand, the PCC will not be aware of
Multiple PCE Path Computation with Inter-PCE Communication (Section
5.4) which it will perceive as no different from the simple External
PCE Node case (Section 5.2).
The PCC, therefore, will be acutely aware that a Centralized PCE
Model (Section 6.1) might still require Multiple PCE Path
Computations with the head-end or subsequent PCCs required to issue
further requests to the central PCE. Conversely, the PCC may be
protected from the Distributed PCE Model (Section 6.2) by the fact
that the first PCE it consults uses inter-PCE communication to
achieve a complete computation result so that no further computation
requests are required.
These distinctions can be completely classified by determining
whether the computation response includes all necessary paths, and
whether those paths are fully explicit (that is, containing only
strict hops between simple abstract nodes).
8. Evaluation Metrics
Evaluation metrics that may be used to evaluate the efficiency and Evaluation metrics that may be used to evaluate the efficiency and
applicability of any PCE-based solution are listed below. Note that applicability of any PCE-based solution are listed below. Note that
these metrics are not being used to determine paths, but are used to these metrics are not being used to determine paths, but are used to
evaluate potential solutions to the PCE architecture. evaluate potential solutions to the PCE architecture.
- Optimality: The ability to maximize network utilization and - Optimality: The ability to maximize network utilization and
minimize cost, considering QoS objectives, multiple regions and minimize cost, considering QoS objectives, multiple regions and
network layers. Note that models that require the sequential network layers. Note that models that require the sequential
involvement of multiple PCEs (for example, the multiple PCE model involvement of multiple PCEs (for example, the multiple PCE model
described in section 5.3) have an inherent risk of lower quality described in Section 5.3) might create path loops unless careful
paths and might create path loops unless careful policy is applied. policy is applied.
- Scalability: The implications of routing, LSP signaling and PCE - Scalability: The implications of routing, TE LSP signaling and PCE
communication overhead such as the number of messages and the size communication overhead such as the number of messages and the size
of messages (includes LSAs, crankbacks, queries, distribution of messages (including LSAs, crankback information, queries,
mechanisms, etc.). distribution mechanisms, etc.).
- Load sharing: The ability to allow multiple PCEs to spread the path - Load sharing: The ability to allow multiple PCEs to spread the path
computation load by allowing multiple PCEs to each take computation load by allowing multiple PCEs to each take
responsibility for a subset of the total path computation requests. responsibility for a subset of the total path computation requests.
- Multi-path computation: The ability to compute multiple and - Multi-path computation: The ability to compute multiple and
potentially diverse paths to satisfy load-sharing of traffic and potentially diverse paths to satisfy load-sharing of traffic and
protection/restoration needs including end-to-end diversity and protection/restoration needs including end-to-end diversity and
protection within individual domains. protection within individual domains.
skipping to change at page 23, line 22 skipping to change at page 26, line 8
of new TE paths. of new TE paths.
- Ability to maintain accurate synchronization between TED and - Ability to maintain accurate synchronization between TED and
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
set of constraints cannot be found by the PCE.
- Policy: Application of Policy to the PCC-PCE and PCE-PCE
communications as well as to the computation of paths that respect
inter-domain TE LSP establishment Policies.
Note that other metrics may also be considered. Such metrics should 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).
8. Manageability Considerations 9. Manageability Considerations
The PCE architecture introduces several elements that are subject to The PCE architecture introduces several elements that are subject to
manageability. The PCE itself must be managed as must its manageability. The PCE itself must be managed as must its
communications with PCCs and other PCEs. The mechanism by which PCEs communications with PCCs and other PCEs. The mechanism by which PCEs
and PCCs discover each other are also subject to manageability. and PCCs discover each other are also subject to manageability.
Many of the issues of manageability are already covered in other Many of the issues of manageability are already covered in other
sections of this document. sections of this document.
8.1 Information and Data Models 9.1. Control of Function and Policy
It must be possible to enable and disable the PCE function at a PCE,
and this will lead to the PCE accepting, rejecting, or simply not
receiving requests from PCCs. Graceful shutdown of the PCE function
should also be considered so that in controlled circumstances (such
as software upgrade) a PCE does not just 'disappear' but warns its
PCCs and gracefully handles any queued computation requests (perhaps
by completing them, forwarding them to another PCE, or rejecting
them).
Similarly it must be possible to control the application of Policy at
the PCE through configuration. This control may include the
restriction of certain functions or algorithms, the configuration of
access rights and priorities for PCCs, and the relationships with
other PCEs both inside and outside the domain.
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. These will be and controlled through appropriate MIB modules. The tables in the new
relatively simple constructs since the relationships between PCEs and MIB modules will need to reflect the relationships between entities
PCCs are quite simple. The tables in the new MIB modules will need to and to control and report on configurable options.
reflect the relationships between entities 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
seen, and success rate of its requests. Similarly, it is important seen, and success rate of its requests. Similarly, it is important
for an operator to be able to inspect a PCE and determine its load for an operator to be able to inspect a PCE and determine its load
and whether an individual PCC is responsible for a disproportionate and whether an individual PCC is responsible for a disproportionate
amount of the load. It will also be important to be able to record amount of the load. It will also be important to be able to record
and inspect statistics about the communications between the PCC and and inspect statistics about the communications between the PCC and
PCE, including issues such as malformed messages, unauthorized PCE, including issues such as malformed messages, unauthorized
messages and messages discarded owing to congestion. In this respect messages and messages discarded owing to congestion. In this respect
there is clearly an overlap between manageability and security. there is clearly an overlap between manageability and security.
Statistics for the PCE architecture can be made available through Statistics for the PCE architecture can be made available through
appropriate tables in the new MIB modules. appropriate tables in the new MIB modules.
The new MIB modules should also be used to provide notifications The new MIB modules should also be used to provide notifications
(formerly known as traps) when key thresholds are crossed or when (formerly known as traps) when key thresholds are crossed or when
important events occur. Great care must be exercised to ensure that important events occur. Great care must be exercised to ensure that
skipping to change at page 24, line 20 skipping to change at page 27, line 30
The new MIB modules should also be used to provide notifications The new MIB modules should also be used to provide notifications
(formerly known as traps) when key thresholds are crossed or when (formerly known as traps) when key thresholds are crossed or when
important events occur. Great care must be exercised to ensure that important events occur. Great care must be exercised to ensure that
the network is not flooded with SNMP notifications. Thus it might be the network is not flooded with SNMP notifications. Thus it might be
inappropriate to issue a notification every time that a PCE receives inappropriate to issue a notification every time that a PCE receives
a request to compute a path. In any case, full control must be a request to compute a path. In any case, full control must be
provided through the MIB modules to allow notifications to be provided through the MIB modules to allow notifications to be
disabled. disabled.
8.2 Liveness Detection and Monitoring 9.3. Liveness Detection and Monitoring
Section 6.5 discusses the importance of a PCC being able to detect Section 6.5 discusses the importance of a PCC being able to detect
the liveness of a PCE. PCE-PCC communications techniques must enable the liveness of a PCE. PCE-PCC communications techniques must enable
a PCC to determine the liveness of a PCE both before it sends a a PCC to determine the liveness of a PCE both before it sends a
request and in the period between sending a request and receiving a request and in the period between sending a request and receiving a
response. response.
It is less important for a PCE to know about the liveness of PCCs, It is less important for a PCE to know about the liveness of PCCs,
and within the simple request/response model, this is only helpful: and within the simple request/response model, this is only helpful:
- to gain a predictive view of the likely loading of a PCE in the - to gain a predictive view of the likely loading of a PCE in the
future future
- to allow a PCE to abandon processing of a received request. - to allow a PCE to abandon processing of a received request.
8.3 Verifying Correct Operation 9.4. Verifying Correct Operation
Correct operation for the PCE architecture can be classified as Correct operation for the PCE architecture can be classified as
determining the correct point-to-point connectivity between PCCs and determining the correct point-to-point connectivity between PCCs and
PCEs, and assessing the validity of the computed paths. The former is PCEs, and assessing the validity of the computed paths. The former is
a security issue that may be enhanced by authentication and monitored a security issue that may be enhanced by authentication and monitored
through event logging and records as described in Section 8.1. through event logging and records as described in Section 9.1. It may
also be a routing issue to ensure that PCC-PCE connectivity is
possible.
Verifying computed paths is more complex. The information to perform Verifying computed paths is more complex. The information to perform
this function can, however, be made available to the operator through this function can, however, be made available to the operator through
MIB tables provided full records are kept of the constraints passed MIB tables provided full records are kept of the constraints passed
on the request, the path computed and provided on the response, and on the request, the path computed and provided on the response, and
any additional information supplied by the PCE such as the constraint any additional information supplied by the PCE such as the constraint
relaxation policies applied. relaxation policies applied.
8.4 Requirements on Other Protocols and Functional Components 9.5. Requirements on Other Protocols and Functional Components
At the architectural stage it is impossible to make definitive At the architectural stage it is impossible to make definitive
statements about the impact on other protocols and functional statements about the impact on other protocols and functional
components since the solutions work has not been completed. However, components since the solutions work has not been completed. However,
it is possible to make some observations. it is possible to make some observations.
- Dependence on underlying transport protocols - Dependence on underlying transport protocols
PCE-PCC communications may choose to utilize underlying protocols PCE-PCC communications may choose to utilize underlying protocols
to provide transport mechanisms. In this case some of the to provide transport mechanisms. In this case some of the
skipping to change at page 25, line 27 skipping to change at page 28, line 34
be devolved to those protocols. be devolved to those protocols.
- Re-use of existing protocols for discovery - Re-use of existing protocols for discovery
Without prejudicing the requirements and solutions work for PCE Without prejudicing the requirements and solutions work for PCE
discovery (see Section 6.4) it is possible that use will be made of discovery (see Section 6.4) it is possible that use will be made of
existing protocols to facilitate this function. In this case some existing protocols to facilitate this function. In this case some
of the manageability considerations described in the previous of the manageability considerations described in the previous
sections may be devolved to those protocols. sections may be devolved to those protocols.
- Impact on LSRs and LSP signaling - Impact on LSRs and TE LSP signaling
The primary example of a PCC identified in this architecture is an The primary example of a PCC identified in this architecture is an
MPLS LSR. Consideration must therefore be given to the MPLS or GMPLS LSR. Consideration must therefore be given to the
manageability of the LSRs and the additional manageability manageability of the LSRs and the additional manageability
constraints applicable to the LSP signaling protocols. constraints applicable to the TE LSP signaling protocols.
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 path important to be able to distinguish within an LSR whether the route
used for an LSP was supplied in a signaling message, by an used for a TE LSP was supplied in a signaling message from another
operator, or by a PCE, and in the case where it was supplied in a LSR, by an operator, or by a PCE, and in the case where it was
signaling message whether it was enhanced or expanded by a PCE. supplied in a signaling message whether it was enhanced or expanded
by a PCE.
8.5 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 LSP setup times while requests are sent to and processed It increases TE LSP setup times while requests are sent to and
by a remote PCE, and it may cause congestion within the network if a processed by a remote PCE, and it may cause congestion within the
significant number of computation requests are issued in a small network if a significant number of computation requests are issued in
period of time. These issues are most severe in busy networks and a small period of time. These issues are most severe in busy networks
after network failures although the effect may be mitigated if the and after network failures, although the effect may be mitigated if
protection paths are precomputed. the protection paths are precomputed or if the path computation load
is distributed among a set of PCEs.
Issues of potential congestion during recovery from failures may be Issues of potential congestion during recovery from failures may be
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. 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.
Of particular relevance are the implications for confidentiality Of particular relevance are the implications for confidentiality
skipping to change at page 26, line 41 skipping to change at page 30, line 4
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
- Falsification of TE information - 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.
10. IANA Considerations 11. IANA Considerations
This informational document makes no requests for IANA action. This informational document makes no requests for IANA action.
11. 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, Mohamed Boucadair, alphabetical order) Arthi Ayyangar, Zafar Ali, Lou Berger, Mohamed
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.
12. 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
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 27, line 38 skipping to change at page 30, line 46
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.
13. Normative References 14. Normative References
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004. RFC 3667, February 2004.
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF [RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004. Technology", BCP 79, RFC 3668, February 2004.
14. Informational References 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", RFC2547, [RFC2547] Rosen, E. and Rekhter, Y. "BGP/MPLS VPNs", RFC2547,
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 28, line 20 skipping to change at page 31, line 29
[RFC3473] Berger, L., et. al., "Generalized Multi-Protocol Label [RFC3473] Berger, L., et. al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation Switching (GMPLS) Signaling - Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003. RFC 3473, January 2003.
[RFC3748] Smit, H. and Li, T., "Intermediate System to [RFC3748] Smit, H. and Li, T., "Intermediate System to
Intermediate System (IS-IS) - Extensions for Traffic Intermediate System (IS-IS) - Extensions for Traffic
Engineering (TE)", RFC3784, June 2004. Engineering (TE)", RFC3784, June 2004.
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) Management Information Base (MIB)",
RFC 3812, June 2004.
[RFC4105] Le Roux, J., 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 [INTER-AS] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic
Engineering requirements", Engineering requirements",
draft-ietf-tewg-interas-mpls-te-req, work in progress. 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.
15. Authors' Addresses 16. 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
skipping to change at page 29, line 5 skipping to change at page 32, line 20
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: +1-(732)-420-4578
Fax: +1-(732)-368-8659 Fax: +1-(732)-368-8659
Email: gash@att.com Email: gash@att.com
16. Full Copyright Statement 17. 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. 83 change blocks. 
193 lines changed or deleted 440 lines changed or added

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