draft-ietf-pce-global-concurrent-optimization-10.txt   rfc5557.txt 
Network Working Group Y. Lee Network Working Group Y. Lee
Internet-Draft Huawei Request for Comments: 5557 Huawei
Intended status: Standards Track JL. Le Roux Category: Standards Track JL. Le Roux
Expires: Aug 2009 France Telecom France Telecom
D. King D. King
Old Dog Consulting Old Dog Consulting
E. Oki E. Oki
Univeristy of Electro Communications University of Electro Communications
March 29, 2009 Path Computation Element Communication Protocol (PCEP) Requirements
and Protocol Extensions in Support of Global Concurrent Optimization
Path Computation Element Communication Protocol (PCEP) Requirements and
Protocol Extensions In Support of Global Concurrent Optimization
draft-ietf-pce-global-concurrent-optimization-10.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 August 29, 2009.
Abstract Abstract
The Path Computation Element Communication Protocol (PCEP) allows The Path Computation Element Communication Protocol (PCEP) allows
Path Computation Clients (PCCs) to request path computations from Path Computation Clients (PCCs) to request path computations from
Path Computation Elements (PCEs), and lets the PCEs return responses. Path Computation Elements (PCEs), and lets the PCEs return responses.
When computing or re-optimizing the routes of a set of TE LSPs When computing or reoptimizing the routes of a set of Traffic
through a network it may be advantageous to perform bulk path Engineering Label Switched Paths (TE LSPs) through a network, it may
computations in order to avoid blocking problems and to achieve more be advantageous to perform bulk path computations in order to avoid
optimal network-wide solutions. Such bulk optimization is termed blocking problems and to achieve more optimal network-wide solutions.
Global Concurrent Optimization (GCO). A GCO is able to Such bulk optimization is termed Global Concurrent Optimization
simultaneously consider the entire topology of the network and the (GCO). A GCO is able to simultaneously consider the entire topology
complete set of existing TE LSPs, and their respective constraints, of the network and the complete set of existing TE LSPs, and their
and look to optimize or re-optimize the entire network to satisfy all respective constraints, and look to optimize or reoptimize the entire
constraints for all TE LSPs. A GCO may also be applied to some network to satisfy all constraints for all TE LSPs. A GCO may also
subset of the TE LSPs in a network. The GCO application is primarily be applied to some subset of the TE LSPs in a network. The GCO
a Network Management System (NMS) solution. application is primarily a Network Management System (NMS) solution.
This document provides application-specific requirements and the PCEP This document provides application-specific requirements and the PCEP
extensions in support of GCO applications. extensions in support of GCO applications.
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology .....................................................6
3. Applicability of Global Concurrent Optimization (GCO) . . . . 7 3. Applicability of Global Concurrent Optimization (GCO) ...........6
3.1. Application of the PCE Architecture . . . . . . . . . . . 7 3.1. Application of the PCE Architecture ........................7
3.2. Greenfield Optimization . . . . . . . . . . . . . . . . . 8 3.2. Greenfield Optimization ....................................8
3.2.1. Single-layer Traffic Engineering . . . . . . . . . . . 8 3.2.1. Single-Layer Traffic Engineering ....................8
3.2.2. Multi-layer Traffic Engineering . . . . . . . . . . . 8 3.2.2. Multi-Layer Traffic Engineering .....................8
3.3. Re-optimization of Existing Networks . . . . . . . . . . . 8 3.3. Reoptimization of Existing Networks ........................8
3.3.1. Reconfiguration of the Virtual Network Topology 3.3.1. Reconfiguration of the Virtual Network
(VNT) . . . . . . . . . . . . . . . . . . . . . . . . 9 Topology (VNT) ......................................9
3.3.2. Traffic Migration . . . . . . . . . . . . . . . . . . 9 3.3.2. Traffic Migration ...................................9
4. PCECP Requirements . . . . . . . . . . . . . . . . . . . . . . 10 4. PCECP Requirements .............................................10
5. Protocol Extensions for Support of Global Concurrent 5. Protocol Extensions for Support of Global Concurrent
Optimization . . . . . . . . . . . . . . . . . . . . . . . . . 14 Optimization ...................................................13
5.1. Global Objective Function (GOF) Specification . . . . . . 14 5.1. Global Objective Function (GOF) Specification .............14
5.2. Indication of Global Concurrent Optimization Requests . . 15 5.2. Indication of Global Concurrent Optimization Requests .....15
5.3. Request for The Order of TE LSP . . . . . . . . . . . . . 15 5.3. Request for the Order of TE LSP ...........................15
5.4. The Order Response . . . . . . . . . . . . . . . . . . . . 16 5.4. The Order Response ........................................16
5.5. GLOBAL CONSTRAINTS (GC) Object . . . . . . . . . . . . . . 17 5.5. GLOBAL CONSTRAINTS (GC) Object ............................17
5.6. Error Indicator . . . . . . . . . . . . . . . . . . . . . 18 5.6. Error Indicator ...........................................18
5.7. NO-PATH Indicator . . . . . . . . . . . . . . . . . . . . 19 5.7. NO-PATH Indicator .........................................19
6. Manageability Considerations . . . . . . . . . . . . . . . . . 20 6. Manageability Considerations ...................................19
6.1. Control of Function and Policy . . . . . . . . . . . . . . 20 6.1. Control of Function and Policy ............................19
6.2. Information and Data Models, e.g. MIB module . . . . . . . 20 6.2. Information and Data Models (e.g., MIB Module) ............20
6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 20 6.3. Liveness Detection and Monitoring .........................20
6.4. Verifying Correct Operation . . . . . . . . . . . . . . . 20 6.4. Verifying Correct Operation ...............................20
6.5. Requirements on Other Protocols and Functional 6.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 21 Components ................................................20
6.6. Impact on Network Operation . . . . . . . . . . . . . . . 21 6.6. Impact on Network Operation ...............................20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations ........................................21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations ............................................21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8.1. Request Parameter Bit Flags ...............................21
9.1. Request Parameter Bit Flags . . . . . . . . . . . . . . . 22 8.2. New PCEP TLV ..............................................21
9.2. New PCEP TLV . . . . . . . . . . . . . . . . . . . . . . . 22 8.3. New Flag in PCE-CAP-FLAGS Sub-TLV in PCED .................22
9.3. New Flag in PCE-CAP-FLAGS Sub-TLV in PCED . . . . . . . . 22 8.4. New PCEP Object ...........................................22
9.4. New PCEP Object . . . . . . . . . . . . . . . . . . . . . 23 8.5. New PCEP Error Codes ......................................22
9.5. New PCEP Error Codes . . . . . . . . . . . . . . . . . . . 23 8.5.1. New Error-Values for Existing Error-Types ..........22
9.5.1. New Error-Values for Existing Error-Types . . . . . . 23 8.5.2. New Error-Types and Error-Values ...................23
9.5.2. New Error-Types and Error-Values . . . . . . . . . . . 23 8.6. New No-Path Reasons .......................................23
9.6. New No-Path Reasons . . . . . . . . . . . . . . . . . . . 24 9. References .....................................................23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.1. Normative References ......................................23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 9.2. Informative References ....................................24
10.2. Informative References . . . . . . . . . . . . . . . . . . 25 10. Acknowledgments ...............................................24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. RBNF Code Fragments ...................................25
Intellectual Property and Copyright Statements . . . . . . . . . . 26
1. Introduction 1. Introduction
[RFC4655] defines the Path Computation Element (PCE) based [RFC4655] defines the Path Computation Element (PCE)-based
Architecture and explains how a PCE may compute Label Switched Paths architecture and explains how a PCE may compute Label Switched Paths
(LSPs) in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) (LSPs) in Multiprotocol Label Switching Traffic Engineering (MPLS-TE)
and Generalized MPLS (GMPLS) networks at the request of Path and Generalized MPLS (GMPLS) networks at the request of Path
Computation Clients (PCCs). A PCC is shown to be any network Computation Clients (PCCs). A PCC is shown to be any network
component that makes such a request and may be for instance a Label component that makes such a request and may be, for instance, a Label
Switching Router (LSR) or a Network Management System (NMS). The Switching Router (LSR) or a Network Management System (NMS). The
PCE, itself, is shown to be located anywhere within the network, and PCE, itself, is shown to be located anywhere within the network, and
may be within an LSR, an NMS or Operational Support System (OSS), or it may be within an LSR, an NMS or Operational Support System (OSS),
may be an independent network server. or may be an independent network server.
The PCE Communication Protocol (PCEP) is the communication protocol The PCE Communication Protocol (PCEP) is the communication protocol
used between PCC and PCE, and may also be used between cooperating used between PCC and PCE, and it may also be used between cooperating
PCEs. [RFC4657] sets out generic protocol requirements for PCEP. PCEs. [RFC4657] sets out generic protocol requirements for PCEP.
Additional application-specific requirements for PCEP are defined in Additional application-specific requirements for PCEP are defined in
separate documents. separate documents.
This document provides a set of requirements and PCEP extensions in This document provides a set of requirements and PCEP extensions in
support of concurrent path computation applications. A concurrent support of concurrent path computation applications. A concurrent
path computation is a path computation application where a set of TE path computation is a path computation application where a set of TE
paths are computed concurrently in order to efficiently utilize paths are computed concurrently in order to efficiently utilize
network resources. The computation method involved with a concurrent network resources. The computation method involved with a concurrent
path computation is referred to as global concurrent optimization in path computation is referred to as "global concurrent optimization"
this document. Appropriate computation algorithms to perform this in this document. Appropriate computation algorithms to perform this
type of optimization are out of the scope of this document. type of optimization are out of the scope of this document.
The Global Concurrent Optimization (GCO) application is primarily an The Global Concurrent Optimization (GCO) application is primarily an
NMS or a PCE Server based solution. Owing to complex synchronization NMS or a PCE-Server-based solution. Owing to complex synchronization
issues associated with GCO applications, the management based PCE issues associated with GCO applications, the management-based PCE
architecture defined in Section 5.5 of [RFC4655] is considered as the architecture defined in Section 5.5 of [RFC4655] is considered as the
most suitable usage to support GCO application. This does not most suitable usage to support GCO application. This does not
preclude other architectural alternatives to support GCO application, preclude other architectural alternatives to support GCO application,
but they are NOT RECOMMENDED. For instance, GCO might be enabled by but they are NOT RECOMMENDED. For instance, GCO might be enabled by
distributed LSRs through complex synchronization mechanisms. distributed LSRs through complex synchronization mechanisms.
However, this approach might suffer from significant synchronization However, this approach might suffer from significant synchronization
overhead between the PCE and each of the PCCs. It would likely overhead between the PCE and each of the PCCs. It would likely
affect the network stability and hence significantly diminish the affect the network stability and hence significantly diminish the
benefits of deploying PCEs. benefits of deploying PCEs.
The need for global concurrent path computation may also arise when The need for global concurrent path computation may also arise when
network operators need to establish a set of TE LSPs in their network network operators need to establish a set of TE LSPs in their network
planning process. It is also envisioned that network operators might planning process. It is also envisioned that network operators might
require global concurrent path computation in the event of require global concurrent path computation in the event of
catastrophic network failures, where a set of TE LSPs need to be catastrophic network failures, where a set of TE LSPs need to be
optimally rerouted. The nature of this work promote the use of such optimally rerouted. The nature of this work promotes the use of such
systems for offline processing. Online application of this work systems for off-line processing. Online application of this work
should only be considered with proven empirical validation. should only be considered with proven empirical validation.
As new TE LSPs are added or removed from the network over time, the As new TE LSPs are added or removed from the network over time, the
global network resources become fragmented and the existing placement global network resources become fragmented and the existing placement
of TE LSPs within network no longer provides optimal use of the of TE LSPs within the network no longer provides optimal use of the
available capacity. A global concurrent path computation is able to available capacity. A global concurrent path computation is able to
simultaneously consider the entire topology of the network and the simultaneously consider the entire topology of the network and the
complete set of existing TE LSPs and their respective constraints, complete set of existing TE LSPs and their respective constraints,
and look to re-optimize the entire network to satisfy all constraints and is able to look to reoptimize the entire network to satisfy all
for all TE LSPs. Alternatively, the application may consider a constraints for all TE LSPs. Alternatively, the application may
subset of the TE LSPs and/or a subset of the network topology. Note consider a subset of the TE LSPs and/or a subset of the network
that other preemption can also help reducing the fragmentation topology. Note that other preemption can also help reduce the
issues. fragmentation issues.
While GCO is applicable to any simultaneous request for multiple TE While GCO is applicable to any simultaneous request for multiple TE
LSPs (for example, a request for end-to-end protection), it is NOT LSPs (for example, a request for end-to-end protection), it is NOT
RECOMMENDED that global concurrent reoptimization would be applied in RECOMMENDED that global concurrent reoptimization would be applied in
a network (such as an MPLS-TE network) that contains a very large a network (such as an MPLS-TE network) that contains a very large
number of very low bandwidth or zero bandwidth TE LSPs since the number of very low bandwidth or zero bandwidth TE LSPs since the
large scope of the problem and the small benefit of concurrent large scope of the problem and the small benefit of concurrent
reoptimization relative to single TE LSP reoptimization is unlikely reoptimization relative to single TE LSP reoptimization is unlikely
to make the process worthwhile. Further, applying global concurrent to make the process worthwhile. Further, applying global concurrent
reoptimization in a network with a high rate of change of TE LSPs reoptimization in a network with a high rate of change of TE LSPs
(churn) is NOT RECOMMENDED because of the likelihood that TE LSPs (churn) is NOT RECOMMENDED because of the likelihood that TE LSPs
would change before they could be globally reoptimized. Global would change before they could be globally reoptimized. Global
reoptimization is more applicable to stable networks such as reoptimization is more applicable to stable networks such as
transport networks or those with long-term TE LSP tunnels. transport networks or those with long-term TE LSP tunnels.
The main focus of this document is to highlight the PCC-PCE The main focus of this document is to highlight the PCC-PCE
communication needs in support of a concurrent path computation communication needs in support of a concurrent path computation
applications and to define protocol extensions to meet those needs. application and to define protocol extensions to meet those needs.
The PCC-PCE requirements addressed herein are specific to the context The PCC-PCE requirements addressed herein are specific to the context
where the PCE is a specialized PCE that is capable of performing where the PCE is a specialized PCE that is capable of performing
computations in support of GCO. Discovery of such capabilities might computations in support of GCO. Discovery of such capabilities might
be desirable and could be achieved through extensions to the PCE be desirable and could be achieved through extensions to the PCE
discovery mechanisms [RFC4674], [RFC5088], [RFC5089], but that is out discovery mechanisms [RFC4674], [RFC5088], [RFC5089]; but, that is
of the scope of this document. out of the scope of this document.
It is to be noted that Backward Recursive Path Computation (BRPC) It is to be noted that Backward Recursive Path Computation (BRPC)
[BRPC] is a multi-PCE path computation technique used to compute a [RFC5441] is a multi-PCE path computation technique used to compute a
shortest constrained inter-domain path whereas this ID specifies a shortest constrained inter-domain path, whereas this ID specifies a
technique where a set of path computation requests are bundled and technique where a set of path computation requests are bundled and
send to a PCE with the objective of "optimizing" the set of computed sent to a PCE with the objective of "optimizing" the set of computed
paths. paths.
2. Terminology 2. Terminology
Most of the terminology used in this document is explained in Most of the terminology used in this document is explained in
[RFC4655]. A few key terms are repeated here for clarity. [RFC4655]. A few key terms are repeated here for clarity.
PCC: Path Computation Client: Any client application requesting a PCC: Path Computation Client. Any client application requesting a
path computation to be performed by a Path Computation Element. path computation to be performed by a Path Computation Element.
PCE: Path Computation Element: An entity (component, application or PCE: Path Computation Element. An entity (component, application, or
network node) that is capable of computing a network path or route network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints. based on a network graph and applying computational constraints.
TED: Traffic Engineering Database which contains the topology and TED: Traffic Engineering Database. The TED contains the topology and
resource information of the domain. The TED may be fed by IGP resource information of the domain. The TED may be fed by IGP
extensions or potentially by other means. extensions or potentially by other means.
PCECP: The PCE Communication Protocol: PCECP is the generic abstract PCECP: The PCE Communication Protocol. PCECP is the generic abstract
idea of a protocol that is used to communicate path computation idea of a protocol that is used to communicate path computation
requests from a PCC to a PCE, and to return computed paths from the requests from 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. PCE to the PCC. The PCECP can also be used between cooperating PCEs.
PCEP: The PCE communication Protocol: PCEP is the actual protocol PCEP: The PCE communication Protocol. PCEP is the actual protocol
that implements the PCECP idea. that implements the PCECP idea.
GCO: Global Concurrent Optimization: A concurrent path computation GCO: Global Concurrent Optimization. A concurrent path computation
application where a set of TE paths are computed concurrently in application where a set of TE paths are computed concurrently in
order to optimize network resources. A GCO path computation is able order to optimize network resources. A GCO path computation is able
to simultaneously consider the entire topology of the network and the to simultaneously consider the entire topology of the network and the
complete set of existing TE LSPs, and their respective constraints, complete set of existing TE LSPs, and their respective constraints,
and look to optimize or re-optimize the entire network to satisfy all and look to optimize or reoptimize the entire network to satisfy all
constraints for all TE LSPs. A GCO path computation can also provide constraints for all TE LSPs. A GCO path computation can also provide
an optimal way to migrate from an existing set of TE LSPs to a an optimal way to migrate from an existing set of TE LSPs to a
reoptimized set (Morphing Problem). reoptimized set (Morphing Problem).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
These terms are also used in the parts of this document that specify These terms are used to specify requirements in this document.
requirements for clarity of specification of those requirements.
3. Applicability of Global Concurrent Optimization (GCO) 3. Applicability of Global Concurrent Optimization (GCO)
This section discusses the PCE architecture to which GCO is applied. This section discusses the PCE architecture to which GCO is applied.
It also discusses various application scenarios for which global It also discusses various application scenarios for which global
concurrent path computation may be applied. concurrent path computation may be applied.
3.1. Application of the PCE Architecture 3.1. Application of the PCE Architecture
Figure 1 shows the PCE-based network architecture as defined in Figure 1 shows the PCE-based network architecture as defined in
[RFC4655] to which GCO application is applied. It must be observed [RFC4655] to which GCO application is applied. It must be observed
that the PCC is not necessarily an LSR [RFC4655]. The GCO that the PCC is not necessarily an LSR [RFC4655]. The GCO
application is primarily an NMS-based solution in which an NMS plays application is primarily an NMS-based solution in which an NMS plays
the function of the PCC. Although Figure 1 shows the PCE as remote the function of the PCC. Although Figure 1 shows the PCE as remote
from the NMS, it might be collocated with the NMS. Note that in the from the NMS, it might be collocated with the NMS. Note that in the
collocated case there is no need for a standard communication collocated case, there is no need for a standard communication
protocol; this can rely on internal APIs. protocol; this can rely on internal APIs.
----------- -----------
Application | ----- | Application | ----- |
Request | | TED | | Request | | TED | |
| | ----- | | | ----- |
v | | | v | | |
------------- Request/ | v | ------------- Request/ | v |
| PCC | Response| ----- | | PCC | Response| ----- |
| (NMS/Server)|<--------+> | PCE | | | (NMS/Server)|<--------+> | PCE | |
| | | ----- | | | | ----- |
------------- ----------- ------------- -----------
Service | Service |
Request | Request |
v v
---------- Signaling ---------- ---------- Signaling ----------
| Head-End | Protocol | Adjacent | | Head-End | Protocol | Adjacent |
| Node |<---------->| Node | | Node |<---------->| Node |
---------- ---------- ---------- ----------
Figure 1: PCE-Based Architecture for Global Concurrent Optimization Figure 1: PCE-Based Architecture for
Global Concurrent Optimization
Upon receipt of an application request (e.g., a traffic demand matrix Upon receipt of an application request (e.g., a traffic demand matrix
is provided to the NMS by the operator's network planning procedure), is provided to the NMS by the operator's network planning procedure),
the NMS requests a global concurrent path computation from the PCE. the NMS requests a global concurrent path computation from the PCE.
The PCE then computes the requested paths concurrently applying some The PCE then computes the requested paths concurrently applying some
algorithms. Various algorithms and computation techniques have been algorithms. Various algorithms and computation techniques have been
proposed to perform this function. Specification of such algorithms proposed to perform this function. Specification of such algorithms
or techniques is outside the scope of this document. or techniques is outside the scope of this document.
When the requested path computation completes, the PCE sends the When the requested path computation completes, the PCE sends the
resulting paths back to the NMS. The NMS then supplies the head-end 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 LSRs with a fully computed explicit path for each TE LSP that needs
to be established. to be established.
3.2. Greenfield Optimization 3.2. Greenfield Optimization
Greenfield optimization is a special case of GCO application when Greenfield optimization is a special case of GCO application when
there are no TE LSPs already set up in the network. The need for there are no TE LSPs already set up in the network. The need for
greenfield optimization arises when network planner wants to make use greenfield optimization arises when the network planner wants to make
of a computation server to plan the TE LSPs that will be provisioned use of a computation server to plan the TE LSPs that will be
in the network. Note that once greenfield operation is one-time provisioned in the network. Note that greenfield operation is a
optimization. When network conditions change due to failure or other one-time optimization. When network conditions change due to failure
changes, then re-optimization mode of operation will kick in. or other changes, then the reoptimization mode of operation will kick
in.
When a new TE network needs to be provisioned from a greenfield 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 perspective, a set of TE LSPs needs to be created based on traffic
demand, network topology, service constraints, and network resources. demand, network topology, service constraints, and network resources.
In this scenario, the ability to perform concurrent computation is In this scenario, the ability to perform concurrent computation is
desirable, or required, to utilize network resources in an optimal desirable, or required, to utilize network resources in an optimal
manner and avoid blocking. manner and avoid blocking.
3.2.1. Single-layer Traffic Engineering 3.2.1. Single-Layer Traffic Engineering
Greenfield optimization can be applied when layer-specific TE LSPs Greenfield optimization can be applied when layer-specific TE LSPs
need to be created from a greenfield perspective. For example, an need to be created from a greenfield perspective. For example, an
MPLS-TE network can be planned based on layer 3 specific traffic MPLS-TE network can be planned based on Layer 3 specific traffic
demands, the network topology, and available network resources. demands, the network topology, and available network resources.
Greenfield optimization for single-layer traffic engineering can be Greenfield optimization for single-layer traffic engineering can be
applied to optical transport networks such as SDH/Sonet, Ethernet applied to optical transport networks such as Synchronous Digital
Transport, WDM, etc. Hierarchy/Synchronous Optical Network (SDH/SONET), Ethernet
Transport, Wavelength Division Multiplexing (WDM), etc.
3.2.2. Multi-layer Traffic Engineering 3.2.2. Multi-Layer Traffic Engineering
Greenfield optimization is not limited to single-layer traffic Greenfield optimization is not limited to single-layer traffic
engineering. It can also be applied to multi-layer traffic engineering. It can also be applied to multi-layer traffic
engineering [PCE-MLN]. Both the client and the server layers network engineering [PCE-MLN]. The network resources and topology (of both
resources and topology can be considered simultaneously in setting up the client and server layers) can be considered simultaneously in
a set of TE LSPs that traverse the layer boundary. setting up a set of TE LSPs that traverse the layer boundary.
3.3. Re-optimization of Existing Networks 3.3. Reoptimization of Existing Networks
The need for global concurrent path computation may arise in existing The need for global concurrent path computation may arise in existing
networks. When an existing TE LSP network experiences sub-optimal networks. When an existing TE LSP network experiences sub-optimal
use of its resources, the need for re-optimization or reconfiguration use of its resources, the need for reoptimization or reconfiguration
may arise. The scope of re-optimization and reconfiguration may vary may arise. The scope of reoptimization and reconfiguration may vary
depending on particular situations. The scope of re-optimization may depending on particular situations. The scope of reoptimization may
be limited to bandwidth modification to an existing TE LSP. However, be limited to bandwidth modification to an existing TE LSP. However,
it could well be that a set of TE LSPs may need to be re-optimized it could well be that a set of TE LSPs may need to be reoptimized
concurrently. In an extreme case, the TE LSPs may need to be concurrently. In an extreme case, the TE LSPs may need to be
globally re-optimized. globally reoptimized.
In loaded networks, with large size TE LSPs, a sequential re- In loaded networks, with large size TE LSPs, a sequential
optimization may not produce substantial improvements in terms of reoptimization may not produce substantial improvements in terms of
overall network optimization. Sequential re-optimization refers to a overall network optimization. Sequential reoptimization refers to a
path computation method that computes the re-optimized path of path computation method that computes the reoptimized path of one TE
one TE LSP at a time without giving any consideration to the other TE LSP at a time without giving any consideration to the other TE LSPs
LSPs that need to be re-optimized in the network. The potential for that need to be reoptimized in the network. The potential for
network-wide gains from reoptimization of TE LSPs sequentially is network-wide gains from reoptimization of TE LSPs sequentially is
dependent upon the network usage and size of the TE LSPs being dependent upon the network usage and size of the TE LSPs being
optimized. However, the key point remains: computing the reoptimized optimized. However, the key point remains: computing the reoptimized
path of one TE LSP at a time without giving any consideration to the path of one TE LSP at a time without giving any consideration to the
other TE LSPs in the network could result in sub-optimal use of other TE LSPs in the network could result in sub-optimal use of
network resources. This may be far more visible in an optical network resources. This may be far more visible in an optical
network with a low ratio of potential TE LSPs per link, and far less network with a low ratio of potential TE LSPs per link, and far less
visible in packet networks with micro-flow TE LSPs. visible in packet networks with micro-flow TE LSPs.
With regards to applicability of GCO in the event of catastrophic With regards to applicability of GCO in the event of catastrophic
skipping to change at page 9, line 39 skipping to change at page 9, line 36
computation. GCO provides an alternative way that could also prevent computation. GCO provides an alternative way that could also prevent
race condition in a centralized manner. However, a centralized race condition in a centralized manner. However, a centralized
system will typically suffer from a slower response time than a system will typically suffer from a slower response time than a
distributed system. distributed system.
3.3.1. Reconfiguration of the Virtual Network Topology (VNT) 3.3.1. Reconfiguration of the Virtual Network Topology (VNT)
Reconfiguration of the VNT [RFC5212] [PCE-MLN] is a typical Reconfiguration of the VNT [RFC5212] [PCE-MLN] is a typical
application scenario where global concurrent path computation may be application scenario where global concurrent path computation may be
applicable. Triggers for VNT reconfiguration, such as traffic demand applicable. Triggers for VNT reconfiguration, such as traffic demand
changes, network failures, and topological configuration changes, may changes, network failures, and topological configuration changes may
require a set of existing TE LSPs to be re-computed. require a set of existing TE LSPs to be re-computed.
3.3.2. Traffic Migration 3.3.2. Traffic Migration
When migrating from one set of TE LSPs to a reoptimized set of TE When migrating from one set of TE LSPs to a reoptimized set of TE
LSPs it is important that the traffic be moved without causing LSPs, it is important that the traffic be moved without causing
disruption. Various techniques exist in MPLS and GMPLS, such as disruption. Various techniques exist in MPLS and GMPLS, such as
make-before-break [RFC3209], to establish the new TE LSPs before make-before-break [RFC3209], to establish the new TE LSPs before
tearing down the old TE LSPs. When multiple TE LSP routes are tearing down the old TE LSPs. When multiple TE LSP routes are
changed according to the computed results, some of the TE LSPs may be changed according to the computed results, some of the TE LSPs may be
disrupted due to the resource constraints. In other words, it may disrupted due to the resource constraints. In other words, it may
prove to be impossible to perform a direct migration from the old TE prove to be impossible to perform a direct migration from the old TE
LSPs to the new optimal TE LSPs without disrupting traffic because LSPs to the new optimal TE LSPs without disrupting traffic because
there are insufficient network resources to support both sets of TE there are insufficient network resources to support both sets of TE
LSPs when make-before-break is used. However, a PCE may be able to LSPs when make-before-break is used. However, a PCE may be able to
determine a sequence of make-before- break replacement of individual determine a sequence of make-before- break replacement of individual
TE LSPs or small sets of TE LSPs so that the full set of TE LSPs can TE LSPs or small sets of TE LSPs so that the full set of TE LSPs can
be migrated without any disruption. This scenario assumes that the be migrated without any disruption. This scenario assumes that the
bandwidth of existing TE LSP is kept during the migration which is bandwidth of existing TE LSP is kept during the migration, which is
required in optical networks. In packet networks, this assumption required in optical networks. In packet networks, this assumption
can be relaxed as the bandwidth of temporary TE LSPs during migration can be relaxed as the bandwidth of temporary TE LSPs during migration
can be zeroed. can be zeroed.
It may be the case that the reoptimization is radical. This could It may be the case that the reoptimization is radical. This could
mean that it is not possible to apply make-before-break in any order mean that it is not possible to apply make-before-break in any order
to migrate from the old TE LSPs to the new TE LSPs. In this case a to migrate from the old TE LSPs to the new TE LSPs. In this case, a
migration strategy is required that may necessitate TE LSPs being migration strategy is required that may necessitate TE LSPs being
rerouted using make-before-break onto temporary paths in order to rerouted using make-before-break onto temporary paths in order to
make space for the full reoptimization. A PCE might indicate the make space for the full reoptimization. A PCE might indicate the
order in which reoptimized TE LSPs must be established and take over order in which reoptimized TE LSPs must be established and take over
from the old TE LSPs, and may indicate a series of different from the old TE LSPs, and it may indicate a series of different
temporary paths that must be used. Alternatively, the PCE might temporary paths that must be used. Alternatively, the PCE might
perform the global reoptimization as a series of sub-reoptimizations perform the global reoptimization as a series of sub-reoptimizations
by reoptimizing subsets of the total set of TE LSPs. by reoptimizing subsets of the total set of TE LSPs.
The benefit of this multi-step rerouting includes minimization of The benefit of this multi-step rerouting includes minimization of
traffic discruption and optimization gain. However this approach may traffic disruption and optimization gain. However, this approach may
imply some transient packets desequencing, jitter as well as control imply some transient packets desequencing, jitter, as well as control
plane stress. plane stress.
Note also that during reoptimization, traffic disruption may be Note also that during reoptimization, traffic disruption may be
allowed for some TE LSPs carrying low priority services (e.g., allowed for some TE LSPs carrying low priority services (e.g.,
Internet traffic) and not allowed for some TE LSPs carrying mission Internet traffic) and not allowed for some TE LSPs carrying mission
critical services (e.g., voice traffic). critical services (e.g., voice traffic).
4. PCECP Requirements 4. PCECP Requirements
This section provides the PCECP requirements to support global This section provides the PCECP requirements to support global
skipping to change at page 11, line 30 skipping to change at page 11, line 26
"synchronized path computation" in [RFC4655] and [RFC4657]. "synchronized path computation" in [RFC4655] and [RFC4657].
However, an explicit indicator to request a global concurrent However, an explicit indicator to request a global concurrent
optimization is a new requirement. optimization is a new requirement.
o A Global Objective Function (GOF) field in which to specify the o A Global Objective Function (GOF) field in which to specify the
global objective function. The global objective function is the global objective function. The global objective function is the
overarching objective function to which all individual path overarching objective function to which all individual path
computation requests are subjected in order to find a globally computation requests are subjected in order to find a globally
optimal solution. Note that this requirement is covered by optimal solution. Note that this requirement is covered by
"synchronized objective functions" in Section 5.1.7 [RFC4657] and "synchronized objective functions" in Section 5.1.7 [RFC4657] and
that [PCE-OF] defined three global objective functions as follows. that [RFC5541] defined three global objective functions as
A list of available global objective functions SHOULD include the follows. A list of available global objective functions SHOULD
following objective functions at the minimum and SHOULD be include the following objective functions at the minimum and
expandable for future addition: SHOULD be expandable for future addition:
* Minimize aggregate Bandwidth Consumption (MBC) * Minimize aggregate Bandwidth Consumption (MBC)
* Minimize the load of the Most Loaded Link (MLL) * Minimize the load of the Most Loaded Link (MLL)
* Minimize Cumulative Cost of a set of paths (MCC) * Minimize Cumulative Cost of a set of paths (MCC)
o A Global Constraints (GC) field in which to specify the list of o A Global Constraints (GC) field in which to specify the list of
global constraints to which all the requested path computations global constraints to which all the requested path computations
should be subjected. This list SHOULD include the following should be subjected. This list SHOULD include the following
skipping to change at page 12, line 4 skipping to change at page 11, line 47
o A Global Constraints (GC) field in which to specify the list of o A Global Constraints (GC) field in which to specify the list of
global constraints to which all the requested path computations global constraints to which all the requested path computations
should be subjected. This list SHOULD include the following should be subjected. This list SHOULD include the following
constraints at the minimum and SHOULD be expandable for future constraints at the minimum and SHOULD be expandable for future
addition: addition:
* Maximum link utilization value -- This value indicates the * Maximum link utilization value -- This value indicates the
highest possible link utilization percentage set for each link. highest possible link utilization percentage set for each link.
(Note: to avoid floating point numbers, the values should be (Note: to avoid floating point numbers, the values should be
integer values.) integer values.)
* Minimum link utilization value -- This value indicates the * Minimum link utilization value -- This value indicates the
lowest possible link utilization percentage set for each link. lowest possible link utilization percentage set for each link.
(Note: same as above) (Note: same as above.)
* Overbooking factor -- The overbooking factor allows the
* Overbooking Factor -- The overbooking factor allows the
reserved bandwidth to be overbooked on each link beyond its reserved bandwidth to be overbooked on each link beyond its
physical capacity limit. physical capacity limit.
* Maximum number of hops for all the TE LSPs -- This is the * Maximum number of hops for all the TE LSPs -- This is the
largest number of hops that any TE LSP can have. Note that largest number of hops that any TE LSP can have. Note that
this constraint can also be provided on a per TE LSP basis (as this constraint can also be provided on a per-TE-LSP basis (as
requested in [RFC4657] and defined in [PCEP]). requested in [RFC4657] and defined in [RFC5440]).
* Exclusion of links/nodes in all TE LSP path computation (i.e., * Exclusion of links/nodes in all TE LSP path computation (i.e.,
all TE LSPs should not include the specified links/nodes in all TE LSPs should not include the specified links/nodes in
their paths). Note that this constraint can also be provided their paths). Note that this constraint can also be provided
on a per TE LSP basis (as requested in [RFC4657] and defined in on a per-TE-LSP basis (as requested in [RFC4657] and defined in
[PCEP]). [RFC5440]).
* An indication should be available in a path computation * An indication should be available in a path computation
response that further reoptimization may only become available response that further reoptimization may only become available
once existing traffic has been moved to the new TE LSPs. once existing traffic has been moved to the new TE LSPs.
o A Global Concurrent Vector (GCV) field in which to specify all the o A Global Concurrent Vector (GCV) field in which to specify all the
individual path computation requests that are subject to individual path computation requests that are subject to
concurrent path computation and subject to the global objective concurrent path computation and subject to the global objective
function and all of the global constraints. Note that this function and all of the global constraints. Note that this
requirement is entirely fulfilled by the SVEC object in the PCEP requirement is entirely fulfilled by the SVEC object in the PCEP
specification [PCEP]. Since the SVEC object as defined in [PCEP] specification [RFC5440]. Since the SVEC object as defined in
allows identifying a set of concurrent path requests, the SVEC can [RFC5440] allows identifying a set of concurrent path requests,
be reused to specify all the individual concurrent path requests the SVEC can be reused to specify all the individual concurrent
for a global concurrent optimization. path requests for a global concurrent optimization.
o An indicator field in which to indicate the outcome of the o An indicator field in which to indicate the outcome of the
request. When the PCE cannot find a feasible solution with the request. When the PCE cannot find a feasible solution with the
initial request, the reason for failure SHOULD be indicated. This initial request, the reason for failure SHOULD be indicated. This
requirement is partially covered by [RFC4657], but not in this requirement is partially covered by [RFC4657], but not in this
level of detail. The following indicators SHOULD be supported at level of detail. The following indicators SHOULD be supported at
the minimum: the minimum:
* no feasible solution found. Note that this is already covered * no feasible solution found. Note that this is already covered
in [PCEP]. in [RFC5440].
* memory overflow * memory overflow.
* PCE too busy. Note that this is already covered in [PCEP]. * PCE too busy. Note that this is already covered in [RFC5440].
* PCE not capable of concurrent reoptimization * PCE not capable of concurrent reoptimization.
* no migration path available
* administrative privileges do not allow global reoptimization * no migration path available.
* administrative privileges do not allow global reoptimization.
o In order to minimize disruption associated with bulk path o In order to minimize disruption associated with bulk path
provisioning, the following requirements MUST be supported: provisioning, the following requirements MUST be supported:
* The request message MUST allow requesting the PCE to provide * The request message MUST allow requesting the PCE to provide
the order in which TE LSPs should be reoptimized (i.e., the the order in which TE LSPs should be reoptimized (i.e., the
migration path) in order to minimize traffic disruption during migration path) in order to minimize traffic disruption during
the migration. That is the request message MUST allow the migration. That is, the request message MUST allow
indicating to the PCE that the set of paths that will be indicating to the PCE that the set of paths that will be
provided in the response message (PCRep) has to be ordered. provided in the response message (PCRep) has to be ordered.
* In response to the "ordering" request from the PCC, the PCE * In response to the "ordering" request from the PCC, the PCE
MUST be able to indicate in the response message (PCRep) the MUST be able to indicate in the response message (PCRep) the
order in which TE LSPs should be reoptimized so as to minimize order in which TE LSPs should be reoptimized so as to minimize
traffic disruption. It should indicate for each request the traffic disruption. It should indicate for each request the
order in which the old TE LSP should be removed and the order order in which the old TE LSP should be removed and the order
in which the new TE LSP should be setup. If the removal order in which the new TE LSP should be setup. If the removal order
is lower than the setup order this means that make-before-break is lower than the setup order, this means that make-before-
cannot be done for this request. It MAY also be desirable to break cannot be done for this request. It MAY also be
have the PCE indicate whether ordering is in fact required or desirable to have the PCE indicate whether ordering is in fact
not. required or not.
* During a migration it may not be possible to do a make-before- * During a migration, it may not be possible to do a make-before-
break for all existing TE LSPs. The request message MUST allow break for all existing TE LSPs. The request message MUST allow
indicating for each request whether make-before-break is indicating for each request whether make-before-break is
required (e.g. Voice traffic) or break-before-make is required (e.g., voice traffic) or break-before-make is
acceptable (e.g. Internet traffic). The response message must acceptable (e.g., Internet traffic). The response message must
allow indicating TE LSPs for which make-before-break allow indicating TE LSPs for which make-before-break
reoptimization is not possible (this will be deduced from the reoptimization is not possible (this will be deduced from the
TE LSP setup and deletion orders). TE LSP setup and deletion orders).
5. Protocol Extensions for Support of Global Concurrent Optimization 5. Protocol Extensions for Support of Global Concurrent Optimization
This section provides protocol extensions for support of global This section provides protocol extensions for support of global
concurrent optimization. Protocol extensions discussed in this concurrent optimization. Protocol extensions discussed in this
section are built on [PCEP]. section are built on [RFC5440].
The format of a PCReq message after incorporating new requirements The format of a PCReq message after incorporating new requirements
for support of global concurrent optimization is as follows. The for support of global concurrent optimization is as follows. The
message format uses Reduced Backus-Naur Format as defined in [RBNF]. message format uses Reduced Backus-Naur Format as defined in
[RFC5511]. Please see Appendix A for a full set of RBNF fragments
defined in this document and the necessary code license.
<PCReq Message> ::= <Common Header> <PCReq Message> ::= <Common Header>
[<svec-list>] [<svec-list>]
<request-list> <request-list>
The <svec-list> is changed as follows: The <svec-list> is changed as follows:
<svec-list> ::= <SVEC> <svec-list> ::= <SVEC>
[<OF>] [<OF>]
[<GC>] [<GC>]
[<XRO>] [<XRO>]
[<svec-list>] [<svec-list>]
Note that three optional objects are added, following the SVEC Note that three optional objects are added, following the SVEC
object: the OF (Objective Function) object, which is defined in object: the OF (Objective Function) object, which is defined in
skipping to change at page 14, line 29 skipping to change at page 14, line 14
The <svec-list> is changed as follows: The <svec-list> is changed as follows:
<svec-list> ::= <SVEC> <svec-list> ::= <SVEC>
[<OF>] [<OF>]
[<GC>] [<GC>]
[<XRO>] [<XRO>]
[<svec-list>] [<svec-list>]
Note that three optional objects are added, following the SVEC Note that three optional objects are added, following the SVEC
object: the OF (Objective Function) object, which is defined in object: the OF (Objective Function) object, which is defined in
[PCE-OF], the GC (Global Constraints) object, which is defined in [RFC5541], the GC (Global Constraints) object, which is defined in
this document (Section 5.5), as well as the eXclude Route Object this document (Section 5.5), as well as the eXclude Route Object
(XRO) which is defined in [PCE-XRO]. The placement of the OF object (XRO), which is defined in [RFC5521]. The placement of the OF object
(in which the global objective function is specified) in the SVEC- (in which the global objective function is specified) in the SVEC-
list is defined in [PCE-OF]. Details of this change will be list is defined in [RFC5541]. Details of this change will be
discussed in the following sections. discussed in the following sections.
Note also that when the XRO is global to a SVEC, and F bit is set, it Note also that when the XRO is global to an SVEC, and F-bit is set,
SHOULD be allowed to specify multiple Record Route Objects in the it SHOULD be allowed to specify multiple Record Route Objects in the
PCReq message. PCReq message.
5.1. Global Objective Function (GOF) Specification 5.1. Global Objective Function (GOF) Specification
The global objective function can be specified in the PCEP Objective The global objective function can be specified in the PCEP Objective
Function (OF) object, defined in [PCE-OF]. The OF object includes a Function (OF) object, defined in [RFC5541]. The OF object includes a
16 bit Objective Function identifier. As per discussed in [PCE-OF], 16-bit Objective Function identifier. As discussed in [RFC5541],
objective function identifier code points are managed by IANA. Objective Function identifier code points are managed by IANA.
Three global objective functions defined in [PCE-OF] are used in the Three global objective functions defined in [RFC5541] are used in the
context of GCO. context of GCO.
Function Function
Code Description Code Description
4 Minimize aggregate Bandwidth Consumption (MBC) 4 Minimize aggregate Bandwidth Consumption (MBC)
5 Minimize the load of the Most Loaded Link (MLL)* 5 Minimize the load of the Most Loaded Link (MLL)*
6 Minimize Cumulative Cost of a set of paths (MCC) 6 Minimize the Cumulative Cost of a set of paths (MCC)
* Note: This can be achieved by the following objective function: * Note: This can be achieved by the following objective function:
minimize max over all links {(C(i)-A(i))/C(i)} where C(i) is the minimize max over all links {A(i)/C(i)} where C(i) is the link
link capacity for link i and A(i) is the total bandwidth allocated capacity for link i, and A(i) is the total bandwidth allocated on
on link i. link i.
5.2. Indication of Global Concurrent Optimization Requests 5.2. Indication of Global Concurrent Optimization Requests
All the path requests in this application should be indicated so that All the path requests in this application should be indicated so that
the global objective function and all of the global constraints are the global objective function and all of the global constraints are
applied to each of the requested path computation. This can be applied to each of the requested path computation. This can be
indicated implicitly by placing the GCO related objects (GOF, GC or indicated implicitly by placing the GCO related objects (OF, GC, or
XRO) after the SVEC object. That is, if any of these objects follows XRO) after the SVEC object. That is, if any of these objects follows
the SVEC object in the PCReq message, all of the requested path the SVEC object in the PCReq message, all of the requested path
computations specified in the SVEC object are subject to GOF, GC or computations specified in the SVEC object are subject to OF, GC, or
XRO. XRO.
5.3. Request for The Order of TE LSP 5.3. Request for the Order of TE LSP
In order to minimize disruption associated with bulk path In order to minimize disruption associated with bulk path
provisioning, the PCC may indicate to the PCE that the response MUST provisioning, the PCC may indicate to the PCE that the response MUST
be ordered. That is, the PCE has to include the order in which TE be ordered. That is, the PCE has to include the order in which TE
LSPs MUST be moved so as to minimize traffic disruption. To support 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 such indication a new flag, the D flag, is defined in the RP object
as follows: as follows:
D bit (orDer - 1 bit): when set, in a PCReq message, the requesting D-bit (orDer - 1 bit): when set, in a PCReq message, the requesting
PCC requires the PCE to specify in the PCRep message the order in PCC requires the PCE to specify in the PCRep message the order in
which this particular path request is to be provisioned relative to which this particular path request is to be provisioned relative to
other requests. other requests.
To support the determination of whether make-before-break To support the determination of whether make-before-break
optimization is required, a new flag, the M flag, is defined in the optimization is required, a new flag, the M flag, is defined in the
RP object as follows. RP object as follows.
M bit (Make-before-break - 1 bit): when set, this indicates that a M-bit (Make-before-break - 1 bit): when set, this indicates that a
make-before-break reoptimization is required for this request. make-before-break reoptimization is required for this request.
When M bit is not set, this implies that a break-before-make When the M-bit is not set, this implies that a break-before-make
reoptimization is allowed for this request. Note that M bit can be reoptimization is allowed for this request. Note that the M-bit can
set only if the R (Reoptimization) flag is set. be set only if the R (Reoptimization) flag is set.
Two new bit flags are defined to be carried in the Flags field Two new bit flags are defined to be carried in the Flags field in the
in the RP Object. RP object.
Bit 22 (D-bit): When set, report of the request order is required.
Bit 21 (M-bit): When set, make-before-break is required. Bit 21 (M-bit): When set, make-before-break is required.
Bit 22 (D-bit): When set, report of the request order is required.
5.4. The Order Response 5.4. The Order Response
The PCE MUST specify the order number in response to the Order 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 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 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, support such an ordering indication, a new optional TLV, the Order
is defined in the RP object. TLV, is defined in the RP object.
The Order TLV is an optional TLV in the RP object, that indicates the The Order TLV is an optional TLV in the RP object, that indicates the
order in which the old TE LSP must be removed and the new TE LSP must order in which the old TE LSP must be removed and the new TE LSP must
be setup during a reoptimization. It is carried in the PCRep message be setup during a reoptimization. It is carried in the PCRep message
in response to a reoptimization request. in response to a reoptimization request.
The Order TLV MUST be included in the RP object in the PCRep message The Order TLV MUST be included in the RP object in the PCRep message
if the D bit is set in the RP object in the PCReq message. if the D-bit is set in the RP object in the PCReq message.
The format of the Order TLV is as follows: The format of the Order TLV is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delete Order | | Delete Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Order | | Setup Order |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The Order TLV in the RP object in the PCRep Message Figure 2: The Order TLV in the RP Object in the PCRep Message
Type: To be defined by IANA (suggested value = 5) Type: 5
Length: Variable Length: Variable
Delete Order: 32 bit integer that indicates the order in which the Delete Order: 32-bit integer that indicates the order in which the
old TE LSP should be removed old TE LSP should be removed.
Setup Order: 32-bit integer that indicates the order in which the new
TE LSP should be setup.
Setup Order: 32 bit integer that indicates the order in which the new
TE LSP should be setup
The delete order SHOULD NOT be equal to the setup order. If the The delete order SHOULD NOT be equal to the setup order. If the
delete order is higher than the setup order, this means that the delete order is higher than the setup order, this means that the
reoptimization can be done in a make-before-break manner, else it reoptimization can be done in a make-before-break manner, else it
cannot be done in a make-before-break manner. cannot be done in a make-before-break manner.
For a new TE LSP the delete order is not applicable. The value 0 is For a new TE LSP, the delete order is not applicable. The value 0 is
designated to specify this case. When the value of the delete order designated to specify this case. When the value of the delete order
is 0, it implies that the resulting TE LSP is a new TE LSP. is 0, it implies that the resulting TE LSP is a new TE LSP.
To illustrate this, consider a network with two established TE LSPs: To illustrate this, consider a network with two established TE LSPs:
R1 with path P1 and R2 with path P2. During a reoptimization the PCE R1 with path P1, and R2 with path P2. During a reoptimization, the
may provide the following ordered reply: PCE may provide the following ordered reply:
R1, path P1', remove order 1, setup order 4 R1, path P1', remove order 1, setup order 4
R2, path P2', remove order 3, setup order 2 R2, path P2', remove order 3, setup order 2
This indicates that the NMS should do the following sequence of This indicates that the NMS should do the following sequence of
tasks: tasks:
1: Remove path P1 1: Remove path P1
2: Setup path P2' 2: Setup path P2'
3: Remove path P2 3: Remove path P2
skipping to change at page 17, line 38 skipping to change at page 17, line 30
That is, R1 is reoptimized in a break-before-make manner and R2 in a That is, R1 is reoptimized in a break-before-make manner and R2 in a
make-before-break manner. make-before-break manner.
5.5. GLOBAL CONSTRAINTS (GC) Object 5.5. GLOBAL CONSTRAINTS (GC) Object
The GLOBAL CONSTRAINTS (GC) Object is used in a PCReq message to The GLOBAL CONSTRAINTS (GC) Object is used in a PCReq message to
specify the necessary global constraints that should be applied to specify the necessary global constraints that should be applied to
all individual path computations for a global concurrent path all individual path computations for a global concurrent path
optimization request. optimization request.
GLOBAL CONSTRAINTS Object-Class is to be assigned by IANA GLOBAL-CONSTRAINTS Object-Class is 24.
(recommended value=24)
GLOBAL CONSTRAINTS Object-Type is to be assigned by IANA (recommended Global Constraints Object-Type is 1.
value=1)
The format of the GC object body that includes the global constraints The format of the GC object body that includes the global constraints
is as follows: is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 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 | | MH | MU | mU | OB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: GC body object format Figure 3: GC Body Object Format
MH (Max Hop: 8 bits): 8 bit integer that indicates the maximum hop MH (Max Hop: 8 bits): 8-bit integer that indicates the maximum hop
count for all the TE LSPs. count for all the TE LSPs.
MU (Max Utilization Percentage: 8 bits) : 8 bits integer that MU (Max Utilization Percentage: 8 bits) : 8-bit integer that
indicates the upper bound utilization percentage by which all link indicates the upper-bound utilization percentage by which all links
should be bound. Utilization = (Link Capacity - Allocated Bandwidth should be bound. Utilization = (Link Capacity - Allocated Bandwidth
on the Link)/ Link Capacity on the Link)/ Link Capacity. MU is intended to be an integer that
can only be between 0 and 100.
mU (minimum Utilization Percentage: 8 bits) : 8 bits integer that mU (minimum Utilization Percentage: 8 bits) : 8-bit integer that
indicates the lower bound utilization percentage by which all link indicates the lower-bound utilization percentage by which all links
should be bound. should be bound. mU is intended to be an integer that can only be
between 0 and 100.
OB (Over Booking factor Percentage: 8 bits) : 8 bits integer that OB (Over Booking factor Percentage: 8 bits) : 8-bit integer that
indicates the overbooking percentage that allows the reserved indicates the overbooking percentage that allows the reserved
bandwidth to be overbooked on each link beyond its physical capacity bandwidth to be overbooked on each link beyond its physical capacity
limit. The value, for example, 10% means that 110 Mbps can be limit. The value, for example, 10% means that 110 Mbps can be
reserved on a 100Mbps link. 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 The exclusion of the list of nodes/links from a global path
computation can be done by including the XRO object following the GC computation can be done by including the XRO object following the GC
object in the new SVEC list definition. object in the new SVEC-list definition.
Optional TLVs may be included within the GC object body to specify Optional TLVs may be included within the GC object body to specify
additional global constraints. The TLV format and processing is additional global constraints. The TLV format and processing is
consistent with Section 7.1 of RFC5440. Any TLVs will be allocated consistent with Section 7.1 of RFC5440. Any TLVs will be allocated
from the "PCEP TLV Type Indicators" registry. Note that no TLVs are from the "PCEP TLV Type Indicators" registry. Note that no TLVs are
defined in this document. defined in this document.
5.6. Error Indicator 5.6. Error Indicator
To indicate errors associated with the global concurrent path To indicate errors associated with the global concurrent path
optimization request, a new Error-Type (14) and subsequent error- optimization request, a new Error-Type (14) and subsequent error-
values are defined as follows for inclusion in the PCEP-ERROR object: values are defined as follows for inclusion in the PCEP-ERROR Object:
A new Error-Type (15) and subsequent error-values are defined as A new Error-Type (15) and subsequent error-values are defined as
follows: follows:
Error-Type=15 and Error-Value=1: if a PCE receives a global Error-Type=15; Error-value=1: if a PCE receives a global concurrent
concurrent path optimization request and the PCE is not capable of path optimization request and the PCE is not capable of processing
processing the request due to insufficient memory, the PCE MUST send the request due to insufficient memory, the PCE MUST send a PCErr
a PCErr message with a PCEP ERROR object (Error-Type=15) and an message with a PCEP-ERROR Object (Error-Type=15) and an Error-value
Error-Value (Error-Value=1). The PCE stops processing the request. (Error-value=1). The PCE stops processing the request. The
The corresponding global concurrent path optimization request MUST be corresponding global concurrent path optimization request MUST be
cancelled at the PCC. cancelled at the PCC.
Error-Type=15; Error-Value=2: if a PCE receives a global concurrent Error-Type=15; Error-value=2: if a PCE receives a global concurrent
path optimization request and the PCE is not capable of global path optimization request and the PCE is not capable of global
concurrent optimization, the PCE MUST send a PCErr message with a concurrent optimization, the PCE MUST send a PCErr message with a
PCEP-ERROR Object (Error-Type=15) and an Error-Value (Error-Value=2). PCEP-ERROR Object (Error-Type=15) and an Error-value (Error-value=2).
The PCE stops processing the request. The corresponding global The PCE stops processing the request. The corresponding global
concurrent path optimization MUST be cancelled at the PCC. concurrent path optimization MUST be cancelled at the PCC.
To indicate an error associated with policy violation, a new error To indicate an error associated with policy violation, a new error
value "global concurrent optimization not allowed" should be added to value "global concurrent optimization not allowed" should be added to
an existing error code for policy violation (Error-Type=5) as defined an existing error code for policy violation (Error-Type=5) as defined
in [RFC5440]. in [RFC5440].
Error-Type=5; Error-Value=5: if a PCE receives a global concurrent Error-Type=5; Error-value=5: if a PCE receives a global concurrent
path optimization request which is not compliant with administrative path optimization request that is not compliant with administrative
privileges (i.e., the PCE policy does not support global concurrent privileges (i.e., the PCE policy does not support global concurrent
optimization), the PCE sends a PCErr message with a PCEP-ERROR Object optimization), the PCE sends a PCErr message with a PCEP-ERROR Object
(Error-Type=5) and an Error-Value (Error-Value=5). The PCE stops the (Error-Type=5) and an Error-value (Error-value=5). The PCE stops the
processing the request. The corresponding global concurrent path processing the request. The corresponding global concurrent path
computation MUST be cancelled at the PCC. computation MUST be cancelled at the PCC.
5.7. NO-PATH Indicator 5.7. NO-PATH Indicator
To communicate the reason(s) for not being able to find global To communicate the reason(s) for not being able to find global
concurrent path computation, the NO-PATH object can be used in the concurrent path computation, the NO-PATH object can be used in the
PCRep message. The format of the NO-PATH object body is defined in PCRep message. The format of the NO-PATH object body is defined in
[RFC5440]. The object may contain a NO-PATH-VECTOR TLV to provide [RFC5440]. The object may contain a NO-PATH-VECTOR TLV to provide
additional information about why a path computation has failed. additional information about why a path computation has failed.
skipping to change at page 20, line 7 skipping to change at page 19, line 40
NO-PATH-VECTOR TLV carried in the NO-PATH Object. NO-PATH-VECTOR TLV carried in the NO-PATH Object.
Bit 6: When set, the PCE indicates that no migration path was found. 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 Bit 7: When set, the PCE indicates no feasible solution was found
that meets all the constraints associated with global concurrent path that meets all the constraints associated with global concurrent path
optimization in the PCRep message. optimization in the PCRep message.
6. Manageability Considerations 6. Manageability Considerations
Manageability of Global Concurrent Path Computation with PCE must Manageability of global concurrent path computation with PCE must
address the following considerations: address the following considerations:
6.1. Control of Function and Policy 6.1. Control of Function and Policy
In addition to the parameters already listed in Section 8.1 of In addition to the parameters already listed in Section 8.1 of
[RFC5440], a PCEP implementation SHOULD allow configuring the following [RFC5440], a PCEP implementation SHOULD allow configuring the
PCEP session parameters on a PCC: following PCEP session parameters on a PCC:
o The ability to send a GCO request. o The ability to send a GCO request.
In addition to the parameters already listed in Section 8.1 of In addition to the parameters already listed in Section 8.1 of
[RFC5440], a PCEP implementation SHOULD allow configuring the following [RFC5440], a PCEP implementation SHOULD allow configuring the
PCEP session parameters on a PCE: following PCEP session parameters on a PCE:
o The support for Global Concurrent Optimization. o The support for Global Concurrent Optimization.
o The maximum number of synchronized path requests per request o The maximum number of synchronized path requests per request
message. message.
o A set of GCO specific policies (authorized sender, request rate o A set of GCO specific policies (authorized sender, request rate
limiter, etc). limiter, etc.).
These parameters may be configured as default parameters for any PCEP These parameters may be configured as default parameters for any PCEP
session the PCEP speaker participates in, or may apply to a specific 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 session with a given PCEP peer or a specific group of sessions with a
specific group of PCEP peers. specific group of PCEP peers.
6.2. Information and Data Models, e.g. MIB module 6.2. Information and Data Models (e.g., MIB Module)
Extensions to the PCEP MIB module defined in [PCEP-MIB] should be Extensions to the PCEP MIB module defined in [PCEP-MIB] should be
defined, so as to cover the GCO information introduced in this defined, so as to cover the GCO information introduced in this
document. document.
6.3. Liveness Detection and Monitoring 6.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already detection and monitoring requirements in addition to those already
listed in Section 8.3 of [RFC5440]. listed in Section 8.3 of [RFC5440].
6.4. Verifying Correct Operation 6.4. Verifying Correct Operation
Mechanisms defined in this document do not imply any new verification Mechanisms defined in this document do not imply any new verification
requirements in addition to those already listed in Section 8.4 of requirements in addition to those already listed in Section 8.4 of
[RFC5440] [RFC5440]
6.5. Requirements on Other Protocols and Functional Components 6.5. Requirements on Other Protocols and Functional Components
The PCE Discovery mechanisms ([RFC5088] and [RFC5089]) may be used The PCE Discovery mechanisms ([RFC5088] and [RFC5089]) may be used to
to advertise global concurrent path computation capabilities to PCCs. advertise global concurrent path computation capabilities to PCCs. A
A New Flag (value=9) in PCE-CAP-FLAGs Sub-TLV should be assigned to new flag (value=9) in PCE-CAP-FLAGs Sub-TLV has been assigned to be
be able to indicate GCO capability. able to indicate GCO capability.
6.6. Impact on Network Operation 6.6. Impact on Network Operation
Mechanisms defined in this document do not imply any new network Mechanisms defined in this document do not imply any new network
operation requirements in addition to those already listed in Section operation requirements in addition to those already listed in Section
8.6 of [RFC5440]. 8.6 of [RFC5440].
7. Security Considerations 7. Security Considerations
When global re-optimization is applied to an active network, it could When global reoptimization is applied to an active network, it could
be extremely disruptive. Although the real security and policy be extremely disruptive. Although the real security and policy
issues apply at the NMS, if the wrong results are returned to the issues apply at the NMS, if the wrong results are returned to the
NMS, the wrong actions may be taken in the network. Therefore, it is NMS, the wrong actions may be taken in the network. Therefore, it is
very important that the operator issuing the commands has sufficient very important that the operator issuing the commands has sufficient
authority and is authenticated, and that the computation request is authority and is authenticated, and that the computation request is
subject to appropriate policy. subject to appropriate policy.
The mechanism defined in [RFC5440] to secure a PCEP session can be used The mechanism defined in [RFC5440] to secure a PCEP session can be
to secure global concurrent path computation requests/responses. used to secure global concurrent path computation requests/responses.
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.
9. IANA Considerations 8. IANA Considerations
IANA maintains a registry of PCEP parameters. IANA is requested to IANA maintains a registry of PCEP parameters. IANA has made
make allocations from the sub-registries as described in the allocations from the sub-registries as described in the following
following sections. sections.
9.1. Request Parameter Bit Flags 8.1. Request Parameter Bit Flags
As described in Section 5.3, two new bit flags are defined for As described in Section 5.3, two new bit flags are defined for
inclusion in the Flags field of the RP object. IANA is requested to inclusion in the Flags field of the RP object. IANA has made the
make the following allocations from the "Request Parameter Bit Flags" following allocations from the "RP Object Flag Field" sub-registry.
sub-registry.
Bit Name Description Reference Bit Description Reference
22 D-bit Report the request order [This.I-D] 21 Make-before-break (M-bit) [RFC5557]
21 M-bit Make-before-break [This.I-D] 22 Report the request order (D-bit) [RFC5557]
9.2. New PCEP TLV 8.2. New PCEP TLV
As described in Section 5.4, a new PCEP TLV is defined to indicate As described in Section 5.4, a new PCEP TLV is defined to indicate
the setup and delete order of TE LSPs in a GCO. IANA is requested to the setup and delete order of TE LSPs in a GCO. IANA has made the
make the following allocation from the "PCEP TLV Types" sub-registry. following allocation from the "PCEP TLV Type Indicators" sub-
registry.
TLV Type Meaning Reference TLV Type Meaning Reference
5 Order TLV [This.I-D] 5 Order TLV [RFC5557]
9.3. New Flag in PCE-CAP-FLAGS Sub-TLV in PCED 8.3. New Flag in PCE-CAP-FLAGS Sub-TLV in PCED
As described in Section 6.5, a new PCE-CAP-FLAGS Sub-TLV is As described in Section 6.5, a new PCE-CAP-FLAGS Sub-TLV is defined
defined to indicate a GCO capability. IANA is requested to make the to indicate a GCO capability. IANA has made the following allocation
following allocation from the "PCE-CAP-FLAGS TLV Types" sub-registry. from the "Path Computation Element (PCE) Capability Flags" sub-
The "PCE Capability Flags Registry" is created by section 7.2 of registry, which was created by Section 7.2 of RFC 5088. It is an
RFC 5088. It is an OSPF registry. OSPF registry.
FLAG Meaning Reference FLAG Meaning Reference
9 Global Concurrent Optimization (GCO)[This.I-D] 9 Global Concurrent Optimization (GCO) [RFC5557]
9.4. New PCEP Object 8.4. New PCEP Object
As descried in Section 5.5, a new PCEP object is defined to carry As descried in Section 5.5, a new PCEP object is defined to carry
global constraints. IANA is requested to make the following global constraints. IANA has made the following allocation from the
allocation from the "PCEP Objects" sub-registry. "PCEP Objects" sub-registry.
Object Name Reference Object Name Reference
Class Class
24 GLOBAL-CONSTRAINTS [This.I-D] 24 GLOBAL-CONSTRAINTS [RFC5557]
Object-Type Object-Type
1: Global Constraints [This.I-D] 1: Global Constraints [RFC5557]
9.5. New PCEP Error Codes 8.5. New PCEP Error Codes
As described in Section 5.6, new PCEP error codes are defined for GCO 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 errors. IANA has made allocations from the "PCEP-ERROR Object Error
Types and Values" sub-registry as set out in the following sections. Types and Values" sub-registry as set out in the following sections.
9.5.1. New Error-Values for Existing Error-Types 8.5.1. New Error-Values for Existing Error-Types
Error Error-
Type Meaning Reference Type Meaning Reference
5 Policy violation 5 Policy violation
Error-value=5: [This.I-D] Error-value=5: [RFC5557]
Global concurrent optimization not allowed Global concurrent optimization not allowed
9.5.2. New Error-Types and Error-Values 8.5.2. New Error-Types and Error-Values
Error Error-
Type Meaning Reference Type Meaning Reference
15 Global Concurrent Optimization Error [This.I-D] 15 Global Concurrent Optimization Error [RFC5557]
Error-value=1: Error-value=1:
Insufficient memory [This.I-D] Insufficient memory [RFC5557]
Error-value=2: Error-value=2:
Global concurrent optimization not supported Global concurrent optimization not supported
[This.I-D] [RFC5557]
9.6. New No-Path Reasons 8.6. New No-Path Reasons
IANA is requested to make the following allocations from the "No-Path IANA has made the following allocations from the "NO-PATH-VECTOR TLV
Reasons" sub-registry for bit flags carried in the NO-PATH-VECTOR TLV Flag Field" sub-registry for bit flags carried in the NO-PATH-VECTOR
in the PCEP NO-PATH object as described in Section 5.7. TLV in the PCEP NO-PATH object as described in Section 5.7.
Bit Bit
Number Name Reference Number Name Reference
26 No GCO migration path found [This.I-D] 25 No GCO solution found [RFC5557]
25 No GCO solution found [This.I-D] 26 No GCO migration path found [RFC5557]
10. References 9. References
10.1. Normative References 9.1. Normative References
[BRPC] Vasseur, JP., Ed., "A Backward Recursive PCE-based [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
Computation (BRPC) procedure to compute shortest inter- "A Backward-Recursive PCE-Based Computation (BRPC)
domain Traffic Engineering Label Switched Paths, Procedure to Compute Shortest Constrained Inter-Domain
draft-ietf-pce-brpc, work in progress". Traffic Engineering Label Switched Paths", RFC 5441, April
2009.
[PCE-OF] Le Roux, JL., Vasseur, JP., and Y. Lee, "Objective [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Function encoding in Path Computation Element Objective Functions in Path Computation Element
communication and discovery protocols, Communication Protocol (PCEP)", RFC 5541, May 2009.
draft-ietf-pce-of, work in progress".
[PCE-XRO] Oki, E. and A. Farrel, "Extensions to the Path Computation [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Element Communication Protocol (PCEP) for Route Path Computation Element Communication Protocol (PCEP) for
Exclusions, draft-ietf-pce-pcep-xro, work in progress". Route Exclusions", RFC 5521, April 2009.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation
Element (PCE) communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009. March 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC5088] Le Roux, J., Vasseur, J., Ikejiri, Y., and R. Zhang, "OSPF [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Protocol Extensions for Path Computation Element (PCE) Zhang, "OSPF Protocol Extensions for Path Computation
Discovery", RFC 5088, January 2008. Element (PCE) Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, J., Vasseur, J., Ikejiri, Y., and R. Zhang, [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
"IS-IS Protocol Extensions for Path Computation Element Zhang, "IS-IS Protocol Extensions for Path Computation
(PCE) Discovery", RFC 5089, January 2008. Element (PCE) Discovery", RFC 5089, January 2008.
10.2. Informative References 9.2. Informative References
[PCE-MLN] Oki, E., Le Roux, J., and A. Farrel, "Framework for PCE- [PCE-MLN] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
based inter-layer MPLS and GMPLS traffic engineering", "Framework for PCE-Based Inter-Layer MPLS and GMPLS
draft-ietf-pce-inter-layer-frwk, work in progress. Traffic Engineering", Work in Progress, March 2009.
[PCEP-MIB] Stephen, E. and K. Koushik, "PCE communication [PCEP-MIB] Koushik, K. and E. Stephan, "PCE communication protocol
protocol(PCEP) Management Information Base", (PCEP) Management Information Base", Work in Progress,
draft-kkoushik-pce-pcep-mib, work in progress. November 2008.
[RBNF] A. Farrel, "Reduced Backus-Naur Form (RBNF) - A Syntax [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used in Various Protocol Specifications", draft-farrel- Used to Form Encoding Rules in Various Routing Protocol
rtg-common-bnf, work in progress. Specifications", RFC 5511, April 2009.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Element (PCE)-Based Architecture", RFC 4655, August 2006. Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation
Communication Protocol Generic Requirements", RFC 4657, Element (PCE) Communication Protocol Generic
September 2006. Requirements", RFC 4657, September 2006.
[RFC4674] Le Roux, J., "Requirements for Path Computation Element [RFC4674] Le Roux, J., Ed., "Requirements for Path Computation
(PCE) Discovery", RFC 4674, October 2006. Element (PCE) Discovery", RFC 4674, October 2006.
[RFC5212] Shiomoto, K., Ed., "Requirements for GMPLS-based multi- [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
region and multi-layer networks (MRN/MLN)", RFC 5212, M., and D. Brungard, "Requirements for GMPLS-Based Multi-
July 2008. Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July
2008.
10. Acknowledgments
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.
Appendix A. RBNF Code Fragments
Copyright (c) 2009 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
- Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the
distribution.
- Neither the name of Internet Society, IETF or IETF Trust, nor the
names of specific contributors, may be used to endorse or promote
products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
<svec-list> ::= <SVEC>
[<OF>]
[<GC>]
[<XRO>]
[<svec-list>]
Authors' Addresses Authors' Addresses
Young Lee Young Lee
Huawei Huawei
1700 Alma Drive, Suite 100 1700 Alma Drive, Suite 100
Plano, TX 75075 Plano, TX 75075
US US
Phone: +1 972 509 5599 x2240 Phone: +1 972 509 5599 x2240
Fax: +1 469 229 5397 Fax: +1 469 229 5397
Email: ylee@huawei.com EMail: ylee@huawei.com
JL Le Roux JL Le Roux
France Telecom France Telecom
2, Avenue Pierre-Marzin 2, Avenue Pierre-Marzin
Lannion 22307 Lannion 22307
FRANCE FRANCE
Email: jeanlouis.leroux@orange-ftgroup.com EMail: jeanlouis.leroux@orange-ftgroup.com
Daniel King Daniel King
Old Dog Consulting Old Dog Consulting
United Kingdom United Kingdom
Phone: EMail: daniel@olddog.co.uk
Fax:
Email: daniel@olddog.co.uk
Eiji Oki Eiji Oki
University of Electro-Communications University of Electro-Communications
1-5-1 Chofugaoka 1-5-1 Chofugaoka
Chofu, Tokyo 182-8585 Chofu, Tokyo 182-8585
JAPAN JAPAN
Email: oki@ice.uec.ac.jp EMail: oki@ice.uec.ac.jp
Full Copyright Statement
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
ALL IETF Documents 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 definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
 End of changes. 164 change blocks. 
362 lines changed or deleted 412 lines changed or added

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