Network Working Group Y. Lee
Internet-Draft Huawei
Intended status: Standards Track JL. Le Roux
Expires: January 15, 2009 France Telecom
D. King
Old Dog Consulting
E. Oki
NTT
July 14, 2008
Path Computation Element Communication Protocol (PCECP) Requirements and
Protocol Extensions In Support of Global Concurrent Optimization
draft-ietf-pce-global-concurrent-optimization-04.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009.
Lee, et al. Expires January 15, 2009 [Page 1]
Internet-Draft PCE Global Concurrent Optimization July 2008
Abstract
The Path Computation Element (PCE) is a network component,
application, or node that is capable of performing path computations
at the request of Path Computation Clients (PCCs). The PCE is
applied in Multiprotocol Label Switching Traffic Engineering
(MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to
determine the routes of Label Switched Paths (LSPs) through the
network. In this context a PCC may be a Label Switching Router
(LSR), a Network Management System (NMS), or another PCE. The Path
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
network it may be advantageous to perform bulk path computations in
order to avoid blocking problems and to achieve more optimal network-
wide solutions. Such bulk optimization is termed Global Concurrent
Optimization (GCO). A GCO is able to simultaneously consider the
entire topology of the network and the complete set of existing LSPs,
and their respective constraints, and look to optimize or re-optimize
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
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
extensions in support of GCO applications.
Lee, et al. Expires January 15, 2009 [Page 2]
Internet-Draft PCE Global Concurrent Optimization July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Applicability of Global Concurrent Optimization (GCO) . . . . 7
3.1. Application of the PCE Architecture . . . . . . . . . . . 7
3.2. Greenfield Optimization . . . . . . . . . . . . . . . . . 8
3.2.1. Single-layer Traffic Engineering . . . . . . . . . . . 8
3.2.2. Multi-layer Traffic Engineering . . . . . . . . . . . 8
3.3. Re-optimization of Existing Networks . . . . . . . . . . . 8
3.3.1. Reconfiguration of the Virtual Network Topology
(VNT) . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2. Traffic Migration . . . . . . . . . . . . . . . . . . 9
4. PCECP Requirements . . . . . . . . . . . . . . . . . . . . . . 11
5. Protocol Extensions for Support of Global Concurrent
Optimization . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Global Objective Function (GOF) Specification . . . . . . 15
5.2. Indication of Global Concurrent Optimization Requests . . 16
5.3. Request for The Order of LSP . . . . . . . . . . . . . . . 16
5.4. The Order Response . . . . . . . . . . . . . . . . . . . . 17
5.5. GLOBAL CONSTRAINTS (GC) Object . . . . . . . . . . . . . . 18
5.6. Error Indicator . . . . . . . . . . . . . . . . . . . . . 19
5.7. NO-PATH Indicator . . . . . . . . . . . . . . . . . . . . 20
6. Manageability Considerations . . . . . . . . . . . . . . . . . 21
6.1. Control of Function and Policy . . . . . . . . . . . . . . 21
6.2. Information and Data Models, e.g. MIB module . . . . . . . 21
6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21
6.4. Verifying Correct Operation . . . . . . . . . . . . . . . 21
6.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 22
6.6. Impact on Network Operation . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9.1. Request Parameter Bit Flags . . . . . . . . . . . . . . . 25
9.2. New PCEP TLV . . . . . . . . . . . . . . . . . . . . . . . 25
9.3. New PCEP Object . . . . . . . . . . . . . . . . . . . . . 25
9.4. New PCEP Error Codes . . . . . . . . . . . . . . . . . . . 26
9.4.1. New Error-Values for Existing Error-Types . . . . . . 26
9.4.2. New Error-Types and Error-Values . . . . . . . . . . . 26
9.5. New No-Path Reasons . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 30
Lee, et al. Expires January 15, 2009 [Page 3]
Internet-Draft PCE Global Concurrent Optimization July 2008
1. Introduction
[RFC4655] defines the Path Computation Element (PCE) based
Architecture and explains how a PCE may compute Label Switched Paths
(LSPs) in Multiprotocol Label Switching Traffic Engineering (MPLS-TE)
and Generalized MPLS (GMPLS) networks at the request of Path
Computation Clients (PCCs). A PCC is shown to be any network
component that makes such a request and may be for instance a Label
Switching Router (LSR) or a Network Management System (NMS). The
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 an independent network server.
The PCE Communication Protocol (PCEP) is the communication protocol
used between PCC and PCE, and may also be used between cooperating
PCEs. [RFC4657] sets out generic protocol requirements for PCEP.
Additional application-specific requirements for PCEP are defined in
separate documents.
This document provides a set of requirements and PCEP extensions in
support of concurrent path computation applications. A concurrent
path computation is a path computation application where a set of TE
paths are computed concurrently in order to efficiently utilize
network resources. The computation method involved with a concurrent
path computation is referred to as global concurrent optimization in
this document. Appropriate computation algorithms to perform this
type of optimization are out of the scope of this document.
The Global Concurrent Optimization (GCO) application is primarily an
NMS or a PCE Server based solution. Owing to complex synchronization
issues associated with GCO applications, the management based PCE
architecture defined in section 5.5 of [RFC4655] is considered as the
most suitable usage to support GCO application. This does not
preclude other architectural alternatives to support GCO application,
but they are NOT RECOMMENDED. For instance, GCO might be enabled by
distributed LSRs through complex synchronization mechanisms.
However, this approach might suffer from significant synchronization
overhead between the PCE and each of the PCCs. It would likely
affect the network stability and hence significantly diminish the
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
Lee, et al. Expires January 15, 2009 [Page 4]
Internet-Draft PCE Global Concurrent Optimization July 2008
should only be considered with proven empirical validation.
As new LSPs are added or removed from the network over time, the
global network resources become fragmented and the existing placement
of LSPs within network no longer provides optimal use of the
available capacity. A global concurrent path computation is able to
simultaneously consider the entire topology of the network and the
complete set of existing LSPs and their respective constraints, and
look to re-optimize the entire network to satisfy all constraints for
all LSPs. Alternatively, the application may consider a subset of
the LSPs and/or a subset of the network topology.
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.
As the PCE has the potential to provide solutions in all path
computation solutions in a variety of environments and is a candidate
for performing path computations in support of GCO.
The main focus of this document is to highlight the PCC-PCE
communication needs in support of a concurrent path computation
applications and to define protocol extensions to meet those needs.
The PCC-PCE requirements addressed herein are specific to the context
where the PCE is a specialized PCE that is capable of performing
computations in support of GCO. Discovery of such capabilities might
be desirable and could be achieved through extensions to the PCE
discovery mechanisms [RFC4674], [RFC5088], [RFC5089], but that is out
of the scope of this document.
It is to be noted that Backward Recursive Path Computation (BRPC)
[BRPC] is a multi-PCE path computation technique used to compute a
shortest constrained inter-domain path wheres this ID specifies a
technique where a set of path computation requests are bundled and
send to a PCE with the objective of "optimizing" the set of computed
paths.
Lee, et al. Expires January 15, 2009 [Page 5]
Internet-Draft PCE Global Concurrent Optimization July 2008
2. Terminology
Most of the terminology used in this document is explained in
[RFC4655]. A few key terms are repeated here for clarity.
PCC: Path Computation Client: Any client application requesting a
path computation to be performed by a Path Computation Element.
PCE: Path Computation Element: An entity (component, application or
network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints.
TED: Traffic Engineering Database which contains the topology and
resource information of the domain. The TED may be fed by IGP
extensions or potentially by other means.
PCECP: The PCE Communication Protocol: PCECP is the generic abstract
idea of a protocol that is used to communicate path computation
requests a PCC to a PCE, and to return computed paths from the PCE to
the PCC. The PCECP can also be used between cooperating PCEs.
PCEP: The PCE communication Protocol: PCEP is the actual protocol
that implements the PCECP idea.
GCO: Global Concurrent Optimization: A concurrent path computation
application where a set of TE paths are computed concurrently in
order to efficiently utilize network resources. A GCO path
computation is able to simultaneously consider the entire topology of
the network and the complete set of existing LSPs, and their
respective constraints, and look to optimize or re-optimize the
entire network to satisfy all constraints for all LSPs. A GCO path
computation can also provide an optimal way to migrate from an
existing set of LSPs to a reoptimized set (Morphing Problem).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
These terms are also used in the parts of this document that specify
requirements for clarity of specification of those requirements.
Lee, et al. Expires January 15, 2009 [Page 6]
Internet-Draft PCE Global Concurrent Optimization July 2008
3. Applicability of Global Concurrent Optimization (GCO)
This section discusses the PCE architecture to which GCO is applied.
It also discusses various application scenarios for which global
concurrent path computation may be applied.
3.1. Application of the PCE Architecture
Figure 1 shows the PCE-based network architecture as defined in
[RFC4655] to which GCO application is applied. It must be observed
that the PCC is not necessarily an LSR [RFC4655]. The GCO
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
from the NMS, it might be collocated with the NMS. Note that in the
collocated case there is no need for a standard communication
protocol; this can rely on internal APIs.
-----------
Application | ----- |
Request | | TED | |
| | ----- |
v | | |
------------- Request/ | v |
| PCC | Response| ----- |
| (NMS/Server)|<--------+> | PCE | |
| | | ----- |
------------- -----------
Service |
Request |
v
---------- Signaling ----------
| Head-End | Protocol | Adjacent |
| Node |<---------->| Node |
---------- ----------
Figure 1: PCE-Based Architecture for Global Concurrent Optimization
Upon receipt of an application request (e.g., a traffic demand matrix
is provided to the NMS by the operator's network planning procedure),
the NMS requests a global concurrent path computation from the PCE.
The PCE then computes the requested paths concurrently applying some
algorithms. Various algorithms and computation techniques have been
proposed to perform this function. Specification of such algorithms
Lee, et al. Expires January 15, 2009 [Page 7]
Internet-Draft PCE Global Concurrent Optimization July 2008
or techniques is outside the scope of this document.
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
networks. When an existing TE LSP network experiences sub-optimal
use of its resources, the need for re-optimization or reconfiguration
may arise. The scope of re-optimization and reconfiguration may vary
depending on particular situations. The scope of re-optimization may
be limited to bandwidth modification to an existing TE LSP. However,
Lee, et al. Expires January 15, 2009 [Page 8]
Internet-Draft PCE Global Concurrent Optimization July 2008
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
globally re-optimized.
In loaded networks, with large size LSPs, a sequential re-
optimization may not produce substantial improvements in terms of
overall network optimization. Sequential re-optimization refers to a
path computation method in which to compute the re-optimized path of
one LSP at a time without giving any consideration to the other LSPs
that need to be re-optimized in the network. The potential for
network-wide gains from reoptimization of LSPs sequentially is
dependent upon the network usage and size of the LSPs being
optimized. However, the key point remains: computing the reoptimized
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
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
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
than a distributed system.
3.3.1. Reconfiguration of the Virtual Network Topology (VNT)
Reconfiguration of the VNT [MLN-REQ] [PCE-MLN] is a typical
application scenario where global concurrent path computation may be
applicable. Triggers for VNT reconfiguration, such as traffic demand
changes, network failures, and topological configuration changes, may
require a set of existing LSPs to be re-computed.
3.3.2. Traffic Migration
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
disruption. Various techniques exist in MPLS and GMPLS, such as
make-before-break [RFC3209], to establish the new LSPs before tearing
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
resource constraints. In other words, it may prove to be impossible
to perform a direct migration from the old LSPs to the new optimal
LSPs without disrupting traffic because there are insufficient
network resources to support both sets of LSPs when make-before-break
Lee, et al. Expires January 15, 2009 [Page 9]
Internet-Draft PCE Global Concurrent Optimization July 2008
is used. However, a PCE may be able to determine a sequence of make-
before- break replacement of individual LSPs or small sets of LSPs so
that the full set of LSPs can be migrated without any disruption.
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
to migrate from the old LSPs to the new LSPs. In this case a
migration strategy is required that may necessitate LSPs being
rerouted using make-before-break onto temporary paths in order to
make space for the full reoptimization. A PCE might indicate the
order in which reoptimized LSPs must be established and take over
from the old LSPs, and may indicate a series of different temporary
paths that must be used. Alternatively, the PCE might perform the
global reoptimization as a series of sub-reoptimizations by
reoptimizing subsets of the total set of LSPs.
The benefit of this multi-step rerouting includes minimization of
traffic discruption and optimization gain. However this approach may
imply some transient packets desequencing, jitter as well as control
plane stress.
Note also that during reoptimization, traffic disruption may be
allowed for some LSPs carrying low priority services (e.g., Internet
traffic) and not allowed for some LSPs carrying mission critical
services (e.g., voice traffic).
Lee, et al. Expires January 15, 2009 [Page 10]
Internet-Draft PCE Global Concurrent Optimization July 2008
4. PCECP Requirements
This section provides the PCECP requirements to support global
concurrent path computation applications. The requirements specified
here should be regarded as application-specific requirements and are
justifiable based on the extensibility clause found in section 6.1.14
of [RFC4657]:
The PCECP MUST support the requirements specified in the
application-specific requirements documents. The PCECP MUST also
allow extensions as more PCE applications will be introduced in
the future.
It is also to be noted that some of the requirements discussed in
this section have already been discussed in the PCECP requirement
document [RFC4657]. For example, Section 5.1.16 in [RFC4657]
provides a list of generic constraints while Section 5.1.17 in
[RFC4657] provides a list of generic objective functions that MUST be
supported by the PCECP. While using such generic requirements as the
baseline, this section provides application-specific requirements in
the context of global concurrent path computation and in a more
detailed level than the generic requirements.
The PCEP SHOULD support the following capabilities either via
creation of new objects and/or modification of existing objects where
applicable.
o An indicator to convey that the request is for a global concurrent
path computation. This indicator is necessary to ensure
consistency in applying global objectives and global constraints
in all path computations. Note: This requirement is covered by
"synchronized path computation" in [RFC4655] and [RFC4657].
However, an explicit indicator to request a global concurrent
optimization is a new requirement.
o A Global Objective Function (GOF) field in which to specify the
global objective function. The global objective function is the
overarching objective function to which all individual path
computation requests are subjected in order to find a globally
optimal solution. Note that this requirement is covered by
"synchronized objective functions" in section 5.1.7 [RFC4657] and
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
expandable for future addition:
* Minimize aggregate Bandwidth Consumption (MBC)
Lee, et al. Expires January 15, 2009 [Page 11]
Internet-Draft PCE Global Concurrent Optimization July 2008
* Minimize the load of the Most Loaded Link (MLL)
* Minimize Cumulative Cost of a set of paths (MCC)
o A Global Constraints (GC) field in which to specify the list of
global constraints to which all the requested path computations
should be subjected. This list SHOULD include the following
constraints at the minimum and SHOULD be expandable for future
addition:
* Maximum link utilization value -- This value indicates the
highest possible link utilization percentage set for each link.
(Note: to avoid floating point numbers, the values should be
integer values.)
* Minimum link utilization value -- This value indicates the
lowest possible link utilization percentage set for each link.
(Note: same as above)
* Overbooking Factor -- The overbooking factor allows the
reserved bandwidth to be overbooked on each link beyond its
physical capacity limit.
* Maximum number of hops for all the LSPs -- This is the largest
number of hops that any LSP can have. Note that this
constraint can also be provided on a per LSP basis (as
requested in [RFC4657] and defined in [PCEP]).
* Exclusion of links/nodes in all LSP path computation (i.e., all
LSPs should not include the specified links/nodes in their
paths). Note that this constraint can also be provided on a
per LSP basis (as requested in [RFC4657] and defined in
[PCEP]).
* An indication should be available in a path computation
response that further reoptimization may only become available
once existing traffic has been moved to the new LSPs.
o A Global Concurrent Vector (GCV) field in which to specify all the
individual path computation requests that are subject to
concurrent path computation and subject to the global objective
function and all of the global constraints. Note that this
requirement is entirely fulfilled by the SVEC object in the PCEP
specification [PCEP]. Since the SVEC object as defined in [PCEP]
allows identifying a set of concurrent path requests, the SVEC can
be reused to specify all the individual concurrent path requests
for a global concurrent optimization.
Lee, et al. Expires January 15, 2009 [Page 12]
Internet-Draft PCE Global Concurrent Optimization July 2008
o An indicator field in which to indicate the outcome of the
request. When the PCE cannot find a feasible solution with the
initial request, the reason for failure SHOULD be indicated. This
requirement is partially covered by [RFC4657], but not in this
level of detail. The following indicators SHOULD be supported at
the minimum:
* no feasible solution found. Note that this is already covered
in [PCEP].
* memory overflow
* PCE too busy. Note that this is already covered in [PCEP].
* PCE not capable of concurrent reoptimization
* no migration path available
* administrative privileges do not allow global reoptimization
o In order to minimize disruption associated with bulk path
provisioning, the following requirements MUST be supported:
* The request message MUST allow requesting the PCE to provide
the order in which LSPs should be reoptimized (i.e., the
migration path) in order to minimize traffic disruption during
the migration. That is the request message MUST allow
indicating to the PCE that the set of paths that will be
provided in the response message (PCRep) has to be ordered.
* In response to the "ordering" request from the PCC, the PCE
MUST be able to indicate in the response message (PCRep) the
order in which LSPs should be reoptimized so as to minimize
traffic disruption. It should indicate for each request the
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
lower than the setup order this means that make-before-break
cannot be done for this request. It MAY also be desirable to
have the PCE indicate whether ordering is in fact required or
not.
* As stated in RFC 4657, the request for a reoptimization MUST
support the inclusion of the set of previously computed paths
along with their bandwidth. This is to avoid double bandwidth
accounting and also this allows running an algorithm that
minimizes perturbation and that can compute a migration path
(LSP setup/removal orders). This is particularly required for
stateless PCEs.
Lee, et al. Expires January 15, 2009 [Page 13]
Internet-Draft PCE Global Concurrent Optimization July 2008
* During a migration it may not be possible to do a make-before-
break for all existing LSPs. The request message MUST allow
indicating for each request whether make-before-break is
required (e.g. Voice traffic) or break-before-make is
acceptable (e.g. Internet traffic). The response message must
allow indicating LSPs for which make-before-break
reoptimization is not possible (this will be deduced from the
LSP setup and deletion orders).
Lee, et al. Expires January 15, 2009 [Page 14]
Internet-Draft PCE Global Concurrent Optimization July 2008
5. Protocol Extensions for Support of Global Concurrent Optimization
This section provides protocol extensions for support of global
concurrent optimization. Protocol extensions discussed in this
section are built on [PCEP].
The format of a PCReq message after incorporating new requirements
for support of global concurrent optimization is as follows:
<PCReq Message>::=<Common Header>
[<SVEC-list>]
<request-list>
The <SVEC-list> is changed as follows:
<SVEC-list>:: =<SVEC>
[<OF>]
[<GC>]
[<XRO>]
[<SVEC-list>]
Note that three optional objects are added, following the SVEC
object: the OF (Objective Function) 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
(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.
Note also that when the XRO is global to a SVEC, and F bit is set, it
SHOULD be allowed to specify multiple Reported Route Objects (RROs)
in the PCReq message.
5.1. Global Objective Function (GOF) Specification
The global objective function can be specified in the PCEP Objective
Function (OF) object, defined in [PCE-OF]. The OF object includes a
16 bit Objective Function identifier. As per discussed in [PCE-OF],
objective function identifier code points are managed by IANA.
Three global objective functions defined in [PCE-OF] are used in the
context of GCO.
Lee, et al. Expires January 15, 2009 [Page 15]
Internet-Draft PCE Global Concurrent Optimization July 2008
Function
Code Description
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)
* 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
capacity for link i and A(i) is the total bandwidth allocated on link
i.
5.2. Indication of Global Concurrent Optimization Requests
All the path requests in this application should be indicated so that
the global objective function and all of the global constraints are
applied to each of the requested path computation. This can be
indicated implicitly by placing the GCO related objects (GOF, GC or
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
computations specified in the SVEC object are subject to GOF, GC or
XRO.
5.3. Request for The Order of LSP
In order to minimize disruption associated with bulk path
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
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
follows:
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
which this particular path request is to be provisioned relative to
other requests.
To support the determination of whether make-before-break
optimization is required, a new flag, the M flag, is defined in the
RP object as follows.
M bit (Make-before-break - 1 bit): when set, this indicates that a
make-before-break reoptimization is required for this request.
When M bit is not set, this implies that a break-before-make
Lee, et al. Expires January 15, 2009 [Page 16]
Internet-Draft PCE Global Concurrent Optimization July 2008
reoptimization is allowed for this request. Note that M bit can be
set only if the R (Reoptimization) flag is set.
5.4. The Order Response
The PCE MUST specify the order number in response to the Order
Request made by the PCC in the PCReq message if so requested by the
setting of the D bit in the RP object in the PCReq message. To
support such ordering indication a new optional TLV, the Order TLV,
is defined in the RP object.
The Order TLV is an optional TLV in the RP object, that indicates the
order in which the old LSP must be removed and the new LSP must be
setup during a reoptimization. It is carried in the PCRep message in
response to a reoptimization request.
The Order TLV SHOULD be included in the RP object in the PCRep
message if the D bit is set in the RP object in the PCReq message.
The format of the Order TLV is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delete Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The Order TLV in the RP object in the PCRep Message
Type: To be defined by IANA (suggested value = 5)
Length: Variable
Delete Order: 32 bit integer that indicates the order in which the
old LSP should be removed
Setup Order: 32 bit integer that indicates the order in which the new
LSP should be setup
The delete order SHOULD not be equal to the setup order. If the
Lee, et al. Expires January 15, 2009 [Page 17]
Internet-Draft PCE Global Concurrent Optimization July 2008
delete order is higher than the setup order, this means that the
reoptimization can be done in a make-before-break manner, else it
cannot be done in a make-before-break manner.
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
is 0, it implies that the resulting LSP is a new LSP.
To illustrate this, consider a network with two established LSPs: R1
with path P1 and R2 with path P2. During a reoptimization the PCE
may provide the following ordered reply:
R1, path P1', remove order 1, setup order 4
R2, path P2', remove order 3, setup order 2
This indicates that the NMS should do the following sequence of
tasks:
1: Remove path P1
2: Setup path P2'
3: Remove path P2
4: Setup path P1'
That is, R1 is reoptimized in a break-before-make manner and R2 in a
make-before-break manner.
5.5. GLOBAL CONSTRAINTS (GC) Object
The GLOBAL CONSTRAINTS (GC) Object is used in a PCReq message to
specify the necessary global constraints that should be applied to
all individual path computations for a global concurrent path
optimization request.
GLOBAL CONSTRAINTS Object-Class is to be assigned by IANA
(recommended value=24)
GLOBAL CONSTRAINTS Object-Type is to be assigned by IANA (recommended
value=1)
The format of the GC object body that includes the global constraints
is as follows:
Lee, et al. Expires January 15, 2009 [Page 18]
Internet-Draft PCE Global Concurrent Optimization July 2008
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MH | MU | mU | OB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: GC body object format
MH (Max Hop: 8 bits): 8 bit integer that indicates the maximum hop
count for all the LSPs.
MU (Max Utilization Percentage: 8 bits) : 8 bits integer that
indicates the upper bound utilization percentage by which all link
should be bound. Utilization = (Link Capacity - Allocated Bandwidth
on the Link)/ Link Capacity
mU (minimum Utilization Percentage: 8 bits) : 8 bits integer that
indicates the lower bound utilization percentage by which all link
should be bound.
OB (Over Booking factor Percentage: 8 bits) : 8 bits integer that
indicates the overbooking percentage that allows the reserved
bandwidth to be overbooked on each link beyond its physical capacity
limit. The value, for example, 10% means that 110 Mbps can be
reserved on a 100Mbps link.
Reserved bits (24 bits) of the GLOBAL CONSTRAINTS Object SHOULD be
transmitted as zero and SHOULD be ignored upon receipt.
The exclusion of the list of nodes/links from a global path
computation can be done by including the XRO object following the GC
object in the new SVEC list definition.
5.6. Error Indicator
To indicate errors associated with the global concurrent path
optimization request, a new Error-Type (14) and subsequent error-
values are defined as follows for inclusion in the PCEP-ERROR object:
A new Error-Type (15) and subsequent error-values are defined as
follows:
Error-Type=15 and Error-Value=1: if a PCE receives a global
Lee, et al. Expires January 15, 2009 [Page 19]
Internet-Draft PCE Global Concurrent Optimization July 2008
concurrent path optimization request and the PCE is not capable of
processing the request due to insufficient memory, the PCE MUST send
a PCErr message with a PCEP ERROR object (Error-Type=15) and an
Error-Value (Error-Value=1). The PCE stops processing the request.
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
path optimization request and the PCE is not capable of global
concurrent optimization, the PCE MUST send a PCErr message with a
PCEP-ERROR Object (Error-Type=15) and an Error-Value (Error-Value=2).
The PCE stops processing the request. The corresponding global
concurrent path optimization MUST be cancelled at the PCC.
To indicate an error associated with policy violation, a new error
value "global concurrent optimization not allowed" should be added to
an existing error code for policy violation (Error-Type=5) as defined
in [PCEP].
Error-Type=5; Error-Value=5: if a PCE receives a global concurrent
path optimization request which is not compliant with administrative
privileges (i.e., the PCE policy does not support global concurrent
optimization), the PCE sends a PCErr message with a PCEP-ERROR Object
(Error-Type=5) and an Error-Value (Error-Value=5). The PCE stops the
processing the request. The corresponding global concurrent path
computation MUST be cancelled at the PCC.
5.7. NO-PATH Indicator
To communicate the reason(s) for not being able to find global
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
[PCEP]. The object may contain a NO-PATH-VECTOR TLV to provide
additional information about why a path computation has failed.
Two new bit flags are defined to be carried in the Flags field in the
NO-PATH-VECTOR TLV carried in the NO-PATH Object.
Bit 6: When set, the PCE indicates that no migration path was found.
Bit 7: When set, the PCE indicates no feasible solution was found
that meets all the constraints associated with global concurrent path
optimization in the PCRep message.
Lee, et al. Expires January 15, 2009 [Page 20]
Internet-Draft PCE Global Concurrent Optimization July 2008
6. Manageability Considerations
Manageability of Global Concurrent Path Computation with PCE must
address the following considerations:
6.1. Control of Function and Policy
In addition to the parameters already listed in section 8.1 of
[PCEP], a PCEP implementation SHOULD allow configuring the following
PCEP session parameters on a PCC:
o The ability to send a GCO request.
In addition to the parameters already listed in section 8.1 of
[PCEP], a PCEP implementation SHOULD allow configuring the following
PCEP session parameters on a PCE:
o The support for Global Concurrent Optimization.
o The maximum number of synchronized path requests per request
message.
o A set of GCO specific policies (authorized sender, request rate
limiter, etc).
These parameters may be configured as default parameters for any PCEP
session the PCEP speaker participates in, or may apply to a specific
session with a given PCEP peer or a specific group of sessions with a
specific group of PCEP peers.
6.2. Information and Data Models, e.g. MIB module
Extensions to the PCEP MIB module defined in [PCEP-MIB] should be
defined, so as to cover the GCO information introduced in this
document.
6.3. Liveness Detection and Monitoring
Mechanisms defined in this draft does not imply any new liveness
detection and monitoring requirements in addition to those already
listed in section 8.3 of [PCEP].
6.4. Verifying Correct Operation
Mechanisms defined in this draft do not imply any new verification
requirements in addition to those already listed in section 8.4 of
[PCEP]
Lee, et al. Expires January 15, 2009 [Page 21]
Internet-Draft PCE Global Concurrent Optimization July 2008
6.5. Requirements on Other Protocols and Functional Components
The PCE Discovery mechanisms ([RFC 5088] and [RFC 5089]) may be used
to advertise global concurrent path computation capabilities to PCCs.
6.6. Impact on Network Operation
Mechanisms defined in this draft do not imply any new network
operation requirements in addition to those already listed in section
8.6 of [PCEP].
Lee, et al. Expires January 15, 2009 [Page 22]
Internet-Draft PCE Global Concurrent Optimization July 2008
7. Security Considerations
When global re-optimization is applied to an active network, it could
be extremely disruptive. Although the real security and policy
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
very important that the operator issuing the commands has sufficient
authority and is authenticated, and that the computation request is
subject to appropriate policy.
The mechanism defined in [PCEP] to secure a PCEP session can be used
to secure global concurrent path computation requests/responses.
Lee, et al. Expires January 15, 2009 [Page 23]
Internet-Draft PCE Global Concurrent Optimization July 2008
8. Acknowledgements
We would like to thank Jerry Ash, Adrian Farrel, J-P Vasseur, Ning
So, Lucy Yong and Fabien Verhaeghe for their useful comments and
suggestions.
Lee, et al. Expires January 15, 2009 [Page 24]
Internet-Draft PCE Global Concurrent Optimization July 2008
9. IANA Considerations
IANA maintains a registry of PCEP parameters. IANA is requested to
make allocations from the sub-registries as described in the
following sections.
9.1. Request Parameter Bit Flags
As described in Section 5.3, two new bit lfags are defined for
inclusion in the Flags field of the RP object. IANA is requested to
make the following allocations from the "Request Parameter Bit Flags"
sub-registry.
Bit Name Description Reference
11 D-bit Report the request order [This.I-D]
12 M-bit Make-before-break [This.I-D]
9.2. New PCEP TLV
As described in Section 5.4, a new PCEP TLV is defined to indicate
the setup and delete order of LSPs in a GCO. IANA is requested to
make the following allocation from the "PCEP TLV Types" sub-registry.
TLV Type Meaning Reference
5 Order TLV [This.I-D]
9.3. New PCEP Object
As descried in Section 5.5, a new PCEP object is defined to carry
global constraints. IANA is requested to make the following
allocation from the "PCEP Objects" sub-registry.
Object Name Reference
Class
24 GLOBAL-CONSTRAINTS [This.I-D]
Object-Type
1: Global Constraints [This.I-D]
Lee, et al. Expires January 15, 2009 [Page 25]
Internet-Draft PCE Global Concurrent Optimization July 2008
9.4. New PCEP Error Codes
As described in Section 5.6, new PCEP error codes are defined for GCO
errors. IANA is requested to make allocations from the "PCEP Error
Types and Values" sub-registry as set out in the following sections.
9.4.1. New Error-Values for Existing Error-Types
Error
Type Meaning Reference
5 Policy violation
Error-value=5: [This.I-D]
Global concurrent optimization not allowed
9.4.2. New Error-Types and Error-Values
Error
Type Meaning Reference
15 Global Concurrent Optimization Error [This.I-D]
Error-value=1:
Insufficient memory [This.I-D]
Error-value=2:
Global concurrent optimization not supported
[This.I-D]
9.5. New No-Path Reasons
IANA is requested to make the following allocations from the "No-Path
Reasons" sub-registry for bit flags carried in the NO-PATH-VECTOR TLV
in the PCEP NO-PATH object as described in Section 5.7.
Bit
Number Name Reference
6 No GCO migration path found [This.I-D]
7 No GCO solution found [This.I-D]
Lee, et al. Expires January 15, 2009 [Page 26]
Internet-Draft PCE Global Concurrent Optimization July 2008
10. References
10.1. Normative References
[BRPC] Vasseur, JP., Ed., "A Backward Recursive PCE-based
Computation (BRPC) procedure to compute shortest inter-
domain Traffic Engineering Label Switched Paths,
draft-ietf-pce-brpc, work in progress".
[PCE-OF] Le Roux, JL., Vasseur, JP., and Y. Lee, "Objective
Function encoding in Path Computation Element
communication and discovery protocols,
draft-leroux-pce-of, work in progress".
[PCE-XRO] Oki, E. and A. Farrel, "Extensions to the Path Computation
Element Communication Protocol (PCEP) for Route
Exclusions, draft-ietf-pce-pcep-xro, work in progress".
[PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) communication Protocol (PCEP) - Version 1,
draft-ietf-pce-pcep, work in progress".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC5088] Le Roux, J., Vasseur, J., Ikejiri, Y., and R. Zhang, "OSPF
Protocol Extensions for Path Computation Element (PCE)
Discovery, RFC 5088, January 2008.".
[RFC5089] Le Roux, J., Vasseur, J., Ikejiri, Y., and R. Zhang,
"IS-IS Protocol Extensions for Path Computation Element
(PCE) Discovery, RFC 5089, January 2008.".
10.2. Informative References
[MLN-REQ] Shiomoto, K., Ed., "Requirements for GMPLS-based multi-
region and multi-layer networks (MRN/MLN),
draft-ietf-ccamp-gmpls-mln-reqs, work in progress".
[PCE-MLN] Oki, E., Le Roux, J., and A. Farrel, "Framework for PCE-
based inter-layer MPLS and GMPLS traffic engineering,
draft-ietf-pce-inter-layer-frwk, work in progress.".
[PCEP-MIB]
Lee, et al. Expires January 15, 2009 [Page 27]
Internet-Draft PCE Global Concurrent Optimization July 2008
Stephen, E. and K. Koushik, "PCE communication
protocol(PCEP) Management Information Base,
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.".
Lee, et al. Expires January 15, 2009 [Page 28]
Internet-Draft PCE Global Concurrent Optimization July 2008
Authors' Addresses
Young Lee
Huawei
1700 Alma Drive, Suite 100
Plano, TX 75075
US
Phone: +1 972 509 5599 x2240
Fax: +1 469 229 5397
Email: ylee@huawei.com
JL Le Roux
France Telecom
2, Avenue Pierre-Marzin
Lannion 22307
FRANCE
Email: jeanlouis.leroux@orange-ftgroup.com
Daniel King
Aria Networks
United Kingdom
Phone:
Fax:
Email: daniel@olddog.co.uk
Eiji Oki
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585
JAPAN
Email: oki.eiji@lab.ntt.co.jp
Lee, et al. Expires January 15, 2009 [Page 29]
Internet-Draft PCE Global Concurrent Optimization July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Lee, et al. Expires January 15, 2009 [Page 30]
