Network Working Group Y. Lee
Internet-Draft Huawei
Intended status: Standards Track JL. Le Roux
Expires: October 27, 2007 France Telecom
D. King
Aria Networks
E. Oki
NTT
April 25, 2007
Path Computation Element Communication Protocol (PCECP) Requirements and
Protocol Extensions In Support of Global Concurrent Optimization
draft-lee-pce-global-concurrent-optimization-03.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 October 27, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Lee, et al. Expires October 27, 2007 [Page 1]
Internet-Draft PCE Global Concurrent Optimization April 2007
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. 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 Global Concurrent Optimization 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.
This document provides application-specific requirements and the PCEP
extensions in support of a global concurrent path computation
application.
Lee, et al. Expires October 27, 2007 [Page 2]
Internet-Draft PCE Global Concurrent Optimization April 2007
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability of Global Concurrent Path Computation . . . . . 7
3.1. Greenfield Optimization . . . . . . . . . . . . . . . . . 7
3.1.1. Single-layer Traffic Engineering . . . . . . . . . . . 7
3.1.2. Multi-layer Traffic Engineering . . . . . . . . . . . 8
3.2. Re-optimization of Existing Networks . . . . . . . . . . . 8
3.2.1. Reconfiguration of the Virtual Network Topology
(VNT) . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. Traffic Migration . . . . . . . . . . . . . . . . . . 8
3.3. Application of the PCE Architecture . . . . . . . . . . . 9
4. PCECP Requirements . . . . . . . . . . . . . . . . . . . . . . 11
5. Protocol extensions for support of global concurrent
optimization . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Global Objective Function (GOF) Specification . . . . . . 16
5.2. Indication of Global Concurrent Optimization Requests . . 16
5.3. Request for the order of LSP . . . . . . . . . . . . . . . 17
5.4. The Order Response . . . . . . . . . . . . . . . . . . . . 17
5.5. Global Constraints (GC) Object . . . . . . . . . . . . . . 19
5.6. Multi-Session Processing . . . . . . . . . . . . . . . . . 20
5.7. Error Indicator . . . . . . . . . . . . . . . . . . . . . 22
5.8. NO-PATH Indicator . . . . . . . . . . . . . . . . . . . . 22
6. Manageability Considerations . . . . . . . . . . . . . . . . . 24
6.1. Control of Function and Policy . . . . . . . . . . . . . . 24
6.2. Information and Data Models, e.g. MIB module . . . . . . . 24
6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 24
6.4. Verifying Correct Operation . . . . . . . . . . . . . . . 25
6.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 25
6.6. Impact on Network Operation . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 32
Lee, et al. Expires October 27, 2007 [Page 3]
Internet-Draft PCE Global Concurrent Optimization April 2007
1. Terminology
The terminology explained herein complies with [RFC4655].
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 from PCCs to a PCE, and to return computed paths from the
PCE to the PCCs. 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 repotimized 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 October 27, 2007 [Page 4]
Internet-Draft PCE Global Concurrent Optimization April 2007
2. Introduction
[RFC4655] defines the PCE based Architecture and explains how a PCE
may compute the paths of Multiprotocol Label Switching Traffic
Engineering (MPLS-TE) and Generalized MPLS (GMPLS) Label Switched
Paths (LSPs) at the request of 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 PCECP is the communication protocol used between PCC and PCE, and
may also be used between cooperating PCEs. [RFC4657] sets out the
common protocol requirements for the PCECP. Additional application-
specific requirements for PCECP are deferred to separate documents.
This document provides a set of PCECP extension requirements and
solutions in support of concurrent path computation applications that
may arise during network operations. 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.
As new LSPs are added sequentially or removed from the network over
time, the global network resources become fragmented and the network
no longer provides the 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.
The need for a 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 a global concurrent path computation in the event of
catastrophic network failures, where a set of TE LSPs need to be
optimally rerouted in real-time.
As the PCE is envisioned to provide solutions in all path computation
matters, it is anticipated that the PCE would provide solutions for
global concurrent path computation needs.
Lee, et al. Expires October 27, 2007 [Page 5]
Internet-Draft PCE Global Concurrent Optimization April 2007
The main focus of this document is to highlight the PCC-PCE
communication needs in support of a concurrent path computation
application 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 solving global
concurrent path computation applications. Discovery of such
capabilities might be desirable and could be achieved through
extensions to the PCE discovery mechanisms [RFC4674], but that is out
of the scope of this document.
Lee, et al. Expires October 27, 2007 [Page 6]
Internet-Draft PCE Global Concurrent Optimization April 2007
3. Applicability of Global Concurrent Path Computation
This section discusses scenarios for which global concurrent path
computation may be applied. It also discusses how these scenarios
apply to the PCE architecture.
3.1. Greenfield Optimization
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. Sequential path computation could
potentially result in sub-optimal use of network resources or even
blocking issues.
3.1.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
lower layer networks such as SDH/Sonet, Ethernet Transport, WDM, etc.
3.1.1.1. Pre-establishment of the Hierarchical-LSP (H-LSP)in the
Transport Network
When an optical transport layer provides lower-layer traffic
engineered LSPs for upper-layer client LSPs via the Hierarchical LSP
(H-LSP) mechanism, the operator may desire to pre-establish optical
LSPs in the optical transport network [MLN-REQ]. This whole multi-
layer network can be managed using PCE [PCE-MLN]. In this scenario,
it is anticipated that a set of H-LSPs would be created concurrently
in such a way as to efficiently utilize network resources in the
lower-layer network. Again, concurrent path computation capability
would result in more efficient network resource utilization than
sequential path computation.
3.1.1.2. VNT Configuration
A set of one or more lower-layer LSPs providing information for
efficient path handling in upper-layer(s) can be described as a
virtual network topology (VNT)[MLN-REQ].
When the VNT [MLN-REQ] is configured for the first time, greenfield
concurrent optimization may well be applied to find a set of LSPs
Lee, et al. Expires October 27, 2007 [Page 7]
Internet-Draft PCE Global Concurrent Optimization April 2007
more efficiently than sequential path computation.
3.1.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.
3.2. Re-optimization of Existing Networks
The need for global concurrent path computation may also 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, 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. Note that sequential re-
optimization of such TE LSPs is unlikely to produce substantial
improvements in overall network optimization except in very sparsely
utilized networks.
3.2.1. Reconfiguration of the Virtual Network Topology (VNT)
Reconfiguration of the VNT [MLN-REQ] is another 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 large
set of existing LSPs to be re-computed. Again, concurrent path
computation capability would result in more efficient network
resource utilization than sequential path computation.
3.2.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
is used. However, the PCE may be able to determine an order of LSP
Lee, et al. Expires October 27, 2007 [Page 8]
Internet-Draft PCE Global Concurrent Optimization April 2007
rerouting actions so that make-before-break can be performed within
the limited resources.
However, 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.
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).
3.3. Application of the PCE Architecture
Figure 1 shows how the aforementioned functionality applies within
the PCE architecture. It must be observed that the PCC is not
necessarily an LSR [RFC4655]. Although Figure 1 shows the PCE as
remote from the NMS, it might be collocated with the NMS.
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. 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.
Lee, et al. Expires October 27, 2007 [Page 9]
Internet-Draft PCE Global Concurrent Optimization April 2007
-----------
Application | ----- |
Request | | TED | |
| | ----- |
v | | |
------------- Request/ | v |
| | Response| ----- |
| NMS |<--------+> | PCE | |
| | | ----- |
------------- -----------
Service |
Request |
v
---------- Signaling ----------
| Head-End | Protocol | Adjacent |
| Node |<---------->| Node |
---------- ----------
Figure 1: PCE-Based Architecture for Global Concurrent Optimization
Lee, et al. Expires October 27, 2007 [Page 10]
Internet-Draft PCE Global Concurrent Optimization April 2007
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]. A
list of available global objective functions SHOULD include the
following objective functions at the minimum and SHOULD be
expandable for future addition:
* Minimize the sum of all TE LSP costs (min cost)
Lee, et al. Expires October 27, 2007 [Page 11]
Internet-Draft PCE Global Concurrent Optimization April 2007
* Maximize the residual bandwidth on the most loaded link
* Evenly allocate the network load to achieve the most uniform
link utilization across all links (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.
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 partially fulfilled by the SVEC object in the PCEP
specification [PCEP]. Since the SVEC object as defined in [PCEP]
Lee, et al. Expires October 27, 2007 [Page 12]
Internet-Draft PCE Global Concurrent Optimization April 2007
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. This can be achieved by
defining a new flag in the SVEC object to indicate that this is a
global concurrent optimization.
o An indicator field in which to indicate the outcome of the
request. When the PCE could not 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 A Multi-Session Indicator field in the case where the original
request is sub-divided into multiple sessions. This case may
arise when the reason for failure of the original request is due
to mathematical infeasibility, or memory overflow. The PCC may
follow up with subsequent actions under a local policy. The
motivation for multi-session application is to find a partial
feasible solution in the absence of the optimal solution. When
the PCC decides to scale down the original request into several
sessions, the PCC sends the first session path computation request
to the PCE. The next session path computation request is held
until the results from the first session would be available. Once
the results from the first session are available, the PCC then
sends the second session path computation request to the PCE. The
same procedure is repeated until the last session of the multi-
session has been completed. To support this requirement, it is
required that the PCE keep in memory the previously computed paths
until all paths of the multi-session have been computed.
* Multi-Session Indicator
* Multi-Session Sequence Number
Lee, et al. Expires October 27, 2007 [Page 13]
Internet-Draft PCE Global Concurrent Optimization April 2007
* The Indication of the Final Session
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.
* 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.
* 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).
* During a reoptimization it may be required to move a LSP
several times so as to avoid traffic disruption. The response
message must allow indicating the path sequence for each
request.
Lee, et al. Expires October 27, 2007 [Page 14]
Internet-Draft PCE Global Concurrent Optimization April 2007
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 is currently as follows per [PCEP]:
<PCReq Message>::= <Common Header>
[<SVEC-list>]
<request-list>
where:
<SVEC-list>::=<SVEC> [<SVEC-list>]
<request-list>::=<request> [<request-list>]
<request>::=<RP>
[<END-POINTS>]
[<LSPA>]
[<BANDWIDTH>]
[<METRIC>]
[<RRO>]
[<IRO>]
[<LOAD-BALANCING>]
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 in the SVEC-list two new optional objects have been
defined: the OF (Objective Function) Object and the GC (Global
Constraints) Object. Note also that the XRO is also added as an
optional Object in the list. Details of this change will be
discussed in the following sections.
Lee, et al. Expires October 27, 2007 [Page 15]
Internet-Draft PCE Global Concurrent Optimization April 2007
Note that the OF object is defined in [PCE-OF] and the GC object in
this document (see section 5.5).
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 [PCEP],
objective function identifier code points are managed by IANA.
Three global objective functions are defined in this document and
their identifier should be assigned by IANA (suggested value)
Function
Code Description
1 Minimize the sum of all TE LSP costs (min cost)
2 Maximize the residual bandwidth on the most loaded
link
3 Evenly allocate the network load to achieve the
most uniform link utilization across all links*
* 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. In order to
support this requirement, the SVEC object should be modified as
follows.
C flag (1 bit): This is a new flag in the SVEC object. When C flag
is set, this indicates that all of the path requests listed in the
body of the SVEC object should be computed applying the global
constraints and the global objective function.
When the C Flag is set in the SVEC Object, the OF and the GC objects
should directly follow the SVEC Object.
Lee, et al. Expires October 27, 2007 [Page 16]
Internet-Draft PCE Global Concurrent Optimization April 2007
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, it MUST include the order in which LSPs MUST be
moved so as to minimize traffic disruption. Such indication can be
included in the RP object which is revised 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |D|M|F|O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: RP object body format in the PCReq Message
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.
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
reoptimization is allowed for this request. Note that M bit can be
set only if the R flag is set.
All other fields are unchanged from [PCEP].
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. The
format of the RP object body to be included in the PCRep message is
modified as follows:
Lee, et al. Expires October 27, 2007 [Page 17]
Internet-Draft PCE Global Concurrent Optimization April 2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |D|M|F|O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Order TLV (Optional TLV) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: RP object body format in the PCRep Message
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type To be defined by IANA (suggested value = )
Length Variable
Value Orders in which the old path should be removed
and the new path should be setup
Figure 7: The Order TLV in the RP object in the PCRep Message
Delete Order: 32 bit integer that indicates the order in which the
old LSP should be removed
Lee, et al. Expires October 27, 2007 [Page 18]
Internet-Draft PCE Global Concurrent Optimization April 2007
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
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.
To illustrate, consider a network with two established requests: 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.
The format of the GC object body that includes the global constraints
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MU | mU | OB | MH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lee, et al. Expires October 27, 2007 [Page 19]
Internet-Draft PCE Global Concurrent Optimization April 2007
Figure 10: GC body object format
MU (Max Utilization) (8 bits) : 8 bit 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) (8 bits) : 8 bit integer that indicates the
lower bound utilization percentage by which all link should be bound.
OB (Over Booking factor) (8 bits) : 8 bit 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.
MH (Max Hop) (8 bits): 8 bit integer that indicates the maximum hop
count for all the LSPs.
GC Object-Class is to be assigned by IANA.
GC Object-Type is to be assigned by IANA.
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. Multi-Session Processing
When the initial global concurrent path computation request fails due
to scaling issues or memory overflow as indicated in the PCEP-ERROR
object in the PCRep message, multi-session processing may be
proceeded in an attempt to find a feasible solution in the absence of
an optimal solution. This should be driven by local policy decision.
How to divide up the original global concurrent optimization problem
into a number of smaller-scale optimization problems is out of the
scope of this document.
In order to meet these multi-session requirements, a new object, the
Multi-Session (MS) object is required.
This object should be defined on a per message basis. The message is
modified as follows:
<PCReq Message>::= <Common Header>
[<MSO>]
[<SVEC-list>]
Lee, et al. Expires October 27, 2007 [Page 20]
Internet-Draft PCE Global Concurrent Optimization April 2007
<request-list>
The format of the MSO object 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Reserved | Multi-Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: MSO object body format
Multi-Session ID (16 bits): 16 bit integer that identifies the multi-
session computation. The Multi-Session ID will allow to map all
request messages for the same global computation.
Sequence Number (16 bits): 16 bit integer that indicates the sequence
number of the current multi-session request. This should be
incremented for each new request message during a multi-session
request until the final request is performed.
F (Final session - 1 bit): When set, the requesting PCC indicates
that the PCReq message is the final session of a multi-session
request. When it is not set, the PCE SHOULD keep in memory all the
computed paths until the final session of a multi-session is
completed. This is necessary to correctly account for already
computed LSPs.
MS Object-Class is to be assigned by IANA.
MS Object-Type is to be assigned by IANA.
For PCE not able to temporarily maintain previously computed paths,
the multi-session capability can be provided by adding in a PCReq the
results of all previous path requests for this multi-session. This
includes, for each previously handled request, the RP, ERO and
Bandwidth objects.
In order to distinguish a previously computed request from a new
request, a new flag in the RP object is required.
A (Already computed request - 1 bit): When set, this indicates that
the request has already been computed in a previous session, and its
result (as indicated by the ERO and the Bandwidth Object following
Lee, et al. Expires October 27, 2007 [Page 21]
Internet-Draft PCE Global Concurrent Optimization April 2007
the RP object) must be taken account in the current session.
5.7. 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 (14) and subsequent error-values are defined as
follows:
Error-Type=14 and Error-Value=1: if a PCE receives a global
concurrent path optimization request and the PCE is not capable of
the request due to insufficient memory, the PCE MUST send a PCErr
message with a PCEP ERROR object (Error-Type=14) and an Error-Value
(Error-Value=1). The corresponding global concurrent path
optimization request MUST be cancelled.
Error-Type=14; 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=14) and an Error-Value (Error-Value=2).
The corresponding global concurrent path optimization MUST be
cancelled.
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=3: 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 send a PCErr message with a PCEP-ERROR Object
(Error-Type=5) and an Error-Value (Error-Value=3). The corresponding
global concurrent path computation MUST be cancelled.
5.8. 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 as follows:
Lee, et al. Expires October 27, 2007 [Page 22]
Internet-Draft PCE Global Concurrent Optimization April 2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: NO-PATH object format
Flags (16 bits). The C flag is defined in [PCEP].
Two new bit flags are defined in the NO-PATH-VECTOR TLV carried in
the NO-PATH Object:
0x03: when set, the PCE indicates that no migration path was found.
0x04: 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.
When either 0x03 or 0x04 flag is set in the NO-PATH-VECTOR TLV
carried in the NO-PATH object in the PCRep Message, a subsequent
multi-session feature may be triggered if the PCC's local policy
allows it. The multi-session feature allows the original global
concurrent optimization to be split into a number of multiple
sessions so that the PCE would compute a number of smaller-scale
optimizations in a sequential manner. The trade-off is that a
partial feasible solution may be obtained using this approach which
is better than not having any solution at all, although such solution
might not be a global optimal solution. How to divide up the
original set of global concurrent optimization requests into multiple
numbers of smaller-scale optimizations is out of the scope of this
document.
See Section 5.6 for multi-session processing details.
Lee, et al. Expires October 27, 2007 [Page 23]
Internet-Draft PCE Global Concurrent Optimization April 2007
6. Manageability Considerations
Manageability of Global Concurrent Path Computation with PCE must
address the following considerations:
6.1. Control of Function and Policy
Only PCCs configured to be aware of the PCE and its global concurrent
path computation capabilities can request global concurrent path
computations. Discovery of such capabilities might be desirable and
could be achieve through extensions to the PCE discovery mechanisms
[RFC4674], but that is out of the scope of this document. The PCE
MUST allow the restricting of PCCs that can initiate global
concurrent optimization requests.
The PCE architecture introduced in [RFC4655] includes policy as an
integral part of the PCE architecture. Due the inherent nature of a
global concurrent optimization a PCE implementation MUST allow for
policy control that would limit the type of global concurrent path
computation operations that can be requested by the PCC (e.g. network
layer, size, frequency, etc.)
A PCE capable of performing global concurrent path computations
SHOULD also support the ability to enable or disable its global
concurrent path computation capabilities.
6.2. Information and Data Models, e.g. MIB module
A PCEP MIB module will be needed to support the monitoring of global
concurrent path computation requests. A PCEP MIB module is defined
in [PCEP-MIB] that describes managed objects for modeling of PCEP
communication including:
o PCEP client configuration and status,
o PCEP peer configuration and information,
o PCEP session configuration and information,
o Notifications to indicate PCEP session changes.
6.3. Liveness Detection and Monitoring
As documented in [RFC4657] the PCECP MUST allow a PCE/PCC to check
the liveliness of the PCC-PCE communication, to rapidly detect
communication failures, and distinguish PCC/PCE node failures from
PCC-PCE connectivity failures, after the PCC-PCE communication is
recovered.
Lee, et al. Expires October 27, 2007 [Page 24]
Internet-Draft PCE Global Concurrent Optimization April 2007
The aliveness detection mechanism MUST ensure reciprocal knowledge of
PCE and PCC liveness. The PCE SHOULD also notify its congested state
to the PCE when performing large complex concurrent path
computations. Default PCEP session parameters (including keepalive
and deadtimer timers) may need to be modified for PCEP sessions with
PCEs performing global concurrent path computations.
6.4. Verifying Correct Operation
The draft [PCEP] sets out a number of requirements for verifying
correct operation. A PCEP implementation supporting global
concurrent path computation SHOULD provide the following parameters:
o Response time (minimum, average and maximum), on a per PCE Peer
basis,
o PCEP Session and policy failures,
o Amount of time the session has been in active state,
o Number of corrupted messages,
o Number of failed computations,
o Number of requests for which no reply has been received after the
expiration of a configurable timer and by verifying that a
returned path fit in with the requested TE parameters.
A PCEP implementation SHOULD log error events (e.g. corrupted
messages, unrecognized objects, etc.).
6.5. Requirements on Other Protocols and Functional Components
The PCE Discovery mechanisms ([ISIS PCED] and [OSPF PCED]) may be
used to advertise global concurrent path computation capabilities to
PCCs.
6.6. Impact on Network Operation
The draft [PCEP] sets out a number of requirements for minimising the
impact of PCEP on network operations. It should be considered that
if the PCE is processing large or complex global concurrent path
computations it may not be able to process new computation requests.
The PCE SHOULD send a notification when it is unable to process any
new requests.
Lee, et al. Expires October 27, 2007 [Page 25]
Internet-Draft PCE Global Concurrent Optimization April 2007
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 mechanisms defined in [PCEP] to secure a PCEP session (MD-5
authentication, etc.) MUST be used when global concurrent path
optimization is requested.
Lee, et al. Expires October 27, 2007 [Page 26]
Internet-Draft PCE Global Concurrent Optimization April 2007
8. Acknowledgements
We would like to thank Jerry Ash, Adrian Farrel, Ning So and Lucy
Yong for their useful comments and suggestions.
Lee, et al. Expires October 27, 2007 [Page 27]
Internet-Draft PCE Global Concurrent Optimization April 2007
9. IANA Considerations
A future revision of this document will present requests to IANA for
codepoint allocation.
Lee, et al. Expires October 27, 2007 [Page 28]
Internet-Draft PCE Global Concurrent Optimization April 2007
10. References
10.1. Normative References
[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.
[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.".
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-
region and multi-layer networks (MRN/MLN),
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-
based inter-layer MPLS and GMPL traffic engineering,
draft-ietf-pce-inter-layer-frwk, 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".
[PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) communication Protocol (PCEP) - Version 1,
Lee, et al. Expires October 27, 2007 [Page 29]
Internet-Draft PCE Global Concurrent Optimization April 2007
draft-ietf-pce-pcep, work in progress".
[PCEP-MIB]
Stephen, E. and K. Koushik, "PCE communication
protocol(PCEP) Management Information Base,
draft-kkoushik-pce-pcep-mib, work in progress.".
Lee, et al. Expires October 27, 2007 [Page 30]
Internet-Draft PCE Global Concurrent Optimization April 2007
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
44/45 Market Place
Chippenham SN15 3HU
United Kingdom
Phone: +44 7790 775187
Fax: +44 1249 446530
Email: daniel.king@aria-networks.com
Eiji Oki
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585
JAPAN
Email: oki.eiji@lab.ntt.co.jp
Lee, et al. Expires October 27, 2007 [Page 31]
Internet-Draft PCE Global Concurrent Optimization April 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Lee, et al. Expires October 27, 2007 [Page 32]