draft-ietf-pce-global-concurrent-optimization-03.txt   draft-ietf-pce-global-concurrent-optimization-04.txt 
Network Working Group Y. Lee Network Working Group Y. Lee
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track JL. Le Roux Intended status: Standards Track JL. Le Roux
Expires: December 26, 2008 France Telecom Expires: January 15, 2009 France Telecom
D. King D. King
Aria Networks Old Dog Consulting
E. Oki E. Oki
NTT NTT
June 24, 2008 July 14, 2008
Path Computation Element Communication Protocol (PCECP) Requirements and Path Computation Element Communication Protocol (PCECP) Requirements and
Protocol Extensions In Support of Global Concurrent Optimization Protocol Extensions In Support of Global Concurrent Optimization
draft-ietf-pce-global-concurrent-optimization-03.txt draft-ietf-pce-global-concurrent-optimization-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 26, 2008. This Internet-Draft will expire on January 15, 2009.
Abstract Abstract
The Path Computation Element (PCE) is a network component, The Path Computation Element (PCE) is a network component,
application, or node that is capable of performing path computations application, or node that is capable of performing path computations
at the request of Path Computation Clients (PCCs). The PCE is at the request of Path Computation Clients (PCCs). The PCE is
applied in Multiprotocol Label Switching Traffic Engineering applied in Multiprotocol Label Switching Traffic Engineering
(MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to
determine the routes of Label Switched Paths (LSPs) through the determine the routes of Label Switched Paths (LSPs) through the
network. The Path Computation Element Communication Protocol (PCEP) network. In this context a PCC may be a Label Switching Router
is specified for communications between PCCs and PCEs, and between (LSR), a Network Management System (NMS), or another PCE. The Path
cooperating PCEs. Computation Element Communication Protocol (PCEP) is specified for
communications between PCCs and PCEs, and between cooperating PCEs.
When computing or re-optimizing the routes of a set of LSPs through a When computing or re-optimizing the routes of a set of LSPs through a
network it may be advantageous to perform bulk path computations in network it may be advantageous to perform bulk path computations in
order to avoid blocking problems and to achieve more optimal network- order to avoid blocking problems and to achieve more optimal network-
wide solutions. Such bulk optimization is termed Global Concurrent wide solutions. Such bulk optimization is termed Global Concurrent
Optimization (GCO). A GCO is able to simultaneously consider the Optimization (GCO). A GCO is able to simultaneously consider the
entire topology of the network and the complete set of existing LSPs, entire topology of the network and the complete set of existing LSPs,
and their respective constraints, and look to optimize or re-optimize and their respective constraints, and look to optimize or re-optimize
the entire network to satisfy all constraints for all LSPs. A GCO the entire network to satisfy all constraints for all LSPs. A GCO
may also be applied to some subset of the LSPs in a network. The GCO may also be applied to some subset of the LSPs in a network. The GCO
application is primarily a Network Management System (NMS) solution. application is primarily a Network Management System (NMS) solution.
While GCO is applicable to any simultaneous request for multiple LSPs
(for example, a request for end-to-end protection), it is not
invisaged that global concurrent reoptimization would be applied in a
network (such as an MPLS-TE network) that contains a very large
number of very low bandwidth or zero bandwidth LSPs since the large
scope of the problem and the small benefit of concurrent
reoptimization relative to single LSP reoptimization is unlikely to
make the process worthwhile. Further, applying global concurrent
reoptimization in a network with a high rate of change of LSPs
(churn) is not advised because of the likelihood that LSPs would
change before they could be gloablly reoptimized. Global
reoptimization is more applicable to stable networks such as
transport networks or those with long-term TE LSP tunnels.
This document provides application-specific requirements and the PCEP This document provides application-specific requirements and the PCEP
extensions in support of GCO applications. extensions in support of GCO applications.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Applicability of Global Concurrent Optimization (GCO) . . . . 7 3. Applicability of Global Concurrent Optimization (GCO) . . . . 7
3.1. Application of the PCE Architecture . . . . . . . . . . . 7 3.1. Application of the PCE Architecture . . . . . . . . . . . 7
3.2. Re-optimization of Existing Networks . . . . . . . . . . . 8 3.2. Greenfield Optimization . . . . . . . . . . . . . . . . . 8
3.2.1. Reconfiguration of the Virtual Network Topology 3.2.1. Single-layer Traffic Engineering . . . . . . . . . . . 8
(VNT) . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. Multi-layer Traffic Engineering . . . . . . . . . . . 8
3.2.2. Traffic Migration . . . . . . . . . . . . . . . . . . 8 3.3. Re-optimization of Existing Networks . . . . . . . . . . . 8
3.3. Greenfield Optimization . . . . . . . . . . . . . . . . . 9 3.3.1. Reconfiguration of the Virtual Network Topology
3.3.1. Single-layer Traffic Engineering . . . . . . . . . . . 10 (VNT) . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2. Multi-layer Traffic Engineering . . . . . . . . . . . 10 3.3.2. Traffic Migration . . . . . . . . . . . . . . . . . . 9
4. PCECP Requirements . . . . . . . . . . . . . . . . . . . . . . 11 4. PCECP Requirements . . . . . . . . . . . . . . . . . . . . . . 11
5. Protocol extensions for support of global concurrent 5. Protocol Extensions for Support of Global Concurrent
optimization . . . . . . . . . . . . . . . . . . . . . . . . . 15 Optimization . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Global Objective Function (GOF) Specification . . . . . . 15 5.1. Global Objective Function (GOF) Specification . . . . . . 15
5.2. Indication of Global Concurrent Optimization Requests . . 16 5.2. Indication of Global Concurrent Optimization Requests . . 16
5.3. Request for the order of LSP . . . . . . . . . . . . . . . 16 5.3. Request for The Order of LSP . . . . . . . . . . . . . . . 16
5.4. The Order Response . . . . . . . . . . . . . . . . . . . . 17 5.4. The Order Response . . . . . . . . . . . . . . . . . . . . 17
5.5. GLOBAL CONSTRAINTS (GC) Object . . . . . . . . . . . . . . 18 5.5. GLOBAL CONSTRAINTS (GC) Object . . . . . . . . . . . . . . 18
5.6. Error Indicator . . . . . . . . . . . . . . . . . . . . . 19 5.6. Error Indicator . . . . . . . . . . . . . . . . . . . . . 19
5.7. NO-PATH Indicator . . . . . . . . . . . . . . . . . . . . 20 5.7. NO-PATH Indicator . . . . . . . . . . . . . . . . . . . . 20
6. Manageability Considerations . . . . . . . . . . . . . . . . . 21 6. Manageability Considerations . . . . . . . . . . . . . . . . . 21
6.1. Control of Function and Policy . . . . . . . . . . . . . . 21 6.1. Control of Function and Policy . . . . . . . . . . . . . . 21
6.2. Information and Data Models, e.g. MIB module . . . . . . . 21 6.2. Information and Data Models, e.g. MIB module . . . . . . . 21
6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21
6.4. Verifying Correct Operation . . . . . . . . . . . . . . . 21 6.4. Verifying Correct Operation . . . . . . . . . . . . . . . 21
6.5. Requirements on Other Protocols and Functional 6.5. Requirements on Other Protocols and Functional
skipping to change at page 4, line 9 skipping to change at page 4, line 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 30
1. Introduction 1. Introduction
[RFC4655] defines the Path Computation Element (PCE) based [RFC4655] defines the Path Computation Element (PCE) based
Architecture and explains how a PCE may compute Label Switched Paths Architecture and explains how a PCE may compute Label Switched Paths
(LSP) in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) (LSPs) in Multiprotocol Label Switching Traffic Engineering (MPLS-TE)
and Generalized MPLS (GMPLS) networks at the request of Path and Generalized MPLS (GMPLS) networks at the request of Path
Computation Clients (PCCs). A PCC is shown to be any network Computation Clients (PCCs). A PCC is shown to be any network
component that makes such a request and may be for instance a Label component that makes such a request and may be for instance a Label
Switching Router (LSR) or a Network Management System (NMS). The Switching Router (LSR) or a Network Management System (NMS). The
PCE, itself, is shown to be located anywhere within the network, and PCE, itself, is shown to be located anywhere within the network, and
may be within an LSR, an NMS or Operational Support System (OSS), or may be within an LSR, an NMS or Operational Support System (OSS), or
may be an independent network server. may be an independent network server.
The PCE Communication Protocol (PCEP) is the communication protocol The PCE Communication Protocol (PCEP) is the communication protocol
used between PCC and PCE, and may also be used between cooperating used between PCC and PCE, and may also be used between cooperating
skipping to change at page 4, line 46 skipping to change at page 4, line 46
architecture defined in section 5.5 of [RFC4655] is considered as the architecture defined in section 5.5 of [RFC4655] is considered as the
most suitable usage to support GCO application. This does not most suitable usage to support GCO application. This does not
preclude other architectural alternatives to support GCO application, preclude other architectural alternatives to support GCO application,
but they are NOT RECOMMENDED. For instance, GCO might be enabled by but they are NOT RECOMMENDED. For instance, GCO might be enabled by
distributed LSRs through complex synchronization mechanisms. distributed LSRs through complex synchronization mechanisms.
However, this approach might suffer from significant synchronization However, this approach might suffer from significant synchronization
overhead between the PCE and each of the PCCs. It would likely overhead between the PCE and each of the PCCs. It would likely
affect the network stability and hence significantly diminish the affect the network stability and hence significantly diminish the
benefits of deploying PCEs. benefits of deploying PCEs.
The need for global concurrent path computation may also arise when
network operators need to establish a set of TE LSPs in their network
planning process. It is also envisioned that network operators might
require global concurrent path computation in the event of
catastrophic network failures, where a set of TE LSPs need to be
optimally rerouted. The nature of this work promote the use of such
systems for offline processing. Online application of this work
should only be considered with proven empirical validation.
As new LSPs are added or removed from the network over time, the As new LSPs are added or removed from the network over time, the
global network resources become fragmented and the existing placement global network resources become fragmented and the existing placement
of LSPs within network no longer provides optimal use of the of LSPs within network no longer provides optimal use of the
available capacity. A global concurrent path computation is able to available capacity. A global concurrent path computation is able to
simultaneously consider the entire topology of the network and the simultaneously consider the entire topology of the network and the
complete set of existing LSPs and their respective constraints, and complete set of existing LSPs and their respective constraints, and
look to re-optimize the entire network to satisfy all constraints for look to re-optimize the entire network to satisfy all constraints for
all LSPs. Alternatively, the application may consider a subset of all LSPs. Alternatively, the application may consider a subset of
the LSPs and/or a subset of the network topology. the LSPs and/or a subset of the network topology.
The need for global concurrent path computation may also arise when While GCO is applicable to any simultaneous request for multiple LSPs
network operators need to establish a set of TE LSPs in their network (for example, a request for end-to-end protection), it is not
planning process. It is also envisioned that network operators might invisaged that global concurrent reoptimization would be applied in a
require global concurrent path computation in the event of network (such as an MPLS-TE network) that contains a very large
catastrophic network failures, where a set of TE LSPs need to be number of very low bandwidth or zero bandwidth LSPs since the large
optimally rerouted. The nature of this work promote the use of such scope of the problem and the small benefit of concurrent
systems for offline processing. Online application of this work reoptimization relative to single LSP reoptimization is unlikely to
should only be considered with proven empirical validation. make the process worthwhile. Further, applying global concurrent
reoptimization in a network with a high rate of change of LSPs
(churn) is not advised because of the likelihood that LSPs would
change before they could be gloablly reoptimized. Global
reoptimization is more applicable to stable networks such as
transport networks or those with long-term TE LSP tunnels.
As the PCE has the potential to provide solutions in all path As the PCE has the potential to provide solutions in all path
computation solutions in a variety of environments and is a candidate computation solutions in a variety of environments and is a candidate
for performing path computations in support of GCO. for performing path computations in support of GCO.
The main focus of this document is to highlight the PCC-PCE The main focus of this document is to highlight the PCC-PCE
communication needs in support of a concurrent path computation communication needs in support of a concurrent path computation
applications and to define protocol extensions to meet those needs. applications and to define protocol extensions to meet those needs.
The PCC-PCE requirements addressed herein are specific to the context The PCC-PCE requirements addressed herein are specific to the context
where the PCE is a specialized PCE that is capable of performing where the PCE is a specialized PCE that is capable of performing
computations in support of GCO. Discovery of such capabilities might computations in support of GCO. Discovery of such capabilities might
be desirable and could be achieved through extensions to the PCE be desirable and could be achieved through extensions to the PCE
discovery mechanisms [RFC4674], [RFC5058], [RFC5059], but that is out discovery mechanisms [RFC4674], [RFC5088], [RFC5089], but that is out
of the scope of this document. of the scope of this document.
It is to be noted that BRPC [BRPC] is a multi-PCE path computation It is to be noted that Backward Recursive Path Computation (BRPC)
technique used to compute a shortest constrained inter-domain path [BRPC] is a multi-PCE path computation technique used to compute a
wheres this ID specifies a technique where a set of path computation shortest constrained inter-domain path wheres this ID specifies a
requests are bundled and send to a PCE with the objective of technique where a set of path computation requests are bundled and
"optimizing" the set of computed paths. send to a PCE with the objective of "optimizing" the set of computed
paths.
2. Terminology 2. Terminology
Most of the terminology used in this document is explained in Most of the terminology used in this document is explained in
[RFC4655]. A few key terms are repeated here for clarity. [RFC4655]. A few key terms are repeated here for clarity.
PCC: Path Computation Client: Any client application requesting a PCC: Path Computation Client: Any client application requesting a
path computation to be performed by a Path Computation Element. path computation to be performed by a Path Computation Element.
PCE: Path Computation Element: An entity (component, application or PCE: Path Computation Element: An entity (component, application or
skipping to change at page 7, line 20 skipping to change at page 7, line 20
3.1. Application of the PCE Architecture 3.1. Application of the PCE Architecture
Figure 1 shows the PCE-based network architecture as defined in Figure 1 shows the PCE-based network architecture as defined in
[RFC4655] to which GCO application is applied. It must be observed [RFC4655] to which GCO application is applied. It must be observed
that the PCC is not necessarily an LSR [RFC4655]. The GCO that the PCC is not necessarily an LSR [RFC4655]. The GCO
application is primarily an NMS-based solution in which an NMS plays application is primarily an NMS-based solution in which an NMS plays
the function of the PCC. Although Figure 1 shows the PCE as remote the function of the PCC. Although Figure 1 shows the PCE as remote
from the NMS, it might be collocated with the NMS. Note that in the from the NMS, it might be collocated with the NMS. Note that in the
collocated case there is no need for a standard communication collocated case there is no need for a standard communication
protocol, this can rely on internal APIs. protocol; this can rely on internal APIs.
----------- -----------
Application | ----- | Application | ----- |
Request | | TED | | Request | | TED | |
| | ----- | | | ----- |
v | | | v | | |
------------- Request/ | v | ------------- Request/ | v |
| PCC | Response| ----- | | PCC | Response| ----- |
| (NMS/Server)|<--------+> | PCE | | | (NMS/Server)|<--------+> | PCE | |
| | | ----- | | | | ----- |
skipping to change at page 7, line 46 skipping to change at page 7, line 46
| Head-End | Protocol | Adjacent | | Head-End | Protocol | Adjacent |
| Node |<---------->| Node | | Node |<---------->| Node |
---------- ---------- ---------- ----------
Figure 1: PCE-Based Architecture for Global Concurrent Optimization Figure 1: PCE-Based Architecture for Global Concurrent Optimization
Upon receipt of an application request (e.g., a traffic demand matrix Upon receipt of an application request (e.g., a traffic demand matrix
is provided to the NMS by the operator's network planning procedure), is provided to the NMS by the operator's network planning procedure),
the NMS requests a global concurrent path computation from the PCE. the NMS requests a global concurrent path computation from the PCE.
The PCE then computes the requested paths concurrently applying some The PCE then computes the requested paths concurrently applying some
algorithms. When the requested path computation completes, the PCE algorithms. Various algorithms and computation techniques have been
sends the resulting paths back to the NMS. The NMS then supplies the proposed to perform this function. Specification of such algorithms
head-end LSRs with a fully computed explicit path for each TE LSP or techniques is outside the scope of this document.
that needs to be established.
3.2. Re-optimization of Existing Networks When the requested path computation completes, the PCE sends the
resulting paths back to the NMS. The NMS then supplies the head-end
LSRs with a fully computed explicit path for each TE LSP that needs
to be established.
3.2. Greenfield Optimization
Greenfield optimization is a special case of GCO application when
there are no LSPs already set up in the network. The need for
greenfield optimization arises when network planner wants to make use
of a computation server to plan the LSPs that will be provisioned in
the network.
When a new TE network needs to be provisioned from a greenfield
perspective, a set of TE LSPs needs to be created based on traffic
demand, network topology, service constraints, and network resources.
In this scenario, the ability to perform concurrent computation is
desirable, or required, to utilize network resources in an optimal
manner and avoid blocking.
3.2.1. Single-layer Traffic Engineering
Greenfield optimization can be applied when layer-specific TE LSPs
need to be created from a greenfield perspective. For example, an
MPLS-TE network can be planned based on layer 3 specific traffic
demands, the network topology, and available network resources.
Greenfield optimization for single-layer traffic engineering can be
applied to optical transport networks such as SDH/Sonet, Ethernet
Transport, WDM, etc.
3.2.2. Multi-layer Traffic Engineering
Greenfield optimization is not limited to single-layer traffic
engineering. It can also be applied to multi-layer traffic
engineering [PCE-MLN]. Both the client and the server layers network
resources and topology can be considered simultaneously in setting up
a set of TE LSPs that traverse the layer boundary.
3.3. Re-optimization of Existing Networks
The need for global concurrent path computation may arise in existing The need for global concurrent path computation may arise in existing
networks. When an existing TE LSP network experiences sub-optimal networks. When an existing TE LSP network experiences sub-optimal
use of its resources, the need for re-optimization or reconfiguration use of its resources, the need for re-optimization or reconfiguration
may arise. The scope of re-optimization and reconfiguration may vary may arise. The scope of re-optimization and reconfiguration may vary
depending on particular situations. The scope of re-optimization may depending on particular situations. The scope of re-optimization may
be limited to bandwidth modification to an existing TE LSP. However, be limited to bandwidth modification to an existing TE LSP. However,
it could well be that a set of TE LSPs may need to be re-optimized it could well be that a set of TE LSPs may need to be re-optimized
concurrently. In an extreme case, the TE LSPs may need to be concurrently. In an extreme case, the TE LSPs may need to be
globally re-optimized. globally re-optimized.
In loaded networks, with large size LSPs, a sequential re- In loaded networks, with large size LSPs, a sequential re-
optimization may not produce substantial improvements in terms of optimization may not produce substantial improvements in terms of
overall network optimization. The potential for network-wide gains overall network optimization. Sequential re-optimization refers to a
from reoptimization of LSPs sequentially is dependent upon the path computation method in which to compute the re-optimized path of
network usage and size of the LSPs being optimized. However, the key one LSP at a time without giving any consideration to the other LSPs
point remains: computing the reoptimized path of one LSP at a time that need to be re-optimized in the network. The potential for
with giving no consideration to the other LSPs in the network could network-wide gains from reoptimization of LSPs sequentially is
result in sub-optimal use of network resources. This may be far more dependent upon the network usage and size of the LSPs being
visible in an optical network with a low ratio of potential LSPs per optimized. However, the key point remains: computing the reoptimized
link, and far less visible in packet networks with micro-flow LSPs. path of one LSP at a time without giving any consideration to the
other LSPs in the network could result in sub-optimal use of network
resources. This may be far more visible in an optical network with a
low ratio of potential LSPs per link, and far less visible in packet
networks with micro-flow LSPs.
With regards to applicability of GCO in the event of catastrophic With regards to applicability of GCO in the event of catastrophic
failures, there may be a real benefit in computing the paths of the failures, there may be a real benefit in computing the paths of the
LSPs as a set rather than computing new paths from the head-end LSRs LSPs as a set rather than computing new paths from the head-end LSRs
in a distributed manner. It is to be noted, however, that a in a distributed manner. GCO could prevent race condition (i.e.,
competing for the same resource from different head-end LSRs) that
may be associated with a distributed computation. However, a
centralized system will typically suffer from a slower response time centralized system will typically suffer from a slower response time
than a distributed system. than a distributed system.
3.2.1. Reconfiguration of the Virtual Network Topology (VNT) 3.3.1. Reconfiguration of the Virtual Network Topology (VNT)
Reconfiguration of the VNT [MLN-REQ] is a typical application Reconfiguration of the VNT [MLN-REQ] [PCE-MLN] is a typical
scenario where global concurrent path computation may be applicable. application scenario where global concurrent path computation may be
Triggers for VNT reconfiguration, such as traffic demand changes, applicable. Triggers for VNT reconfiguration, such as traffic demand
network failures, and topological configuration changes, may require changes, network failures, and topological configuration changes, may
a set of existing LSPs to be re-computed. require a set of existing LSPs to be re-computed.
3.2.2. Traffic Migration 3.3.2. Traffic Migration
When migrating from one set of TE LSPs to a reoptimized set of TE When migrating from one set of TE LSPs to a reoptimized set of TE
LSPs it is important that the traffic be moved without causing LSPs it is important that the traffic be moved without causing
disruption. Various techniques exist in MPLS and GMPLS, such as disruption. Various techniques exist in MPLS and GMPLS, such as
make-before-break [RFC3209], to establish the new LSPs before tearing make-before-break [RFC3209], to establish the new LSPs before tearing
down the old LSPs. When multiple LSP routes are changed according to down the old LSPs. When multiple LSP routes are changed according to
the computed results, some of the LSPs may be disrupted due to the the computed results, some of the LSPs may be disrupted due to the
resource constraints. In other words, it may prove to be impossible resource constraints. In other words, it may prove to be impossible
to perform a direct migration from the old LSPs to the new optimal to perform a direct migration from the old LSPs to the new optimal
LSPs without disrupting traffic because there are insufficient LSPs without disrupting traffic because there are insufficient
network resources to support both sets of LSPs when make-before-break network resources to support both sets of LSPs when make-before-break
is used. However, the PCE may be able to determine an order of LSP is used. However, a PCE may be able to determine a sequence of make-
rerouting actions so that make-before-break can be performed within before- break replacement of individual LSPs or small sets of LSPs so
the limited resources. that the full set of LSPs can be migrated without any disruption.
It may be the case that the reoptimization is radical. This could It may be the case that the reoptimization is radical. This could
mean that it is not possible to apply make-before-break in any order mean that it is not possible to apply make-before-break in any order
to migrate from the old LSPs to the new LSPs. In this case a to migrate from the old LSPs to the new LSPs. In this case a
migration strategy is required that may necessitate LSPs being migration strategy is required that may necessitate LSPs being
rerouted using make-before-break onto temporary paths in order to rerouted using make-before-break onto temporary paths in order to
make space for the full reoptimization. A PCE might indicate the make space for the full reoptimization. A PCE might indicate the
order in which reoptimized LSPs must be established and take over order in which reoptimized LSPs must be established and take over
from the old LSPs, and may indicate a series of different temporary from the old LSPs, and may indicate a series of different temporary
paths that must be used. Alternatively, the PCE might perform the paths that must be used. Alternatively, the PCE might perform the
skipping to change at page 9, line 35 skipping to change at page 11, line 5
The benefit of this multi-step rerouting includes minimization of The benefit of this multi-step rerouting includes minimization of
traffic discruption and optimization gain. However this approach may traffic discruption and optimization gain. However this approach may
imply some transient packets desequencing, jitter as well as control imply some transient packets desequencing, jitter as well as control
plane stress. plane stress.
Note also that during reoptimization, traffic disruption may be Note also that during reoptimization, traffic disruption may be
allowed for some LSPs carrying low priority services (e.g., Internet allowed for some LSPs carrying low priority services (e.g., Internet
traffic) and not allowed for some LSPs carrying mission critical traffic) and not allowed for some LSPs carrying mission critical
services (e.g., voice traffic). services (e.g., voice traffic).
3.3. Greenfield Optimization
Greenfield optimization is a special case of GCO application when
there is no LSP setup. Once the LSPs are setup, it is not a
greenfield. The need for greenfield arises when network planner will
want to make use of computation servers to plan the LSPs that will be
provisioned in the network.
When a new TE network needs to be provisioned from a green-field
perspective, a set of TE LSPs need to be created based on traffic
demand, network topology, service constraints, and network resources.
Under this scenario, concurrent computation ability is highly
desirable, or required, to utilize network resources in an optimal
manner and avoid blocking risks.
3.3.1. Single-layer Traffic Engineering
Greenfield optimization can be applied when layer-specific TE LSPs
need to be created from a green-field perspective. For example,
MPLS-TE network can be established based on layer 3 specific traffic
demand, network topology, and network resources. Greenfield
optimization for single-layer traffic engineering can be applied to
optical transport networks such as SDH/Sonet, Ethernet Transport,
WDM, etc.
3.3.2. Multi-layer Traffic Engineering
Greenfield optimization is not limited to single-layer traffic
engineering. It can also be applied to multi-layer traffic
engineering. Both the client and the server layers network resources
and topology can be considered simultaneously in setting up a set of
TE LSPs that traverse the layer boundary.
4. PCECP Requirements 4. PCECP Requirements
This section provides the PCECP requirements to support global This section provides the PCECP requirements to support global
concurrent path computation applications. The requirements specified concurrent path computation applications. The requirements specified
here should be regarded as application-specific requirements and are here should be regarded as application-specific requirements and are
justifiable based on the extensibility clause found in section 6.1.14 justifiable based on the extensibility clause found in section 6.1.14
of [RFC4657]: of [RFC4657]:
The PCECP MUST support the requirements specified in the The PCECP MUST support the requirements specified in the
application-specific requirements documents. The PCECP MUST also application-specific requirements documents. The PCECP MUST also
skipping to change at page 11, line 45 skipping to change at page 11, line 45
in all path computations. Note: This requirement is covered by in all path computations. Note: This requirement is covered by
"synchronized path computation" in [RFC4655] and [RFC4657]. "synchronized path computation" in [RFC4655] and [RFC4657].
However, an explicit indicator to request a global concurrent However, an explicit indicator to request a global concurrent
optimization is a new requirement. optimization is a new requirement.
o A Global Objective Function (GOF) field in which to specify the o A Global Objective Function (GOF) field in which to specify the
global objective function. The global objective function is the global objective function. The global objective function is the
overarching objective function to which all individual path overarching objective function to which all individual path
computation requests are subjected in order to find a globally computation requests are subjected in order to find a globally
optimal solution. Note that this requirement is covered by optimal solution. Note that this requirement is covered by
"synchronized objective functions" in section 5.1.7 [RFC4657]. A "synchronized objective functions" in section 5.1.7 [RFC4657] and
list of available global objective functions SHOULD include the that [PCE-OF] defined three global objective functions as follows.
A list of available global objective functions SHOULD include the
following objective functions at the minimum and SHOULD be following objective functions at the minimum and SHOULD be
expandable for future addition: expandable for future addition:
* Minimize the sum of all TE LSP costs (min cost) * Minimize aggregate Bandwidth Consumption (MBC)
* Evenly allocate the network load to achieve the most uniform * Minimize the load of the Most Loaded Link (MLL)
link utilization across all links (this can be achieved by the
following objective function: minimize max over all links * Minimize Cumulative Cost of a set of paths (MCC)
{(C(i)-A(i))/C(i)} where C(i) is the link capacity for link i
and A(i) is the total bandwidth allocated on link i.
o A Global Constraints (GC) field in which to specify the list of o A Global Constraints (GC) field in which to specify the list of
global constraints to which all the requested path computations global constraints to which all the requested path computations
should be subjected. This list SHOULD include the following should be subjected. This list SHOULD include the following
constraints at the minimum and SHOULD be expandable for future constraints at the minimum and SHOULD be expandable for future
addition: addition:
* Maximum link utilization value -- This value indicates the * Maximum link utilization value -- This value indicates the
highest possible link utilization percentage set for each link. highest possible link utilization percentage set for each link.
(Note: to avoid floating point numbers, the values should be (Note: to avoid floating point numbers, the values should be
skipping to change at page 13, line 7 skipping to change at page 13, line 6
individual path computation requests that are subject to individual path computation requests that are subject to
concurrent path computation and subject to the global objective concurrent path computation and subject to the global objective
function and all of the global constraints. Note that this function and all of the global constraints. Note that this
requirement is entirely fulfilled by the SVEC object in the PCEP requirement is entirely fulfilled by the SVEC object in the PCEP
specification [PCEP]. Since the SVEC object as defined in [PCEP] specification [PCEP]. Since the SVEC object as defined in [PCEP]
allows identifying a set of concurrent path requests, the SVEC can allows identifying a set of concurrent path requests, the SVEC can
be reused to specify all the individual concurrent path requests be reused to specify all the individual concurrent path requests
for a global concurrent optimization. for a global concurrent optimization.
o An indicator field in which to indicate the outcome of the o An indicator field in which to indicate the outcome of the
request. When the PCE could not find a feasible solution with the request. When the PCE cannot find a feasible solution with the
initial request, the reason for failure SHOULD be indicated. This initial request, the reason for failure SHOULD be indicated. This
requirement is partially covered by [RFC4657], but not in this requirement is partially covered by [RFC4657], but not in this
level of detail. The following indicators SHOULD be supported at level of detail. The following indicators SHOULD be supported at
the minimum: the minimum:
* no feasible solution found. Note that this is already covered * no feasible solution found. Note that this is already covered
in [PCEP]. in [PCEP].
* memory overflow * memory overflow
skipping to change at page 13, line 43 skipping to change at page 13, line 42
indicating to the PCE that the set of paths that will be indicating to the PCE that the set of paths that will be
provided in the response message (PCRep) has to be ordered. provided in the response message (PCRep) has to be ordered.
* In response to the "ordering" request from the PCC, the PCE * In response to the "ordering" request from the PCC, the PCE
MUST be able to indicate in the response message (PCRep) the MUST be able to indicate in the response message (PCRep) the
order in which LSPs should be reoptimized so as to minimize order in which LSPs should be reoptimized so as to minimize
traffic disruption. It should indicate for each request the traffic disruption. It should indicate for each request the
order in which the old LSP should be removed and the order in order in which the old LSP should be removed and the order in
which the new LSP should be setup. If the removal order is which the new LSP should be setup. If the removal order is
lower than the setup order this means that make-before-break lower than the setup order this means that make-before-break
cannot be done for this request. It might also be desirable to cannot be done for this request. It MAY also be desirable to
have the PCE indicate whether ordering is in fact required or have the PCE indicate whether ordering is in fact required or
not. not.
* As stated in RFC 4657, the request for a reoptimization MUST * As stated in RFC 4657, the request for a reoptimization MUST
support the inclusion of the set of previously computed paths support the inclusion of the set of previously computed paths
along with their bandwidth. This is to avoid double bandwidth along with their bandwidth. This is to avoid double bandwidth
accounting and also this allows running an algorithm that accounting and also this allows running an algorithm that
minimizes perturbation and that can compute a migration path minimizes perturbation and that can compute a migration path
(LSP setup/removal orders). This is particularly required for (LSP setup/removal orders). This is particularly required for
stateless PCEs. stateless PCEs.
* During a migration it may not be possible to do a make-before- * During a migration it may not be possible to do a make-before-
break for all existing LSPs. The request message must allow break for all existing LSPs. The request message MUST allow
indicating for each request whether make-before-break is indicating for each request whether make-before-break is
required (e.g. Voice traffic) or break-before-make is required (e.g. Voice traffic) or break-before-make is
acceptable (e.g. Internet traffic). The response message must acceptable (e.g. Internet traffic). The response message must
allow indicating LSPs for which make-before-break allow indicating LSPs for which make-before-break
reoptimization is not possible (this will be deduced from the reoptimization is not possible (this will be deduced from the
LSP setup and deletion orders). LSP setup and deletion orders).
5. Protocol extensions for support of global concurrent optimization 5. Protocol Extensions for Support of Global Concurrent Optimization
This section provides protocol extensions for support of global This section provides protocol extensions for support of global
concurrent optimization. Protocol extensions discussed in this concurrent optimization. Protocol extensions discussed in this
section are built on [PCEP]. section are built on [PCEP].
The format of a PCReq message after incorporating new requirements The format of a PCReq message after incorporating new requirements
for support of global concurrent optimization is as follows: for support of global concurrent optimization is as follows:
<PCReq Message>::=<Common Header> <PCReq Message>::=<Common Header>
[<SVEC-list>] [<SVEC-list>]
skipping to change at page 15, line 30 skipping to change at page 15, line 30
<SVEC-list>:: =<SVEC> <SVEC-list>:: =<SVEC>
[<OF>] [<OF>]
[<GC>] [<GC>]
[<XRO>] [<XRO>]
[<SVEC-list>] [<SVEC-list>]
Note that three optional objects are added, following the SVEC Note that three optional objects are added, following the SVEC
object: the OF (Objective Function) object, which is defined in object: the OF (Objective Function) object, which is defined in
[PCE-OF], the GC (Global Constraints) object, which is defined in [PCE-OF], the GC (Global Constraints) object, which is defined in
this document (section 5.5), as well as the eXclude Route Object this document (section 5.5), as well as the eXclude Route Object
(XRO) which is defined in [PCE-XRO]. Details of this change will be (XRO) which is defined in [PCE-XRO]. The placement of the OF object
(in which the global objective function is specified) in the SVEC-
list is defined in [PCE-OF]. Details of this change will be
discussed in the following sections. discussed in the following sections.
Note also that when the XRO is global to a SVEC, and F bit is set, it Note also that when the XRO is global to a SVEC, and F bit is set, it
should be allowed to specify multiple RRO objects in the PCReq SHOULD be allowed to specify multiple Reported Route Objects (RROs)
message. in the PCReq message.
5.1. Global Objective Function (GOF) Specification 5.1. Global Objective Function (GOF) Specification
The global objective function can be specified in the PCEP Objective The global objective function can be specified in the PCEP Objective
Function (OF) object, defined in [PCE-OF]. The OF object includes a Function (OF) object, defined in [PCE-OF]. The OF object includes a
16 bit Objective Function identifier. As per discussed in [PCE-OF], 16 bit Objective Function identifier. As per discussed in [PCE-OF],
objective function identifier code points are managed by IANA. objective function identifier code points are managed by IANA.
Two global objective functions defined in [PCE-OF] are used in the Three global objective functions defined in [PCE-OF] are used in the
context of GCO. context of GCO.
Function Function
Code Description Code Description
5 Minimize the load of the Most Loaded Link (MLL) 4 Minimize aggregate Bandwidth Consumption (MBC)
5 Minimize the load of the Most Loaded Link (MLL)*
6 Minimize Cumulative Cost of a set of paths (MCC) 6 Minimize Cumulative Cost of a set of paths (MCC)
* Note: This can be achieved by the following objective function: * Note: This can be achieved by the following objective function:
minimize max over all links {(C(i)-A(i))/C(i)} where C(i) is the link minimize max over all links {(C(i)-A(i))/C(i)} where C(i) is the link
capacity for link i and A(i) is the total bandwidth allocated on link capacity for link i and A(i) is the total bandwidth allocated on link
i.) i.
5.2. Indication of Global Concurrent Optimization Requests 5.2. Indication of Global Concurrent Optimization Requests
All the path requests in this application should be indicated so that All the path requests in this application should be indicated so that
the global objective function and all of the global constraints are the global objective function and all of the global constraints are
applied to each of the requested path computation. This can be applied to each of the requested path computation. This can be
indicated implicitly by placing the GCO related objects (GOF, GC or indicated implicitly by placing the GCO related objects (GOF, GC or
XRO) after the SVEC object. That is, if any of these objects follows XRO) after the SVEC object. That is, if any of these objects follows
the SVEC object in the PCReq message, all of the requested path the SVEC object in the PCReq message, all of the requested path
computations specified in the SVEC object are subject to GOF, GC or computations specified in the SVEC object are subject to GOF, GC or
XRO. XRO.
5.3. Request for the order of LSP 5.3. Request for The Order of LSP
In order to minimize disruption associated with bulk path In order to minimize disruption associated with bulk path
provisioning, the PCC may indicate to the PCE that the response MUST provisioning, the PCC may indicate to the PCE that the response MUST
be ordered. That is, the PCE has to include the order in which LSPs be ordered. That is, the PCE has to include the order in which LSPs
MUST be moved so as to minimize traffic disruption. To support such MUST be moved so as to minimize traffic disruption. To support such
indication a new flag, the D flag, is defined in the RP object as indication a new flag, the D flag, is defined in the RP object as
follows: follows:
D bit (orDer - 1 bit): when set, in a PCReq message, the requesting D bit (orDer - 1 bit): when set, in a PCReq message, the requesting
PCC requires the PCE to specify in the PCRep message the order in PCC requires the PCE to specify in the PCRep message the order in
skipping to change at page 17, line 45 skipping to change at page 17, line 47
Type: To be defined by IANA (suggested value = 5) Type: To be defined by IANA (suggested value = 5)
Length: Variable Length: Variable
Delete Order: 32 bit integer that indicates the order in which the Delete Order: 32 bit integer that indicates the order in which the
old LSP should be removed old LSP should be removed
Setup Order: 32 bit integer that indicates the order in which the new Setup Order: 32 bit integer that indicates the order in which the new
LSP should be setup LSP should be setup
The delete order should not be equal to the setup order. If the The delete order SHOULD not be equal to the setup order. If the
delete order is higher than the setup order, this means that the delete order is higher than the setup order, this means that the
reoptimization can be done in a make-before-break manner, else it reoptimization can be done in a make-before-break manner, else it
cannot be done in a make-before-break manner. cannot be done in a make-before-break manner.
For a new LSP the delete order is not applicable. The value 0 is For a new LSP the delete order is not applicable. The value 0 is
designated to specify this case. When the value of the delete order designated to specify this case. When the value of the delete order
is 0, it implies that the resulting LSP is a new LSP. is 0, it implies that the resulting LSP is a new LSP.
To illustrate, consider a network with two established requests: R1 To illustrate this, consider a network with two established LSPs: R1
with path P1 and R2 with path P2. During a reoptimization the PCE with path P1 and R2 with path P2. During a reoptimization the PCE
may provide the following ordered reply: may provide the following ordered reply:
R1, path P1', remove order 1, setup order 4 R1, path P1', remove order 1, setup order 4
R2, path P2', remove order 3, setup order 2 R2, path P2', remove order 3, setup order 2
This indicates that the NMS should do the following sequence of This indicates that the NMS should do the following sequence of
tasks: tasks:
1: Remove path P1 1: Remove path P1
2: Setup path P2' 2: Setup path P2'
3: Remove path P2 3: Remove path P2
4: Setup path P1' 4: Setup path P1'
That is, R1 is reoptimized in a break-before-make manner and R2 in a That is, R1 is reoptimized in a break-before-make manner and R2 in a
make-before-break manner. make-before-break manner.
5.5. GLOBAL CONSTRAINTS (GC) Object 5.5. GLOBAL CONSTRAINTS (GC) Object
The Global Constraints (GC) Object is used in a PCReq message to The GLOBAL CONSTRAINTS (GC) Object is used in a PCReq message to
specify the necessary global constraints that should be applied to specify the necessary global constraints that should be applied to
all individual path computations for a global concurrent path all individual path computations for a global concurrent path
optimization request. optimization request.
GLOBAL CONSTRAINT Object-Class is to be assigned by IANA (recommended GLOBAL CONSTRAINTS Object-Class is to be assigned by IANA
value=24) (recommended value=24)
GLOBAL CONSTRAINT Object-Type is to be assigned by IANA (recommended GLOBAL CONSTRAINTS Object-Type is to be assigned by IANA (recommended
value=1) value=1)
The format of the GC object body that includes the global constraints The format of the GC object body that includes the global constraints
is as follows: is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MH | MU | mU | OB | | MH | MU | mU | OB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: GC body object format Figure 3: GC body object format
skipping to change at page 20, line 7 skipping to change at page 20, line 5
To indicate errors associated with the global concurrent path To indicate errors associated with the global concurrent path
optimization request, a new Error-Type (14) and subsequent error- optimization request, a new Error-Type (14) and subsequent error-
values are defined as follows for inclusion in the PCEP-ERROR object: values are defined as follows for inclusion in the PCEP-ERROR object:
A new Error-Type (15) and subsequent error-values are defined as A new Error-Type (15) and subsequent error-values are defined as
follows: follows:
Error-Type=15 and Error-Value=1: if a PCE receives a global Error-Type=15 and Error-Value=1: if a PCE receives a global
concurrent path optimization request and the PCE is not capable of concurrent path optimization request and the PCE is not capable of
the request due to insufficient memory, the PCE MUST send a PCErr processing the request due to insufficient memory, the PCE MUST send
message with a PCEP ERROR object (Error-Type=15) and an Error-Value a PCErr message with a PCEP ERROR object (Error-Type=15) and an
(Error-Value=1). The corresponding global concurrent path Error-Value (Error-Value=1). The PCE stops processing the request.
optimization request MUST be cancelled. The corresponding global concurrent path optimization request MUST be
cancelled at the PCC.
Error-Type=15; Error-Value=2: if a PCE receives a global concurrent Error-Type=15; Error-Value=2: if a PCE receives a global concurrent
path optimization request and the PCE is not capable of global path optimization request and the PCE is not capable of global
concurrent optimization, the PCE MUST send a PCErr message with a concurrent optimization, the PCE MUST send a PCErr message with a
PCEP-ERROR Object (Error-Type=15) and an Error-Value (Error-Value=2). PCEP-ERROR Object (Error-Type=15) and an Error-Value (Error-Value=2).
The corresponding global concurrent path optimization MUST be The PCE stops processing the request. The corresponding global
cancelled. concurrent path optimization MUST be cancelled at the PCC.
To indicate an error associated with policy violation, a new error To indicate an error associated with policy violation, a new error
value "global concurrent optimization not allowed" should be added to value "global concurrent optimization not allowed" should be added to
an existing error code for policy violation (Error-Type=5) as defined an existing error code for policy violation (Error-Type=5) as defined
in [PCEP]. in [PCEP].
Error-Type=5; Error-Value=5: if a PCE receives a global concurrent Error-Type=5; Error-Value=5: if a PCE receives a global concurrent
path optimization request which is not compliant with administrative path optimization request which is not compliant with administrative
privileges (i.e., the PCE policy does not support global concurrent privileges (i.e., the PCE policy does not support global concurrent
optimization), the PCE sends a PCErr message with a PCEP-ERROR Object optimization), the PCE sends a PCErr message with a PCEP-ERROR Object
(Error-Type=5) and an Error-Value (Error-Value=5). The corresponding (Error-Type=5) and an Error-Value (Error-Value=5). The PCE stops the
global concurrent path computation MUST be cancelled. processing the request. The corresponding global concurrent path
computation MUST be cancelled at the PCC.
5.7. NO-PATH Indicator 5.7. NO-PATH Indicator
To communicate the reason(s) for not being able to find global To communicate the reason(s) for not being able to find global
concurrent path computation, the NO-PATH object can be used in the concurrent path computation, the NO-PATH object can be used in the
PCRep message. The format of the NO-PATH object body is defined in PCRep message. The format of the NO-PATH object body is defined in
[PCEP]. The object may contain a NO-PATH-VECTOR TLV to provide [PCEP]. The object may contain a NO-PATH-VECTOR TLV to provide
additional information about why a path computation has failed. additional information about why a path computation has failed.
Two new bit flags are defined to be carried in the Flags field in the Two new bit flags are defined to be carried in the Flags field in the
skipping to change at page 21, line 49 skipping to change at page 21, line 49
document. document.
6.3. Liveness Detection and Monitoring 6.3. Liveness Detection and Monitoring
Mechanisms defined in this draft does not imply any new liveness Mechanisms defined in this draft does not imply any new liveness
detection and monitoring requirements in addition to those already detection and monitoring requirements in addition to those already
listed in section 8.3 of [PCEP]. listed in section 8.3 of [PCEP].
6.4. Verifying Correct Operation 6.4. Verifying Correct Operation
Mechanisms defined in this draft does not imply any new verification Mechanisms defined in this draft do not imply any new verification
requirements in addition to those already listed in section 8.4 of requirements in addition to those already listed in section 8.4 of
[PCEP] [PCEP]
6.5. Requirements on Other Protocols and Functional Components 6.5. Requirements on Other Protocols and Functional Components
The PCE Discovery mechanisms ([ISIS PCED] and [OSPF PCED]) may be The PCE Discovery mechanisms ([RFC 5088] and [RFC 5089]) may be used
used to advertise global concurrent path computation capabilities to to advertise global concurrent path computation capabilities to PCCs.
PCCs.
6.6. Impact on Network Operation 6.6. Impact on Network Operation
Mechanisms defined in this draft does not imply any new network Mechanisms defined in this draft do not imply any new network
operation requirements in addition to those already listed in section operation requirements in addition to those already listed in section
8.6 of [PCEP]. 8.6 of [PCEP].
7. Security Considerations 7. Security Considerations
When global re-optimization is applied to an active network, it could When global re-optimization is applied to an active network, it could
be extremely disruptive. Although the real security and policy be extremely disruptive. Although the real security and policy
issues apply at the NMS, if the wrong results are returned to the issues apply at the NMS, if the wrong results are returned to the
NMS, the wrong actions may be taken in the network. Therefore, it is NMS, the wrong actions may be taken in the network. Therefore, it is
very important that the operator issuing the commands has sufficient very important that the operator issuing the commands has sufficient
skipping to change at page 27, line 12 skipping to change at page 27, line 12
6 No GCO migration path found [This.I-D] 6 No GCO migration path found [This.I-D]
7 No GCO solution found [This.I-D] 7 No GCO solution found [This.I-D]
10. References 10. References
10.1. Normative References 10.1. Normative References
[BRPC] Vasseur, JP., Ed., "A Backward Recursive PCE-based [BRPC] Vasseur, JP., Ed., "A Backward Recursive PCE-based
Computation (BRPC) procedure to compute shortest inter- Computation (BRPC) procedure to compute shortest inter-
domain Traffic Engineering Label Switched Paths, domain Traffic Engineering Label Switched Paths,
draft-ietf-pce-brpc-05.txt, work in progress". draft-ietf-pce-brpc, work in progress".
[PCE-OF] Le Roux, JL., Vasseur, JP., and Y. Lee, "Objective [PCE-OF] Le Roux, JL., Vasseur, JP., and Y. Lee, "Objective
Function encoding in Path Computation Element Function encoding in Path Computation Element
communication and discovery protocols, communication and discovery protocols,
draft-leroux-pce-of, work in progress". draft-leroux-pce-of, work in progress".
[PCE-XRO] Oki, E. and A. Farrel, "Extensions to the Path Computation [PCE-XRO] Oki, E. and A. Farrel, "Extensions to the Path Computation
Element Communication Protocol (PCEP) for Route Element Communication Protocol (PCEP) for Route
Exclusions, draft-ietf-pce-pcep-xro-00.txt, work in Exclusions, draft-ietf-pce-pcep-xro, work in progress".
progress".
[PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) communication Protocol (PCEP) - Version 1, Element (PCE) communication Protocol (PCEP) - Version 1,
draft-ietf-pce-pcep, work in progress". draft-ietf-pce-pcep, work in progress".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC5088] Le Roux, J., Vasseur, J., Ikejiri, Y., and R. Zhang, "OSPF
Element (PCE)-Based Architecture, RFC 4655, August 2006". Protocol Extensions for Path Computation Element (PCE)
Discovery, RFC 5088, January 2008.".
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements, RFC 4657,
September 2006".
[RFC4674] Le Roux, J., "Requirements for Path Computation Element [RFC5089] Le Roux, J., Vasseur, J., Ikejiri, Y., and R. Zhang,
(PCE) Discovery, RFC 4674, October 2006.". "IS-IS Protocol Extensions for Path Computation Element
(PCE) Discovery, RFC 5089, January 2008.".
10.2. Informative References 10.2. Informative References
[ISIS-PCED]
Le Roux, J. and JP. Vasseur, "IS-IS protocol extensions
for Path Computation Element (PCE) Discovery,
draft-ietf-pce-disco-proto-isis, work in progress.".
[MLN-REQ] Shiomoto, K., Ed., "Requirements for GMPLS-based multi- [MLN-REQ] Shiomoto, K., Ed., "Requirements for GMPLS-based multi-
region and multi-layer networks (MRN/MLN), region and multi-layer networks (MRN/MLN),
draft-ietf-ccamp-gmpls-mln-reqs, work in progress". draft-ietf-ccamp-gmpls-mln-reqs, work in progress".
[OSPF-PCED]
Le Roux, J. and JP. Vasseur, "OSPF protocol extensions for
Path Computation Element (PCE) Discovery,
draft-ietf-pce-disco-proto-ospf, work in progress.".
[PCE-MLN] Oki, E., Le Roux, J., and A. Farrel, "Framework for PCE- [PCE-MLN] Oki, E., Le Roux, J., and A. Farrel, "Framework for PCE-
based inter-layer MPLS and GMPL traffic engineering, based inter-layer MPLS and GMPLS traffic engineering,
draft-ietf-pce-inter-layer-frwk, work in progress.". draft-ietf-pce-inter-layer-frwk, work in progress.".
[PCEP-MIB] [PCEP-MIB]
Stephen, E. and K. Koushik, "PCE communication Stephen, E. and K. Koushik, "PCE communication
protocol(PCEP) Management Information Base, protocol(PCEP) Management Information Base,
draft-kkoushik-pce-pcep-mib, work in progress.". draft-kkoushik-pce-pcep-mib, work in progress.".
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture, RFC 4655, August 2006".
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements, RFC 4657,
September 2006".
[RFC4674] Le Roux, J., "Requirements for Path Computation Element
(PCE) Discovery, RFC 4674, October 2006.".
Authors' Addresses Authors' Addresses
Young Lee Young Lee
Huawei Huawei
1700 Alma Drive, Suite 100 1700 Alma Drive, Suite 100
Plano, TX 75075 Plano, TX 75075
US US
Phone: +1 972 509 5599 x2240 Phone: +1 972 509 5599 x2240
Fax: +1 469 229 5397 Fax: +1 469 229 5397
skipping to change at page 29, line 27 skipping to change at page 29, line 27
JL Le Roux JL Le Roux
France Telecom France Telecom
2, Avenue Pierre-Marzin 2, Avenue Pierre-Marzin
Lannion 22307 Lannion 22307
FRANCE FRANCE
Email: jeanlouis.leroux@orange-ftgroup.com Email: jeanlouis.leroux@orange-ftgroup.com
Daniel King Daniel King
Aria Networks Aria Networks
44/45 Market Place
Chippenham SN15 3HU
United Kingdom United Kingdom
Phone: +44 7790 775187 Phone:
Fax: +44 1249 446530 Fax:
Email: daniel.king@aria-networks.com Email: daniel@olddog.co.uk
Eiji Oki Eiji Oki
NTT NTT
Midori 3-9-11 Midori 3-9-11
Musashino, Tokyo 180-8585 Musashino, Tokyo 180-8585
JAPAN JAPAN
Email: oki.eiji@lab.ntt.co.jp Email: oki.eiji@lab.ntt.co.jp
Full Copyright Statement Full Copyright Statement
 End of changes. 59 change blocks. 
159 lines changed or deleted 196 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/