draft-ietf-pce-global-concurrent-optimization-04.txt   draft-ietf-pce-global-concurrent-optimization-05.txt 
Network Working Group Y. Lee Network Working Group Y. Lee
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track JL. Le Roux Intended status: Standards Track JL. Le Roux
Expires: January 15, 2009 France Telecom Expires: April 26, 2009 France Telecom
D. King D. King
Old Dog Consulting Old Dog Consulting
E. Oki E. Oki
NTT NTT
July 14, 2008 October 23, 2008
Path Computation Element Communication Protocol (PCECP) Requirements and Path Computation Element Communication Protocol (PCECP) Requirements and
Protocol Extensions In Support of Global Concurrent Optimization Protocol Extensions In Support of Global Concurrent Optimization
draft-ietf-pce-global-concurrent-optimization-04.txt draft-ietf-pce-global-concurrent-optimization-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009. This Internet-Draft will expire on April 26, 2009.
Abstract Abstract
The Path Computation Element (PCE) is a network component, The Path Computation Element (PCE) is a network component,
application, or node that is capable of performing path computations application, or node that is capable of performing path computations
at the request of Path Computation Clients (PCCs). The PCE is at the request of Path Computation Clients (PCCs). The PCE is
applied in Multiprotocol Label Switching Traffic Engineering applied in Multiprotocol Label Switching Traffic Engineering
(MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to
determine the routes of Label Switched Paths (LSPs) through the determine the routes of Label Switched Paths (LSPs) through the
network. In this context a PCC may be a Label Switching Router network. In this context a PCC may be a Label Switching Router
(LSR), a Network Management System (NMS), or another PCE. The Path (LSR), a Network Management System (NMS), or another PCE. The Path
Computation Element Communication Protocol (PCEP) is specified for Computation Element Communication Protocol (PCEP) is specified for
communications between PCCs and PCEs, and between cooperating PCEs. communications between PCCs and PCEs, and between cooperating PCEs.
When computing or re-optimizing the routes of a set of LSPs through a When computing or re-optimizing the routes of a set of TE LSPs
network it may be advantageous to perform bulk path computations in through a network it may be advantageous to perform bulk path
order to avoid blocking problems and to achieve more optimal network- computations in order to avoid blocking problems and to achieve more
wide solutions. Such bulk optimization is termed Global Concurrent optimal network-wide solutions. Such bulk optimization is termed
Optimization (GCO). A GCO is able to simultaneously consider the Global Concurrent Optimization (GCO). A GCO is able to
entire topology of the network and the complete set of existing LSPs, simultaneously consider the entire topology of the network and the
and their respective constraints, and look to optimize or re-optimize complete set of existing TE LSPs, and their respective constraints,
the entire network to satisfy all constraints for all LSPs. A GCO and look to optimize or re-optimize the entire network to satisfy all
may also be applied to some subset of the LSPs in a network. The GCO constraints for all TE LSPs. A GCO may also be applied to some
application is primarily a Network Management System (NMS) solution. subset of the TE LSPs in a network. The GCO application is primarily
a Network Management System (NMS) solution.
While GCO is applicable to any simultaneous request for multiple LSPs While GCO is applicable to any simultaneous request for multiple TE
(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
invisaged that global concurrent reoptimization would be applied in a envisaged that global concurrent reoptimization would be applied in a
network (such as an MPLS-TE network) that contains a very large network (such as an MPLS-TE network) that contains a very large
number of very low bandwidth or zero bandwidth LSPs since the large number of very low bandwidth or zero bandwidth TE LSPs since the
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 LSP reoptimization is unlikely to reoptimization relative to single TE LSP reoptimization is unlikely
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 LSPs reoptimization in a network with a high rate of change of TE LSPs
(churn) is not advised because of the likelihood that LSPs would (churn) is not advised because of the likelihood that TE LSPs would
change before they could be gloablly reoptimized. Global 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.
This document provides application-specific requirements and the PCEP This document provides application-specific requirements and the PCEP
extensions in support of GCO applications. extensions in support of GCO applications.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
skipping to change at page 3, line 23 skipping to change at page 3, line 23
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. Re-optimization of Existing Networks . . . . . . . . . . . 8
3.3.1. Reconfiguration of the Virtual Network Topology 3.3.1. Reconfiguration of the Virtual Network Topology
(VNT) . . . . . . . . . . . . . . . . . . . . . . . . 9 (VNT) . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2. Traffic Migration . . . . . . . . . . . . . . . . . . 9 3.3.2. Traffic Migration . . . . . . . . . . . . . . . . . . 9
4. PCECP Requirements . . . . . . . . . . . . . . . . . . . . . . 11 4. PCECP Requirements . . . . . . . . . . . . . . . . . . . . . . 11
5. Protocol Extensions for Support of Global Concurrent 5. Protocol Extensions for Support of Global Concurrent
Optimization . . . . . . . . . . . . . . . . . . . . . . . . . 15 Optimization . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Global Objective Function (GOF) Specification . . . . . . 15 5.1. Global Objective Function (GOF) Specification . . . . . . 15
5.2. Indication of Global Concurrent Optimization Requests . . 16 5.2. Indication of Global Concurrent Optimization Requests . . 16
5.3. Request for The Order of LSP . . . . . . . . . . . . . . . 16 5.3. Request for The Order of TE LSP . . . . . . . . . . . . . 16
5.4. The Order Response . . . . . . . . . . . . . . . . . . . . 17 5.4. The Order Response . . . . . . . . . . . . . . . . . . . . 17
5.5. GLOBAL CONSTRAINTS (GC) Object . . . . . . . . . . . . . . 18 5.5. GLOBAL CONSTRAINTS (GC) Object . . . . . . . . . . . . . . 18
5.6. Error Indicator . . . . . . . . . . . . . . . . . . . . . 19 5.6. Error Indicator . . . . . . . . . . . . . . . . . . . . . 19
5.7. NO-PATH Indicator . . . . . . . . . . . . . . . . . . . . 20 5.7. NO-PATH Indicator . . . . . . . . . . . . . . . . . . . . 20
6. Manageability Considerations . . . . . . . . . . . . . . . . . 21 6. Manageability Considerations . . . . . . . . . . . . . . . . . 21
6.1. Control of Function and Policy . . . . . . . . . . . . . . 21 6.1. Control of Function and Policy . . . . . . . . . . . . . . 21
6.2. Information and Data Models, e.g. MIB module . . . . . . . 21 6.2. Information and Data Models, e.g. MIB module . . . . . . . 21
6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21
6.4. Verifying Correct Operation . . . . . . . . . . . . . . . 21 6.4. Verifying Correct Operation . . . . . . . . . . . . . . . 21
6.5. Requirements on Other Protocols and Functional 6.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 22 Components . . . . . . . . . . . . . . . . . . . . . . . . 22
6.6. Impact on Network Operation . . . . . . . . . . . . . . . 22 6.6. Impact on Network Operation . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9.1. Request Parameter Bit Flags . . . . . . . . . . . . . . . 25 9.1. Request Parameter Bit Flags . . . . . . . . . . . . . . . 25
9.2. New PCEP TLV . . . . . . . . . . . . . . . . . . . . . . . 25 9.2. New PCEP TLV . . . . . . . . . . . . . . . . . . . . . . . 25
9.3. New PCEP Object . . . . . . . . . . . . . . . . . . . . . 25 9.3. New Flag in PCE-CAP-FLAGS Sub-TLV in PCED . . . . . . . . 25
9.4. New PCEP Error Codes . . . . . . . . . . . . . . . . . . . 26 9.4. New PCEP Object . . . . . . . . . . . . . . . . . . . . . 26
9.4.1. New Error-Values for Existing Error-Types . . . . . . 26 9.5. New PCEP Error Codes . . . . . . . . . . . . . . . . . . . 26
9.4.2. New Error-Types and Error-Values . . . . . . . . . . . 26 9.5.1. New Error-Values for Existing Error-Types . . . . . . 26
9.5. New No-Path Reasons . . . . . . . . . . . . . . . . . . . 26 9.5.2. New Error-Types and Error-Values . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.6. New No-Path Reasons . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.2. Informative References . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 31
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
skipping to change at page 5, line 6 skipping to change at page 5, line 6
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 promote the use of such
systems for offline processing. Online application of this work systems for offline processing. Online application of this work
should only be considered with proven empirical validation. should only be considered with proven empirical validation.
As new 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 LSPs within network no longer provides optimal use of the of TE LSPs within network no longer provides optimal use of the
available capacity. A global concurrent path computation is able to available capacity. A global concurrent path computation is able to
simultaneously consider the entire topology of the network and the simultaneously consider the entire topology of the network and the
complete set of existing LSPs and their respective constraints, and complete set of existing TE LSPs and their respective constraints,
look to re-optimize the entire network to satisfy all constraints for and look to re-optimize the entire network to satisfy all constraints
all LSPs. Alternatively, the application may consider a subset of for all TE LSPs. Alternatively, the application may consider a
the LSPs and/or a subset of the network topology. subset of the TE LSPs and/or a subset of the network topology. Note
that other preemption can also help reducing the fragmentation
issues.
While GCO is applicable to any simultaneous request for multiple LSPs While GCO is applicable to any simultaneous request for multiple TE
(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
invisaged that global concurrent reoptimization would be applied in a RECOMMENDED that global concurrent reoptimization would be applied in
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 LSPs since the large number of very low bandwidth or zero bandwidth TE LSPs since the
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 LSP reoptimization is unlikely to reoptimization relative to single TE LSP reoptimization is unlikely
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 LSPs reoptimization in a network with a high rate of change of TE LSPs
(churn) is not advised because of the likelihood that LSPs would (churn) is NOT RECOMMENDED because of the likelihood that TE LSPs
change before they could be gloablly 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.
As the PCE has the potential to provide solutions in all path
computation solutions in a variety of environments and is a candidate
for performing path computations in support of GCO.
The main focus of this document is to highlight the PCC-PCE The main focus of this document is to highlight the PCC-PCE
communication needs in support of a concurrent path computation communication needs in support of a concurrent path computation
applications and to define protocol extensions to meet those needs. applications and to define protocol extensions to meet those needs.
The PCC-PCE requirements addressed herein are specific to the context The PCC-PCE requirements addressed herein are specific to the context
where the PCE is a specialized PCE that is capable of performing where the PCE is a specialized PCE that is capable of performing
computations in support of GCO. Discovery of such capabilities might computations in support of GCO. Discovery of such capabilities might
be desirable and could be achieved through extensions to the PCE be desirable and could be achieved through extensions to the PCE
discovery mechanisms [RFC4674], [RFC5088], [RFC5089], but that is out discovery mechanisms [RFC4674], [RFC5088], [RFC5089], but that is out
of the scope of this document. of the scope of this document.
skipping to change at page 6, line 31 skipping to change at page 6, line 31
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 a PCC to a PCE, and to return computed paths from the PCE to requests a PCC to a PCE, and to return computed paths from the PCE to
the PCC. The PCECP can also be used between cooperating PCEs. 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 efficiently utilize network resources. A GCO path order to optimize network resources. A GCO path computation is able
computation is able to simultaneously consider the entire topology of to simultaneously consider the entire topology of the network and the
the network and the complete set of existing LSPs, and their complete set of existing TE LSPs, and their respective constraints,
respective constraints, and look to optimize or re-optimize the and look to optimize or re-optimize the entire network to satisfy all
entire network to satisfy all constraints for all LSPs. A GCO path constraints for all TE LSPs. A GCO path computation can also provide
computation can also provide an optimal way to migrate from an an optimal way to migrate from an existing set of TE LSPs to a
existing set of 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 also used in the parts of this document that specify
requirements for clarity of specification of those requirements. 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.
skipping to change at page 8, line 14 skipping to change at page 8, line 14
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 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 network planner wants to make use
of a computation server to plan the LSPs that will be provisioned in of a computation server to plan the TE LSPs that will be provisioned
the network. in the network. Note that once greenfield operation is one-time
optimization. When network conditions change due to failure or other
changes, then re-optimization 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
skipping to change at page 9, line 8 skipping to change at page 9, line 10
The need for global concurrent path computation may arise in existing The need for global concurrent path computation may arise in existing
networks. When an existing TE LSP network experiences sub-optimal networks. When an existing TE LSP network experiences sub-optimal
use of its resources, the need for re-optimization or reconfiguration use of its resources, the need for re-optimization or reconfiguration
may arise. The scope of re-optimization and reconfiguration may vary may arise. The scope of re-optimization and reconfiguration may vary
depending on particular situations. The scope of re-optimization may depending on particular situations. The scope of re-optimization may
be limited to bandwidth modification to an existing TE LSP. However, be limited to bandwidth modification to an existing TE LSP. However,
it could well be that a set of TE LSPs may need to be re-optimized it could well be that a set of TE LSPs may need to be re-optimized
concurrently. In an extreme case, the TE LSPs may need to be concurrently. In an extreme case, the TE LSPs may need to be
globally re-optimized. globally re-optimized.
In loaded networks, with large size LSPs, a sequential re- In loaded networks, with large size TE LSPs, a sequential re-
optimization may not produce substantial improvements in terms of optimization may not produce substantial improvements in terms of
overall network optimization. Sequential re-optimization refers to a overall network optimization. Sequential re-optimization refers to a
path computation method in which to compute the re-optimized path of path computation method in which to compute the re-optimized path of
one LSP at a time without giving any consideration to the other LSPs one TE LSP at a time without giving any consideration to the other TE
that need to be re-optimized in the network. The potential for LSPs that need to be re-optimized in the network. The potential for
network-wide gains from reoptimization of LSPs sequentially is network-wide gains from reoptimization of TE LSPs sequentially is
dependent upon the network usage and size of the 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 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 LSPs in the network could result in sub-optimal use of network other TE LSPs in the network could result in sub-optimal use of
resources. This may be far more visible in an optical network with a network resources. This may be far more visible in an optical
low ratio of potential LSPs per link, and far less visible in packet network with a low ratio of potential TE LSPs per link, and far less
networks with micro-flow 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
failures, there may be a real benefit in computing the paths of the failures, there may be a real benefit in computing the paths of the
LSPs as a set rather than computing new paths from the head-end LSRs TE LSPs as a set rather than computing new paths from the head-end
in a distributed manner. GCO could prevent race condition (i.e., LSRs in a distributed manner. Distributed jittering is a technique
competing for the same resource from different head-end LSRs) that that could prevent race condition (i.e., competing for the same
may be associated with a distributed computation. However, a resource from different head-end LSRs) with a distributed
centralized system will typically suffer from a slower response time computation. GCO provides an alternative way that could also prevent
than a distributed system. race condition in a centralized manner. However, a centralized
system will typically suffer from a slower response time than a
distributed system.
3.3.1. Reconfiguration of the Virtual Network Topology (VNT) 3.3.1. Reconfiguration of the Virtual Network Topology (VNT)
Reconfiguration of the VNT [MLN-REQ] [PCE-MLN] is a typical Reconfiguration of the VNT [MLN-REQ] [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 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 LSPs before tearing make-before-break [RFC3209], to establish the new TE LSPs before
down the old LSPs. When multiple LSP routes are changed according to tearing down the old TE LSPs. When multiple TE LSP routes are
the computed results, some of the LSPs may be disrupted due to the changed according to the computed results, some of the TE LSPs may be
resource constraints. In other words, it may prove to be impossible disrupted due to the resource constraints. In other words, it may
to perform a direct migration from the old LSPs to the new optimal prove to be impossible to perform a direct migration from the old TE
LSPs without disrupting traffic because there are insufficient LSPs to the new optimal TE LSPs without disrupting traffic because
network resources to support both sets of LSPs when make-before-break there are insufficient network resources to support both sets of TE
is used. However, a PCE may be able to determine a sequence of make- LSPs when make-before-break is used. However, a PCE may be able to
before- break replacement of individual LSPs or small sets of LSPs so determine a sequence of make-before- break replacement of individual
that the full set of LSPs can be migrated without any disruption. 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
bandwidth of existing TE LSP is kept during the migration which is
required in optical networks. In packet networks, this assumption
can be relaxed as the bandwidth of temporary TE LSPs during migration
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 LSPs to the new 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 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 LSPs must be established and take over order in which reoptimized TE LSPs must be established and take over
from the old LSPs, and may indicate a series of different temporary from the old TE LSPs, and may indicate a series of different
paths that must be used. Alternatively, the PCE might perform the temporary paths that must be used. Alternatively, the PCE might
global reoptimization as a series of sub-reoptimizations by perform the global reoptimization as a series of sub-reoptimizations
reoptimizing subsets of the total set of 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 discruption and optimization gain. However this approach may
imply some transient packets desequencing, jitter as well as control imply some transient packets desequencing, jitter as well as control
plane stress. plane stress.
Note also that during reoptimization, traffic disruption may be Note also that during reoptimization, traffic disruption may be
allowed for some LSPs carrying low priority services (e.g., Internet allowed for some TE LSPs carrying low priority services (e.g.,
traffic) and not allowed for some LSPs carrying mission critical Internet traffic) and not allowed for some TE LSPs carrying mission
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
concurrent path computation applications. The requirements specified concurrent path computation applications. The requirements specified
here should be regarded as application-specific requirements and are here should be regarded as application-specific requirements and are
justifiable based on the extensibility clause found in section 6.1.14 justifiable based on the extensibility clause found in section 6.1.14
of [RFC4657]: of [RFC4657]:
The PCECP MUST support the requirements specified in the The PCECP MUST support the requirements specified in the
skipping to change at page 12, line 27 skipping to change at page 12, line 27
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 LSPs -- This is the largest * Maximum number of hops for all the TE LSPs -- This is the
number of hops that any LSP can have. Note that this largest number of hops that any TE LSP can have. Note that
constraint can also be provided on a per 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 [PCEP]).
* Exclusion of links/nodes in all LSP path computation (i.e., all * Exclusion of links/nodes in all TE LSP path computation (i.e.,
LSPs should not include the specified links/nodes in their all TE LSPs should not include the specified links/nodes in
paths). Note that this constraint can also be provided on a their paths). Note that this constraint can also be provided
per LSP basis (as requested in [RFC4657] and defined in on a per TE LSP basis (as requested in [RFC4657] and defined in
[PCEP]). [PCEP]).
* 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 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 [PCEP]. Since the SVEC object as defined in [PCEP]
allows identifying a set of concurrent path requests, the SVEC can allows identifying a set of concurrent path requests, the SVEC can
be reused to specify all the individual concurrent path requests be reused to specify all the individual concurrent path requests
for a global concurrent optimization. for a global concurrent optimization.
skipping to change at page 13, line 29 skipping to change at page 13, line 29
* PCE not capable of concurrent reoptimization * PCE not capable of concurrent reoptimization
* no migration path available * no migration path available
* administrative privileges do not allow global reoptimization * 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 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 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 LSP should be removed and the order in order in which the old TE LSP should be removed and the order
which the new LSP should be setup. If the removal order is in which the new TE LSP should be setup. If the removal order
lower than the setup order this means that make-before-break is lower than the setup order this means that make-before-break
cannot be done for this request. It MAY also be desirable to cannot be done for this request. It MAY also be desirable to
have the PCE indicate whether ordering is in fact required or have the PCE indicate whether ordering is in fact required or
not. not.
* As stated in RFC 4657, the request for a reoptimization MUST
support the inclusion of the set of previously computed paths
along with their bandwidth. This is to avoid double bandwidth
accounting and also this allows running an algorithm that
minimizes perturbation and that can compute a migration path
(LSP setup/removal orders). This is particularly required for
stateless PCEs.
* During a migration it may not be possible to do a make-before- * During a migration it may not be possible to do a make-before-
break for all existing LSPs. The request message MUST allow break for all existing 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 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
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 [PCEP].
The format of a PCReq message after incorporating new requirements The format of a PCReq message after incorporating new requirements
for support of global concurrent optimization is as follows: for support of global concurrent optimization is as follows:
skipping to change at page 15, line 36 skipping to change at page 15, line 36
Note that three optional objects are added, following the SVEC Note that three optional objects are added, following the SVEC
object: the OF (Objective Function) object, which is defined in object: the OF (Objective Function) object, which is defined in
[PCE-OF], the GC (Global Constraints) object, which is defined in [PCE-OF], the GC (Global Constraints) object, which is defined in
this document (section 5.5), as well as the eXclude Route Object this document (section 5.5), as well as the eXclude Route Object
(XRO) which is defined in [PCE-XRO]. The placement of the OF object (XRO) which is defined in [PCE-XRO]. The placement of the OF object
(in which the global objective function is specified) in the SVEC- (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 [PCE-OF]. Details of this change will be
discussed in the following sections. discussed in the following sections.
Note also that when the XRO is global to a SVEC, and F bit is set, it Note also that when the XRO is global to a SVEC, and F bit is set, it
SHOULD be allowed to specify multiple Reported Route Objects (RROs) SHOULD be allowed to specify multiple Record Route Objects in the
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 [PCE-OF]. The OF object includes a
16 bit Objective Function identifier. As per discussed in [PCE-OF], 16 bit Objective Function identifier. As per discussed in [PCE-OF],
objective function identifier code points are managed by IANA. objective function identifier code points are managed by IANA.
Three global objective functions defined in [PCE-OF] are used in the Three global objective functions defined in [PCE-OF] are used in the
context of GCO. context of GCO.
skipping to change at page 16, line 30 skipping to change at page 16, line 30
All the path requests in this application should be indicated so that All the path requests in this application should be indicated so that
the global objective function and all of the global constraints are the global objective function and all of the global constraints are
applied to each of the requested path computation. This can be applied to each of the requested path computation. This can be
indicated implicitly by placing the GCO related objects (GOF, GC or indicated implicitly by placing the GCO related objects (GOF, GC or
XRO) after the SVEC object. That is, if any of these objects follows XRO) after the SVEC object. That is, if any of these objects follows
the SVEC object in the PCReq message, all of the requested path the SVEC object in the PCReq message, all of the requested path
computations specified in the SVEC object are subject to GOF, GC or computations specified in the SVEC object are subject to GOF, GC or
XRO. XRO.
5.3. Request for The Order of LSP 5.3. Request for The Order of 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 LSPs be ordered. That is, the PCE has to include the order in which TE
MUST be moved so as to minimize traffic disruption. To support such LSPs MUST be moved so as to minimize traffic disruption. To support
indication a new flag, the D flag, is defined in the RP object as such indication a new flag, the D flag, is defined in the RP object
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.
skipping to change at page 17, line 16 skipping to change at page 17, line 16
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 ordering indication a new optional TLV, the Order TLV,
is defined in the RP object. 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 LSP must be removed and the new LSP must be order in which the old TE LSP must be removed and the new TE LSP must
setup during a reoptimization. It is carried in the PCRep message in be setup during a reoptimization. It is carried in the PCRep message
response to a reoptimization request. in response to a reoptimization request.
The Order TLV SHOULD be included in the RP object in the PCRep The Order TLV MUST be included in the RP object in the PCRep message
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: To be defined by IANA (suggested value = 5)
Length: Variable Length: Variable
Delete Order: 32 bit integer that indicates the order in which the Delete Order: 32 bit integer that indicates the order in which the
old LSP should be removed old TE LSP should be removed
Setup Order: 32 bit integer that indicates the order in which the new Setup Order: 32 bit integer that indicates the order in which the new
LSP should be setup 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 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 LSP is a new LSP. is 0, it implies that the resulting TE LSP is a new TE LSP.
To illustrate this, consider a network with two established LSPs: R1 To illustrate this, consider a network with two established TE LSPs:
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 PCE
may provide the following ordered reply: may provide the following ordered reply:
R1, path P1', remove order 1, setup order 4 R1, path P1', remove order 1, setup order 4
R2, path P2', remove order 3, setup order 2 R2, path P2', remove order 3, setup order 2
This indicates that the NMS should do the following sequence of This indicates that the NMS should do the following sequence of
tasks: tasks:
1: Remove path P1 1: Remove path P1
2: Setup path P2' 2: Setup path P2'
skipping to change at page 19, line 18 skipping to change at page 19, line 18
| 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 LSPs. count for all the TE LSPs.
MU (Max Utilization Percentage: 8 bits) : 8 bits integer that MU (Max Utilization Percentage: 8 bits) : 8 bits integer that
indicates the upper bound utilization percentage by which all link indicates the upper bound utilization percentage by which all link
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 (minimum Utilization Percentage: 8 bits) : 8 bits integer that mU (minimum Utilization Percentage: 8 bits) : 8 bits integer that
indicates the lower bound utilization percentage by which all link indicates the lower bound utilization percentage by which all link
should be bound. should be bound.
skipping to change at page 22, line 9 skipping to change at page 22, line 9
6.4. Verifying Correct Operation 6.4. Verifying Correct Operation
Mechanisms defined in this draft do not imply any new verification Mechanisms defined in this draft do not imply any new verification
requirements in addition to those already listed in section 8.4 of requirements in addition to those already listed in section 8.4 of
[PCEP] [PCEP]
6.5. Requirements on Other Protocols and Functional Components 6.5. Requirements on Other Protocols and Functional Components
The PCE Discovery mechanisms ([RFC 5088] and [RFC 5089]) may be used The PCE Discovery mechanisms ([RFC 5088] and [RFC 5089]) may be used
to advertise global concurrent path computation capabilities to PCCs. to advertise global concurrent path computation capabilities to PCCs.
A New Flag (value=9) in PCE-CAP-FLAGs Sub-TLV should be assigned to
be able to indicate GCO capability.
6.6. Impact on Network Operation 6.6. Impact on Network Operation
Mechanisms defined in this draft do not imply any new network Mechanisms defined in this draft do not imply any new network
operation requirements in addition to those already listed in section operation requirements in addition to those already listed in section
8.6 of [PCEP]. 8.6 of [PCEP].
7. Security Considerations 7. Security Considerations
When global re-optimization is applied to an active network, it could When global re-optimization is applied to an active network, it could
skipping to change at page 25, line 26 skipping to change at page 25, line 26
sub-registry. sub-registry.
Bit Name Description Reference Bit Name Description Reference
11 D-bit Report the request order [This.I-D] 11 D-bit Report the request order [This.I-D]
12 M-bit Make-before-break [This.I-D] 12 M-bit Make-before-break [This.I-D]
9.2. New PCEP TLV 9.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 LSPs in a GCO. IANA is requested to the setup and delete order of TE LSPs in a GCO. IANA is requested to
make the following allocation from the "PCEP TLV Types" sub-registry. make the following allocation from the "PCEP TLV Types" sub-registry.
TLV Type Meaning Reference TLV Type Meaning Reference
5 Order TLV [This.I-D] 5 Order TLV [This.I-D]
9.3. New PCEP Object 9.3. New Flag in PCE-CAP-FLAGS Sub-TLV in PCED
As described in Section 6.5, a new PCE-CAP-FLAGS Sub-TLV in PCED is
defined to indicate a GCO capability. IANA is requested to make the
following allocation from the "PCE-CAP-FLAGS TLV Types" sub-registry.
FLAG Meaning Reference
9 Global Concurrent Optimization (GCO)[This.I-D]
9.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 is requested to make the following
allocation from the "PCEP Objects" sub-registry. allocation from the "PCEP Objects" sub-registry.
Object Name Reference Object Name Reference
Class Class
24 GLOBAL-CONSTRAINTS [This.I-D] 24 GLOBAL-CONSTRAINTS [This.I-D]
Object-Type Object-Type
1: Global Constraints [This.I-D] 1: Global Constraints [This.I-D]
9.4. New PCEP Error Codes 9.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 is requested to make allocations from the "PCEP 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.4.1. New Error-Values for Existing Error-Types 9.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: [This.I-D]
Global concurrent optimization not allowed Global concurrent optimization not allowed
9.4.2. New Error-Types and Error-Values 9.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 [This.I-D]
Error-value=1: Error-value=1:
Insufficient memory [This.I-D] Insufficient memory [This.I-D]
Error-value=2: Error-value=2:
Global concurrent optimization not supported Global concurrent optimization not supported
[This.I-D] [This.I-D]
9.5. New No-Path Reasons 9.6. New No-Path Reasons
IANA is requested to make the following allocations from the "No-Path IANA is requested to make the following allocations from the "No-Path
Reasons" sub-registry for bit flags carried in the NO-PATH-VECTOR TLV Reasons" sub-registry for bit flags carried in the NO-PATH-VECTOR TLV
in the PCEP NO-PATH object as described in Section 5.7. in the PCEP NO-PATH object as described in Section 5.7.
Bit Bit
Number Name Reference Number Name Reference
6 No GCO migration path found [This.I-D] 6 No GCO migration path found [This.I-D]
7 No GCO solution found [This.I-D] 7 No GCO solution found [This.I-D]
 End of changes. 54 change blocks. 
152 lines changed or deleted 165 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/