<pre>Network Working Group                                             Y. Lee
Request for Comments: 5557                                        Huawei
Category: Standards Track                                    JL. Le Roux
                                                          France Telecom
                                                                 D. King
                                                      Old Dog Consulting
                                                                  E. Oki
                                    University of Electro Communications
                                                               July 2009


  <span class="h1">Path Computation Element Communication Protocol (PCEP) Requirements</span>
  <span class="h1">and Protocol Extensions in Support of Global Concurrent Optimization</span>

Abstract

   The Path Computation Element Communication Protocol (PCEP) allows
   Path Computation Clients (PCCs) to request path computations from
   Path Computation Elements (PCEs), and lets the PCEs return responses.
   When computing or reoptimizing the routes of a set of Traffic
   Engineering Label Switched Paths (TE LSPs) through a network, it may
   be advantageous to perform bulk path computations in order to avoid
   blocking problems and to achieve more optimal network-wide solutions.
   Such bulk optimization is termed Global Concurrent Optimization
   (GCO).  A GCO is able to simultaneously consider the entire topology
   of the network and the complete set of existing TE LSPs, and their
   respective constraints, and look to optimize or reoptimize the entire
   network to satisfy all constraints for all TE LSPs.  A GCO may also
   be applied to some subset of the TE LSPs in a network.  The GCO
   application is primarily a Network Management System (NMS) solution.

   This document provides application-specific requirements and the PCEP
   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.










<span class="grey">Lee, et al.                 Standards Track                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>).
   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.





























<span class="grey">Lee, et al.                 Standards Track                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-4">4</a>
   <a href="#section-2">2</a>. Terminology .....................................................<a href="#page-6">6</a>
   <a href="#section-3">3</a>. Applicability of Global Concurrent Optimization (GCO) ...........<a href="#page-6">6</a>
      <a href="#section-3.1">3.1</a>. Application of the PCE Architecture ........................<a href="#page-7">7</a>
      <a href="#section-3.2">3.2</a>. Greenfield Optimization ....................................<a href="#page-8">8</a>
           <a href="#section-3.2.1">3.2.1</a>. Single-Layer Traffic Engineering ....................<a href="#page-8">8</a>
           <a href="#section-3.2.2">3.2.2</a>. Multi-Layer Traffic Engineering .....................<a href="#page-8">8</a>
      <a href="#section-3.3">3.3</a>. Reoptimization of Existing Networks ........................<a href="#page-8">8</a>
           3.3.1. Reconfiguration of the Virtual Network
                  Topology (VNT) ......................................<a href="#page-9">9</a>
           <a href="#section-3.3.2">3.3.2</a>. Traffic Migration ...................................<a href="#page-9">9</a>
   <a href="#section-4">4</a>. PCECP Requirements .............................................<a href="#page-10">10</a>
   5. Protocol Extensions for Support of Global Concurrent
      Optimization ...................................................<a href="#page-13">13</a>
      <a href="#section-5.1">5.1</a>. Global Objective Function (GOF) Specification .............<a href="#page-14">14</a>
      <a href="#section-5.2">5.2</a>. Indication of Global Concurrent Optimization Requests .....<a href="#page-15">15</a>
      <a href="#section-5.3">5.3</a>. Request for the Order of TE LSP ...........................<a href="#page-15">15</a>
      <a href="#section-5.4">5.4</a>. The Order Response ........................................<a href="#page-16">16</a>
      <a href="#section-5.5">5.5</a>. GLOBAL CONSTRAINTS (GC) Object ............................<a href="#page-17">17</a>
      <a href="#section-5.6">5.6</a>. Error Indicator ...........................................<a href="#page-18">18</a>
      <a href="#section-5.7">5.7</a>. NO-PATH Indicator .........................................<a href="#page-19">19</a>
   <a href="#section-6">6</a>. Manageability Considerations ...................................<a href="#page-19">19</a>
      <a href="#section-6.1">6.1</a>. Control of Function and Policy ............................<a href="#page-19">19</a>
      <a href="#section-6.2">6.2</a>. Information and Data Models (e.g., MIB Module) ............<a href="#page-20">20</a>
      <a href="#section-6.3">6.3</a>. Liveness Detection and Monitoring .........................<a href="#page-20">20</a>
      <a href="#section-6.4">6.4</a>. Verifying Correct Operation ...............................<a href="#page-20">20</a>
      6.5. Requirements on Other Protocols and Functional
           Components ................................................<a href="#page-20">20</a>
      <a href="#section-6.6">6.6</a>. Impact on Network Operation ...............................<a href="#page-20">20</a>
   <a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-21">21</a>
   <a href="#section-8">8</a>. IANA Considerations ............................................<a href="#page-21">21</a>
      <a href="#section-8.1">8.1</a>. Request Parameter Bit Flags ...............................<a href="#page-21">21</a>
      <a href="#section-8.2">8.2</a>. New PCEP TLV ..............................................<a href="#page-21">21</a>
      <a href="#section-8.3">8.3</a>. New Flag in PCE-CAP-FLAGS Sub-TLV in PCED .................<a href="#page-22">22</a>
      <a href="#section-8.4">8.4</a>. New PCEP Object ...........................................<a href="#page-22">22</a>
      <a href="#section-8.5">8.5</a>. New PCEP Error Codes ......................................<a href="#page-22">22</a>
           <a href="#section-8.5.1">8.5.1</a>. New Error-Values for Existing Error-Types ..........<a href="#page-22">22</a>
           <a href="#section-8.5.2">8.5.2</a>. New Error-Types and Error-Values ...................<a href="#page-23">23</a>
      <a href="#section-8.6">8.6</a>. New No-Path Reasons .......................................<a href="#page-23">23</a>
   <a href="#section-9">9</a>. References .....................................................<a href="#page-23">23</a>
      <a href="#section-9.1">9.1</a>. Normative References ......................................<a href="#page-23">23</a>
      <a href="#section-9.2">9.2</a>. Informative References ....................................<a href="#page-24">24</a>
   <a href="#section-10">10</a>. Acknowledgments ...............................................<a href="#page-24">24</a>
   <a href="#appendix-A">Appendix A</a>. RBNF Code Fragments ...................................<a href="#page-25">25</a>





<span class="grey">Lee, et al.                 Standards Track                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   [<a id="ref-RFC4655">RFC4655</a>] defines the Path Computation Element (PCE)-based
   architecture and explains how a PCE may compute Label Switched Paths
   (LSPs) in Multiprotocol Label Switching Traffic Engineering (MPLS-TE)
   and Generalized MPLS (GMPLS) networks at the request of Path
   Computation Clients (PCCs).  A PCC is shown to be any network
   component that makes such a request and may be, for instance, a Label
   Switching Router (LSR) or a Network Management System (NMS).  The
   PCE, itself, is shown to be located anywhere within the network, and
   it may be within an LSR, an NMS or Operational Support System (OSS),
   or may be an independent network server.

   The PCE Communication Protocol (PCEP) is the communication protocol
   used between PCC and PCE, and it may also be used between cooperating
   PCEs.  [<a href="./rfc4657" title="&quot;Path Computation Element (PCE) Communication Protocol Generic Requirements&quot;">RFC4657</a>] sets out generic protocol requirements for PCEP.
   Additional application-specific requirements for PCEP are defined in
   separate documents.

   This document provides a set of requirements and PCEP extensions in
   support of concurrent path computation applications.  A concurrent
   path computation is a path computation application where a set of TE
   paths are computed concurrently in order to efficiently utilize
   network resources.  The computation method involved with a concurrent
   path computation is referred to as "global concurrent optimization"
   in this document.  Appropriate computation algorithms to perform this
   type of optimization are out of the scope of this document.

   The Global Concurrent Optimization (GCO) application is primarily an
   NMS or a PCE-Server-based solution.  Owing to complex synchronization
   issues associated with GCO applications, the management-based PCE
   architecture defined in <a href="./rfc4655#section-5.5">Section&nbsp;5.5 of [RFC4655]</a> is considered as the
   most suitable usage to support GCO application.  This does not
   preclude other architectural alternatives to support GCO application,
   but they are NOT RECOMMENDED.  For instance, GCO might be enabled by
   distributed LSRs through complex synchronization mechanisms.
   However, this approach might suffer from significant synchronization
   overhead between the PCE and each of the PCCs.  It would likely
   affect the network stability and hence significantly diminish the
   benefits of deploying PCEs.

   The need for global concurrent path computation may also arise when
   network operators need to establish a set of TE LSPs in their network
   planning process.  It is also envisioned that network operators might
   require global concurrent path computation in the event of
   catastrophic network failures, where a set of TE LSPs need to be





<span class="grey">Lee, et al.                 Standards Track                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


   optimally rerouted.  The nature of this work promotes the use of such
   systems for off-line processing.  Online application of this work
   should only be considered with proven empirical validation.

   As new TE LSPs are added or removed from the network over time, the
   global network resources become fragmented and the existing placement
   of TE LSPs within the network no longer provides optimal use of the
   available capacity.  A global concurrent path computation is able to
   simultaneously consider the entire topology of the network and the
   complete set of existing TE LSPs and their respective constraints,
   and is able to look to reoptimize the entire network to satisfy all
   constraints for all TE LSPs.  Alternatively, the application may
   consider a subset of the TE LSPs and/or a subset of the network
   topology.  Note that other preemption can also help reduce the
   fragmentation issues.

   While GCO is applicable to any simultaneous request for multiple TE
   LSPs (for example, a request for end-to-end protection), it is NOT
   RECOMMENDED that global concurrent reoptimization would be applied in
   a network (such as an MPLS-TE network) that contains a very large
   number of very low bandwidth or zero bandwidth TE LSPs since the
   large scope of the problem and the small benefit of concurrent
   reoptimization relative to single TE LSP reoptimization is unlikely
   to make the process worthwhile.  Further, applying global concurrent
   reoptimization in a network with a high rate of change of TE LSPs
   (churn) is NOT RECOMMENDED because of the likelihood that TE LSPs
   would change before they could be globally reoptimized.  Global
   reoptimization is more applicable to stable networks such as
   transport networks or those with long-term TE LSP tunnels.

   The main focus of this document is to highlight the PCC-PCE
   communication needs in support of a concurrent path computation
   application and to define protocol extensions to meet those needs.

   The PCC-PCE requirements addressed herein are specific to the context
   where the PCE is a specialized PCE that is capable of performing
   computations in support of GCO.  Discovery of such capabilities might
   be desirable and could be achieved through extensions to the PCE
   discovery mechanisms [<a href="./rfc4674" title="&quot;Requirements for Path Computation Element (PCE) Discovery&quot;">RFC4674</a>], [<a href="./rfc5088" title="&quot;OSPF Protocol Extensions for Path Computation Element (PCE) Discovery&quot;">RFC5088</a>], [<a href="./rfc5089" title="&quot;IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery&quot;">RFC5089</a>]; but, that is
   out of the scope of this document.

   It is to be noted that Backward Recursive Path Computation (BRPC)
   [<a href="./rfc5441" title="&quot;A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths&quot;">RFC5441</a>] is a multi-PCE path computation technique used to compute a
   shortest constrained inter-domain path, whereas this ID specifies a
   technique where a set of path computation requests are bundled and
   sent to a PCE with the objective of "optimizing" the set of computed
   paths.




<span class="grey">Lee, et al.                 Standards Track                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Terminology</span>

   Most of the terminology used in this document is explained in
   [<a href="./rfc4655" title="&quot;A Path Computation Element (PCE)-Based Architecture&quot;">RFC4655</a>].  A few key terms are repeated here for clarity.

   PCC: Path Computation Client.  Any client application requesting a
   path computation to be performed by a Path Computation Element.

   PCE: Path Computation Element.  An entity (component, application, or
   network node) that is capable of computing a network path or route
   based on a network graph and applying computational constraints.

   TED: Traffic Engineering Database.  The TED contains the topology and
   resource information of the domain.  The TED may be fed by IGP
   extensions or potentially by other means.

   PCECP: The PCE Communication Protocol.  PCECP is the generic abstract
   idea of a protocol that is used to communicate path computation
   requests from a PCC to a PCE and to return computed paths from the
   PCE to the PCC.  The PCECP can also be used between cooperating PCEs.

   PCEP: The PCE communication Protocol.  PCEP is the actual protocol
   that implements the PCECP idea.

   GCO: Global Concurrent Optimization.  A concurrent path computation
   application where a set of TE paths are computed concurrently in
   order to optimize network resources.  A GCO path computation is able
   to simultaneously consider the entire topology of the network and the
   complete set of existing TE LSPs, and their respective constraints,
   and look to optimize or reoptimize the entire network to satisfy all
   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
   reoptimized set (Morphing Problem).

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].
   These terms are used to specify requirements in this document.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Applicability of Global Concurrent Optimization (GCO)</span>

   This section discusses the PCE architecture to which GCO is applied.
   It also discusses various application scenarios for which global
   concurrent path computation may be applied.







<span class="grey">Lee, et al.                 Standards Track                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Application of the PCE Architecture</span>

   Figure 1 shows the PCE-based network architecture as defined in
   [<a href="./rfc4655" title="&quot;A Path Computation Element (PCE)-Based Architecture&quot;">RFC4655</a>] to which GCO application is applied.  It must be observed
   that the PCC is not necessarily an LSR [<a href="./rfc4655" title="&quot;A Path Computation Element (PCE)-Based Architecture&quot;">RFC4655</a>].  The GCO
   application is primarily an NMS-based solution in which an NMS plays
   the function of the PCC.  Although Figure 1 shows the PCE as remote
   from the NMS, it might be collocated with the NMS.  Note that in the
   collocated case, there is no need for a standard communication
   protocol; this can rely on internal APIs.

                                         -----------
                  Application           |   -----   |
                    Request             |  | TED |  |
                       |                |   -----   |
                       v                |     |     |
                 ------------- Request/ |     v     |
                |     PCC     | Response|   -----   |
                | (NMS/Server)|&lt;--------+&gt; | PCE |  |
                |             |         |   -----   |
                 -------------           -----------
               Service |
               Request |
                       v
                  ----------  Signaling   ----------
                 | Head-End | Protocol   | Adjacent |
                 |  Node    |&lt;----------&gt;|   Node   |
                  ----------              ----------

                         Figure 1: PCE-Based Architecture for
                            Global Concurrent Optimization

   Upon receipt of an application request (e.g., a traffic demand matrix
   is provided to the NMS by the operator's network planning procedure),
   the NMS requests a global concurrent path computation from the PCE.
   The PCE then computes the requested paths concurrently applying some
   algorithms.  Various algorithms and computation techniques have been
   proposed to perform this function.  Specification of such algorithms
   or techniques is outside the scope of this document.

   When the requested path computation completes, the PCE sends the
   resulting paths back to the NMS.  The NMS then supplies the head-end
   LSRs with a fully computed explicit path for each TE LSP that needs
   to be established.







<span class="grey">Lee, et al.                 Standards Track                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Greenfield Optimization</span>

   Greenfield optimization is a special case of GCO application when
   there are no TE LSPs already set up in the network.  The need for
   greenfield optimization arises when the network planner wants to make
   use of a computation server to plan the TE LSPs that will be
   provisioned in the network.  Note that greenfield operation is a
   one-time optimization.  When network conditions change due to failure
   or other changes, then the reoptimization mode of operation will kick
   in.

   When a new TE network needs to be provisioned from a greenfield
   perspective, a set of TE LSPs needs to be created based on traffic
   demand, network topology, service constraints, and network resources.
   In this scenario, the ability to perform concurrent computation is
   desirable, or required, to utilize network resources in an optimal
   manner and avoid blocking.

<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>.  Single-Layer Traffic Engineering</span>

   Greenfield optimization can be applied when layer-specific TE LSPs
   need to be created from a greenfield perspective.  For example, an
   MPLS-TE network can be planned based on Layer 3 specific traffic
   demands, the network topology, and available network resources.
   Greenfield optimization for single-layer traffic engineering can be
   applied to optical transport networks such as Synchronous Digital
   Hierarchy/Synchronous Optical Network (SDH/SONET), Ethernet
   Transport, Wavelength Division Multiplexing (WDM), etc.

<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>.  Multi-Layer Traffic Engineering</span>

   Greenfield optimization is not limited to single-layer traffic
   engineering.  It can also be applied to multi-layer traffic
   engineering [<a href="#ref-PCE-MLN" title="&quot;Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering&quot;">PCE-MLN</a>].  The network resources and topology (of both
   the client and server layers) can be considered simultaneously in
   setting up a set of TE LSPs that traverse the layer boundary.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Reoptimization of Existing Networks</span>

   The need for global concurrent path computation may arise in existing
   networks.  When an existing TE LSP network experiences sub-optimal
   use of its resources, the need for reoptimization or reconfiguration
   may arise.  The scope of reoptimization and reconfiguration may vary
   depending on particular situations.  The scope of reoptimization may
   be limited to bandwidth modification to an existing TE LSP.  However,
   it could well be that a set of TE LSPs may need to be reoptimized
   concurrently.  In an extreme case, the TE LSPs may need to be
   globally reoptimized.



<span class="grey">Lee, et al.                 Standards Track                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


   In loaded networks, with large size TE LSPs, a sequential
   reoptimization may not produce substantial improvements in terms of
   overall network optimization.  Sequential reoptimization refers to a
   path computation method that computes the reoptimized path of one TE
   LSP at a time without giving any consideration to the other TE LSPs
   that need to be reoptimized in the network.  The potential for
   network-wide gains from reoptimization of TE LSPs sequentially is
   dependent upon the network usage and size of the TE LSPs being
   optimized.  However, the key point remains: computing the reoptimized
   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
   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
   visible in packet networks with micro-flow TE LSPs.

   With regards to applicability of GCO in the event of catastrophic
   failures, there may be a real benefit in computing the paths of the
   TE LSPs as a set rather than computing new paths from the head-end
   LSRs in a distributed manner.  Distributed jittering is a technique
   that could prevent race condition (i.e., competing for the same
   resource from different head-end LSRs) with a distributed
   computation.  GCO provides an alternative way that could also prevent
   race condition in a centralized manner.  However, a centralized
   system will typically suffer from a slower response time than a
   distributed system.

<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>.  Reconfiguration of the Virtual Network Topology (VNT)</span>

   Reconfiguration of the VNT [<a href="./rfc5212" title="&quot;Requirements for GMPLS-Based Multi- Region and Multi-Layer Networks (MRN/MLN)&quot;">RFC5212</a>] [<a href="#ref-PCE-MLN" title="&quot;Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering&quot;">PCE-MLN</a>] is a typical
   application scenario where global concurrent path computation may be
   applicable.  Triggers for VNT reconfiguration, such as traffic demand
   changes, network failures, and topological configuration changes may
   require a set of existing TE LSPs to be re-computed.

<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>.  Traffic Migration</span>

   When migrating from one set of TE LSPs to a reoptimized set of TE
   LSPs, it is important that the traffic be moved without causing
   disruption.  Various techniques exist in MPLS and GMPLS, such as
   make-before-break [<a href="./rfc3209" title="&quot;RSVP-TE: Extensions to RSVP for LSP Tunnels&quot;">RFC3209</a>], to establish the new TE LSPs before
   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
   disrupted due to the resource constraints.  In other words, it may
   prove to be impossible to perform a direct migration from the old TE
   LSPs to the new optimal TE LSPs without disrupting traffic because
   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
   determine a sequence of make-before-break replacement of individual



<span class="grey">Lee, et al.                 Standards Track                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


   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
   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
   migration strategy is required that may necessitate TE LSPs being
   rerouted using make-before-break onto temporary paths in order to
   make space for the full reoptimization.  A PCE might indicate the
   order in which reoptimized TE LSPs must be established and take over
   from the old TE LSPs, and it may indicate a series of different
   temporary paths that must be used.  Alternatively, the PCE might
   perform the global reoptimization as a series of sub-reoptimizations
   by reoptimizing subsets of the total set of TE LSPs.

   The benefit of this multi-step rerouting includes minimization of
   traffic disruption and optimization gain.  However, this approach may
   imply some transient packets desequencing, jitter, as well as control
   plane stress.

   Note also that during reoptimization, traffic disruption may be
   allowed for some TE LSPs carrying low priority services (e.g.,
   Internet traffic) and not allowed for some TE LSPs carrying mission
   critical services (e.g., voice traffic).

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  PCECP Requirements</span>

   This section provides the PCECP requirements to support global
   concurrent path computation applications.  The requirements specified
   here should be regarded as application-specific requirements and are
   justifiable based on the extensibility clause found in <a href="./rfc4657#section-6.1.14">Section&nbsp;6.1.14
   of [RFC4657]</a>:

      The PCECP MUST support the requirements specified in the
      application-specific requirements documents.  The PCECP MUST also
      allow extensions as more PCE applications will be introduced in
      the future.

   It is also to be noted that some of the requirements discussed in
   this section have already been discussed in the PCECP requirement
   document [<a href="./rfc4657" title="&quot;Path Computation Element (PCE) Communication Protocol Generic Requirements&quot;">RFC4657</a>].  For example, <a href="./rfc4657#section-5.1.16">Section&nbsp;5.1.16 in [RFC4657]</a>
   provides a list of generic constraints while <a href="./rfc4657#section-5.1.17">Section&nbsp;5.1.17 in
   [RFC4657]</a> provides a list of generic objective functions that MUST be
   supported by the PCECP.  While using such generic requirements as the



<span class="grey">Lee, et al.                 Standards Track                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


   baseline, this section provides application-specific requirements in
   the context of global concurrent path computation and in a more
   detailed level than the generic requirements.

   The PCEP SHOULD support the following capabilities either via
   creation of new objects and/or modification of existing objects where
   applicable.

   o  An indicator to convey that the request is for a global concurrent
      path computation.  This indicator is necessary to ensure
      consistency in applying global objectives and global constraints
      in all path computations.  Note: This requirement is covered by
      "synchronized path computation" in [<a href="./rfc4655" title="&quot;A Path Computation Element (PCE)-Based Architecture&quot;">RFC4655</a>] and [<a href="./rfc4657" title="&quot;Path Computation Element (PCE) Communication Protocol Generic Requirements&quot;">RFC4657</a>].
      However, an explicit indicator to request a global concurrent
      optimization is a new requirement.


   o  A Global Objective Function (GOF) field in which to specify the
      global objective function.  The global objective function is the
      overarching objective function to which all individual path
      computation requests are subjected in order to find a globally
      optimal solution.  Note that this requirement is covered by
      "synchronized objective functions" in <a href="./rfc4657#section-5.1.7">Section&nbsp;5.1.7 [RFC4657]</a> and
      that [<a href="./rfc5541" title="&quot;Encoding of Objective Functions in Path Computation Element Communication Protocol (PCEP)&quot;">RFC5541</a>] defined three global objective functions as
      follows.  A list of available global objective functions SHOULD
      include the following objective functions at the minimum and
      SHOULD be expandable for future addition:

      *  Minimize aggregate Bandwidth Consumption (MBC)

      *  Minimize the load of the Most Loaded Link (MLL)

      *  Minimize Cumulative Cost of a set of paths (MCC)

   o  A Global Constraints (GC) field in which to specify the list of
      global constraints to which all the requested path computations
      should be subjected.  This list SHOULD include the following
      constraints at the minimum and SHOULD be expandable for future
      addition:

      *  Maximum link utilization value -- This value indicates the
         highest possible link utilization percentage set for each link.
         (Note: to avoid floating point numbers, the values should be
         integer values.)

      *  Minimum link utilization value -- This value indicates the
         lowest possible link utilization percentage set for each link.
         (Note: same as above.)



<span class="grey">Lee, et al.                 Standards Track                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


      *  Overbooking factor -- The overbooking factor allows the
         reserved bandwidth to be overbooked on each link beyond its
         physical capacity limit.

      *  Maximum number of hops for all the TE LSPs -- This is the
         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
         requested in [<a href="./rfc4657" title="&quot;Path Computation Element (PCE) Communication Protocol Generic Requirements&quot;">RFC4657</a>] and defined in [<a href="./rfc5440" title="&quot;Path Computation Element (PCE) Communication Protocol (PCEP)&quot;">RFC5440</a>]).

      *  Exclusion of links/nodes in all TE LSP path computation (i.e.,
         all TE LSPs should not include the specified links/nodes in
         their paths).  Note that this constraint can also be provided
         on a per-TE-LSP basis (as requested in [<a href="./rfc4657" title="&quot;Path Computation Element (PCE) Communication Protocol Generic Requirements&quot;">RFC4657</a>] and defined in
         [<a href="./rfc5440" title="&quot;Path Computation Element (PCE) Communication Protocol (PCEP)&quot;">RFC5440</a>]).

      *  An indication should be available in a path computation
         response that further reoptimization may only become available
         once existing traffic has been moved to the new TE LSPs.

   o  A Global Concurrent Vector (GCV) field in which to specify all the
      individual path computation requests that are subject to
      concurrent path computation and subject to the global objective
      function and all of the global constraints.  Note that this
      requirement is entirely fulfilled by the SVEC object in the PCEP
      specification [<a href="./rfc5440" title="&quot;Path Computation Element (PCE) Communication Protocol (PCEP)&quot;">RFC5440</a>].  Since the SVEC object as defined in
      [<a href="./rfc5440" title="&quot;Path Computation Element (PCE) Communication Protocol (PCEP)&quot;">RFC5440</a>] allows identifying a set of concurrent path requests,
      the SVEC can be reused to specify all the individual concurrent
      path requests for a global concurrent optimization.

   o  An indicator field in which to indicate the outcome of the
      request.  When the PCE cannot find a feasible solution with the
      initial request, the reason for failure SHOULD be indicated.  This
      requirement is partially covered by [<a href="./rfc4657" title="&quot;Path Computation Element (PCE) Communication Protocol Generic Requirements&quot;">RFC4657</a>], but not in this
      level of detail.  The following indicators SHOULD be supported at
      the minimum:

      *  no feasible solution found.  Note that this is already covered
         in [<a href="./rfc5440" title="&quot;Path Computation Element (PCE) Communication Protocol (PCEP)&quot;">RFC5440</a>].

      *  memory overflow.

      *  PCE too busy.  Note that this is already covered in [<a href="./rfc5440" title="&quot;Path Computation Element (PCE) Communication Protocol (PCEP)&quot;">RFC5440</a>].

      *  PCE not capable of concurrent reoptimization.

      *  no migration path available.

      *  administrative privileges do not allow global reoptimization.



<span class="grey">Lee, et al.                 Standards Track                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


   o  In order to minimize disruption associated with bulk path
      provisioning, the following requirements MUST be supported:

      *  The request message MUST allow requesting the PCE to provide
         the order in which TE LSPs should be reoptimized (i.e., the
         migration path) in order to minimize traffic disruption during
         the migration.  That is, the request message MUST allow
         indicating to the PCE that the set of paths that will be
         provided in the response message (PCRep) has to be ordered.

      *  In response to the "ordering" request from the PCC, the PCE
         MUST be able to indicate in the response message (PCRep) the
         order in which TE LSPs should be reoptimized so as to minimize
         traffic disruption.  It should indicate for each request the
         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
         is lower than the setup order, this means that make-before-
         break cannot be done for this request.  It MAY also be
         desirable to have the PCE indicate whether ordering is in fact
         required or not.

      *  During a migration, it may not be possible to do a make-before-
         break for all existing TE LSPs.  The request message MUST allow
         indicating for each request whether make-before-break is
         required (e.g., voice traffic) or break-before-make is
         acceptable (e.g., Internet traffic).  The response message must
         allow indicating TE LSPs for which make-before-break
         reoptimization is not possible (this will be deduced from the
         TE LSP setup and deletion orders).

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Protocol Extensions for Support of Global Concurrent Optimization</span>

   This section provides protocol extensions for support of global
   concurrent optimization.  Protocol extensions discussed in this
   section are built on [<a href="./rfc5440" title="&quot;Path Computation Element (PCE) Communication Protocol (PCEP)&quot;">RFC5440</a>].

   The format of a PCReq message after incorporating new requirements
   for support of global concurrent optimization is as follows.  The
   message format uses Reduced Backus-Naur Format as defined in
   [<a href="./rfc5511" title="&quot;Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications&quot;">RFC5511</a>].  Please see <a href="#appendix-A">Appendix A</a> for a full set of RBNF fragments
   defined in this document and the necessary code license.

   &lt;PCReq Message&gt; ::= &lt;Common Header&gt;
                       [&lt;svec-list&gt;]
                       &lt;request-list&gt;






<span class="grey">Lee, et al.                 Standards Track                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


   The &lt;svec-list&gt; is changed as follows:

   &lt;svec-list&gt; ::= &lt;SVEC&gt;
                   [&lt;OF&gt;]
                   [&lt;GC&gt;]
                   [&lt;XRO&gt;]
                   [&lt;svec-list&gt;]

   Note that three optional objects are added, following the SVEC
   object:  the OF (Objective Function) object, which is defined in
   [<a href="./rfc5541" title="&quot;Encoding of Objective Functions in Path Computation Element Communication Protocol (PCEP)&quot;">RFC5541</a>], the GC (Global Constraints) object, which is defined in
   this document (<a href="#section-5.5">Section 5.5</a>), as well as the eXclude Route Object
   (XRO), which is defined in [<a href="./rfc5521" title="&quot;Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions&quot;">RFC5521</a>].  The placement of the OF object
   (in which the global objective function is specified) in the SVEC-
   list is defined in [<a href="./rfc5541" title="&quot;Encoding of Objective Functions in Path Computation Element Communication Protocol (PCEP)&quot;">RFC5541</a>].  Details of this change will be
   discussed in the following sections.

   Note also that when the XRO is global to an SVEC, and F-bit is set,
   it SHOULD be allowed to specify multiple Record Route Objects in the
   PCReq message.

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Global Objective Function (GOF) Specification</span>

   The global objective function can be specified in the PCEP Objective
   Function (OF) object, defined in [<a href="./rfc5541" title="&quot;Encoding of Objective Functions in Path Computation Element Communication Protocol (PCEP)&quot;">RFC5541</a>].  The OF object includes a
   16-bit Objective Function identifier.  As discussed in [<a href="./rfc5541" title="&quot;Encoding of Objective Functions in Path Computation Element Communication Protocol (PCEP)&quot;">RFC5541</a>],
   Objective Function identifier code points are managed by IANA.

   Three global objective functions defined in [<a href="./rfc5541" title="&quot;Encoding of Objective Functions in Path Computation Element Communication Protocol (PCEP)&quot;">RFC5541</a>] are used in the
   context of GCO.

      Function
      Code       Description

       4         Minimize aggregate Bandwidth Consumption (MBC)

       5         Minimize the load of the Most Loaded Link (MLL)*

       6         Minimize the Cumulative Cost of a set of paths (MCC)

   * Note: This can be achieved by the following objective function:
     minimize max over all links {A(i)/C(i)} where C(i) is the link
     capacity for link i, and A(i) is the total bandwidth allocated on
     link i.







<span class="grey">Lee, et al.                 Standards Track                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Indication of Global Concurrent Optimization Requests</span>

   All the path requests in this application should be indicated so that
   the global objective function and all of the global constraints are
   applied to each of the requested path computation.  This can be
   indicated implicitly by placing the GCO related objects (OF, GC, or
   XRO) after the SVEC object.  That is, if any of these objects follows
   the SVEC object in the PCReq message, all of the requested path
   computations specified in the SVEC object are subject to OF, GC, or
   XRO.

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  Request for the Order of TE LSP</span>

   In order to minimize disruption associated with bulk path
   provisioning, the PCC may indicate to the PCE that the response MUST
   be ordered.  That is, the PCE has to include the order in which TE
   LSPs MUST be moved so as to minimize traffic disruption.  To support
   such indication a new flag, the D flag, is defined in the RP object
   as follows:

   D-bit (orDer - 1 bit): when set, in a PCReq message, the requesting
   PCC requires the PCE to specify in the PCRep message the order in
   which this particular path request is to be provisioned relative to
   other requests.

   To support the determination of whether make-before-break
   optimization is required, a new flag, the M flag, is defined in the
   RP object as follows.

   M-bit (Make-before-break - 1 bit): when set, this indicates that a
   make-before-break reoptimization is required for this request.

   When the M-bit is not set, this implies that a break-before-make
   reoptimization is allowed for this request.  Note that the M-bit can
   be set only if the R (Reoptimization) flag is set.

   Two new bit flags are defined to be carried in the Flags field in the
   RP object.

   Bit 21 (M-bit): When set, make-before-break is required.
   Bit 22 (D-bit): When set, report of the request order is required.










<span class="grey">Lee, et al.                 Standards Track                    [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>.  The Order Response</span>

   The PCE MUST specify the order number in response to the Order
   Request made by the PCC in the PCReq message if so requested by the
   setting of the D-bit in the RP object in the PCReq message.  To
   support such an ordering indication, a new optional TLV, the Order
   TLV, is defined in the RP object.

   The Order TLV is an optional TLV in the RP object, that indicates the
   order in which the old TE LSP must be removed and the new TE LSP must
   be setup during a reoptimization.  It is carried in the PCRep message
   in response to a reoptimization request.

   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.

   The format of the Order TLV is as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Type             |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Delete Order                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Setup Order                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 2: The Order TLV in the RP Object in the PCRep Message

   Type: 5
   Length: Variable

   Delete Order: 32-bit integer that indicates the order in which the
   old TE LSP should be removed.

   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
   delete order is higher than the setup order, this means that the
   reoptimization can be done in a make-before-break manner, else it
   cannot be done in a make-before-break manner.

   For a new TE LSP, the delete order is not applicable.  The value 0 is
   designated to specify this case.  When the value of the delete order
   is 0, it implies that the resulting TE LSP is a new TE LSP.




<span class="grey">Lee, et al.                 Standards Track                    [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


   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 may provide the following ordered reply:

   R1, path P1', remove order 1, setup order 4
   R2, path P2', remove order 3, setup order 2

   This indicates that the NMS should do the following sequence of
   tasks:

   1: Remove path P1
   2: Set up path P2'
   3: Remove path P2
   4: Set up path P1'

   That is, R1 is reoptimized in a break-before-make manner and R2 in a
   make-before-break manner.

<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>.  GLOBAL CONSTRAINTS (GC) Object</span>

   The GLOBAL CONSTRAINTS (GC) Object is used in a PCReq message to
   specify the necessary global constraints that should be applied to
   all individual path computations for a global concurrent path
   optimization request.

   GLOBAL-CONSTRAINTS Object-Class is 24.

   Global Constraints Object-Type is 1.

   The format of the GC object body that includes the global constraints
   is as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    MH         |    MU         |    mU         |    OB         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //                         Optional TLV(s)                     //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 3: GC Body Object Format

   MH (Max Hop: 8 bits): 8-bit integer that indicates the maximum hop
   count for all the TE LSPs.





<span class="grey">Lee, et al.                 Standards Track                    [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


   MU (Max Utilization Percentage: 8 bits) : 8-bit integer that
   indicates the upper-bound utilization percentage by which all links
   should be bound.  Utilization = (Link Capacity - Allocated Bandwidth
   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-bit integer that
   indicates the lower-bound utilization percentage by which all links
   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-bit integer that
   indicates the overbooking percentage that allows the reserved
   bandwidth to be overbooked on each link beyond its physical capacity
   limit.  The value, for example, 10% means that 110 Mbps can be
   reserved on a 100 Mbps link.

   The exclusion of the list of nodes/links from a global path
   computation can be done by including the XRO object following the GC
   object in the new SVEC-list definition.

   Optional TLVs may be included within the GC object body to specify
   additional global constraints.  The TLV format and processing is
   consistent with <a href="./rfc5440#section-7.1">Section&nbsp;7.1 of RFC 5440</a>.  Any TLVs will be allocated
   from the "PCEP TLV Type Indicators" registry.  Note that no TLVs are
   defined in this document.

<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a>.  Error Indicator</span>

   To indicate errors associated with the global concurrent path
   optimization request, a new Error-Type (14) and subsequent error-
   values are defined as follows for inclusion in the PCEP-ERROR Object:

   A new Error-Type (15) and subsequent error-values are defined as
   follows:

   Error-Type=15; Error-value=1: if a PCE receives a global concurrent
   path optimization request and the PCE is not capable of processing
   the request due to insufficient memory, the PCE MUST send a PCErr
   message with a PCEP-ERROR Object (Error-Type=15) and an Error-value
   (Error-value=1).  The PCE stops processing the request.  The
   corresponding global concurrent path optimization request MUST be
   cancelled at the PCC.

   Error-Type=15; Error-value=2: if a PCE receives a global concurrent
   path optimization request and the PCE is not capable of global
   concurrent optimization, the PCE MUST send a PCErr message with a
   PCEP-ERROR Object (Error-Type=15) and an Error-value (Error-value=2).



<span class="grey">Lee, et al.                 Standards Track                    [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


   The PCE stops processing the request.  The corresponding global
   concurrent path optimization MUST be cancelled at the PCC.

   To indicate an error associated with policy violation, a new error
   value "global concurrent optimization not allowed" should be added to
   an existing error code for policy violation (Error-Type=5) as defined
   in [<a href="./rfc5440" title="&quot;Path Computation Element (PCE) Communication Protocol (PCEP)&quot;">RFC5440</a>].

   Error-Type=5; Error-value=5: if a PCE receives a global concurrent
   path optimization request that is not compliant with administrative
   privileges (i.e., the PCE policy does not support global concurrent
   optimization), the PCE sends a PCErr message with a PCEP-ERROR Object
   (Error-Type=5) and an Error-value (Error-value=5).  The PCE stops the
   processing the request.  The corresponding global concurrent path
   computation MUST be cancelled at the PCC.

<span class="h3"><a class="selflink" id="section-5.7" href="#section-5.7">5.7</a>.  NO-PATH Indicator</span>

   To communicate the reason(s) for not being able to find global
   concurrent path computation, the NO-PATH object can be used in the
   PCRep message.  The format of the NO-PATH object body is defined in
   [<a href="./rfc5440" title="&quot;Path Computation Element (PCE) Communication Protocol (PCEP)&quot;">RFC5440</a>].  The object may contain a NO-PATH-VECTOR TLV to provide
   additional information about why a path computation has failed.

   Two new bit flags are defined to be carried in the Flags field in the
   NO-PATH-VECTOR TLV carried in the NO-PATH Object.

   Bit 6: When set, the PCE indicates that no migration path was found.

   Bit 7: When set, the PCE indicates no feasible solution was found
   that meets all the constraints associated with global concurrent path
   optimization in the PCRep message.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Manageability Considerations</span>

   Manageability of global concurrent path computation with PCE must
   address the following considerations:

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Control of Function and Policy</span>

   In addition to the parameters already listed in <a href="./rfc5440#section-8.1">Section&nbsp;8.1 of
   [RFC5440]</a>, a PCEP implementation SHOULD allow configuring the
   following PCEP session parameters on a PCC:

   o  The ability to send a GCO request.






<span class="grey">Lee, et al.                 Standards Track                    [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


   In addition to the parameters already listed in <a href="./rfc5440#section-8.1">Section&nbsp;8.1 of
   [RFC5440]</a>, a PCEP implementation SHOULD allow configuring the
   following PCEP session parameters on a PCE:

   o  The support for Global Concurrent Optimization.

   o  The maximum number of synchronized path requests per request
      message.

   o  A set of GCO specific policies (authorized sender, request rate
      limiter, etc.).

   These parameters may be configured as default parameters for any PCEP
   session the PCEP speaker participates in, or may apply to a specific
   session with a given PCEP peer or a specific group of sessions with a
   specific group of PCEP peers.

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Information and Data Models (e.g., MIB Module)</span>

   Extensions to the PCEP MIB module defined in [<a href="#ref-PCEP-MIB" title="&quot;PCE communication protocol (PCEP) Management Information Base&quot;">PCEP-MIB</a>] should be
   defined, so as to cover the GCO information introduced in this
   document.

<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>.  Liveness Detection and Monitoring</span>

   Mechanisms defined in this document do not imply any new liveness
   detection and monitoring requirements in addition to those already
   listed in <a href="./rfc5440#section-8.3">Section&nbsp;8.3 of [RFC5440]</a>.

<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>.  Verifying Correct Operation</span>

   Mechanisms defined in this document do not imply any new verification
   requirements in addition to those already listed in <a href="./rfc5440#section-8.4">Section&nbsp;8.4 of
   [RFC5440]</a>

<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>.  Requirements on Other Protocols and Functional Components</span>

   The PCE Discovery mechanisms ([<a href="./rfc5088" title="&quot;OSPF Protocol Extensions for Path Computation Element (PCE) Discovery&quot;">RFC5088</a>] and [<a href="./rfc5089" title="&quot;IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery&quot;">RFC5089</a>]) may be used to
   advertise global concurrent path computation capabilities to PCCs.  A
   new flag (value=9) in PCE-CAP-FLAGs Sub-TLV has been assigned to be
   able to indicate GCO capability.

<span class="h3"><a class="selflink" id="section-6.6" href="#section-6.6">6.6</a>.  Impact on Network Operation</span>

   Mechanisms defined in this document do not imply any new network
   operation requirements in addition to those already listed in <a href="./rfc5440#section-8.6">Section</a>
   <a href="./rfc5440#section-8.6">8.6 of [RFC5440]</a>.




<span class="grey">Lee, et al.                 Standards Track                    [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Security Considerations</span>

   When global reoptimization is applied to an active network, it could
   be extremely disruptive.  Although the real security and policy
   issues apply at the NMS, if the wrong results are returned to the
   NMS, the wrong actions may be taken in the network.  Therefore, it is
   very important that the operator issuing the commands has sufficient
   authority and is authenticated, and that the computation request is
   subject to appropriate policy.

   The mechanism defined in [<a href="./rfc5440" title="&quot;Path Computation Element (PCE) Communication Protocol (PCEP)&quot;">RFC5440</a>] to secure a PCEP session can be
   used to secure global concurrent path computation requests/responses.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  IANA Considerations</span>

   IANA maintains a registry of PCEP parameters.  IANA has made
   allocations from the sub-registries as described in the following
   sections.

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  Request Parameter Bit Flags</span>

   As described in <a href="#section-5.3">Section 5.3</a>, two new bit flags are defined for
   inclusion in the Flags field of the RP object.  IANA has made the
   following allocations from the "RP Object Flag Field" sub-registry.

      Bit      Description                         Reference

      21       Make-before-break (M-bit)           [<a href="./rfc5557">RFC5557</a>]
      22       Report the request order (D-bit)    [<a href="./rfc5557">RFC5557</a>]

<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>.  New PCEP TLV</span>

   As described in <a href="#section-5.4">Section 5.4</a>, a new PCEP TLV is defined to indicate
   the setup and delete order of TE LSPs in a GCO.  IANA has made the
   following allocation from the "PCEP TLV Type Indicators" sub-
   registry.

      TLV Type        Meaning                 Reference

      5               Order TLV               [<a href="./rfc5557">RFC5557</a>]











<span class="grey">Lee, et al.                 Standards Track                    [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>.  New Flag in PCE-CAP-FLAGS Sub-TLV in PCED</span>

   As described in <a href="#section-6.5">Section 6.5</a>, a new PCE-CAP-FLAGS Sub-TLV is defined
   to indicate a GCO capability.  IANA has made the following allocation
   from the "Path Computation Element (PCE) Capability Flags" sub-
   registry, which was created by <a href="./rfc5088#section-7.2">Section&nbsp;7.2 of RFC 5088</a>.  It is an
   OSPF registry.

      FLAG            Meaning                                Reference

      9               Global Concurrent Optimization (GCO)   [<a href="./rfc5557">RFC5557</a>]

<span class="h3"><a class="selflink" id="section-8.4" href="#section-8.4">8.4</a>.  New PCEP Object</span>

   As descried in <a href="#section-5.5">Section 5.5</a>, a new PCEP object is defined to carry
   global constraints.  IANA has made the following allocation from the
   "PCEP Objects" sub-registry.

      Object  Name                                            Reference
      Class

      24      GLOBAL-CONSTRAINTS                              [<a href="./rfc5557">RFC5557</a>]
                  Object-Type
                  1: Global Constraints                       [<a href="./rfc5557">RFC5557</a>]

<span class="h3"><a class="selflink" id="section-8.5" href="#section-8.5">8.5</a>.  New PCEP Error Codes</span>

   As described in <a href="#section-5.6">Section 5.6</a>, new PCEP error codes are defined for GCO
   errors.  IANA has made allocations from the "PCEP-ERROR Object Error
   Types and Values" sub-registry as set out in the following sections.

<span class="h4"><a class="selflink" id="section-8.5.1" href="#section-8.5.1">8.5.1</a>.  New Error-Values for Existing Error-Types</span>

      Error-
      Type    Meaning                                         Reference

      5       Policy violation
                Error-value=5:                                [<a href="./rfc5557">RFC5557</a>]
                  Global concurrent optimization not allowed












<span class="grey">Lee, et al.                 Standards Track                    [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


<span class="h4"><a class="selflink" id="section-8.5.2" href="#section-8.5.2">8.5.2</a>.  New Error-Types and Error-Values</span>

      Error-
      Type    Meaning                                         Reference

      15      Global Concurrent Optimization Error            [<a href="./rfc5557">RFC5557</a>]
                Error-value=1:
                  Insufficient memory                         [<a href="./rfc5557">RFC5557</a>]
                Error-value=2:
                  Global concurrent optimization not supported
                                                              [<a href="./rfc5557">RFC5557</a>]

<span class="h3"><a class="selflink" id="section-8.6" href="#section-8.6">8.6</a>.  New No-Path Reasons</span>

   IANA has made the following allocations from the "NO-PATH-VECTOR TLV
   Flag Field" sub-registry for bit flags carried in the NO-PATH-VECTOR
   TLV in the PCEP NO-PATH object as described in <a href="#section-5.7">Section 5.7</a>.

      Bit
      Number          Name                         Reference

      25              No GCO solution found        [<a href="./rfc5557">RFC5557</a>]
      26              No GCO migration path found  [<a href="./rfc5557">RFC5557</a>]

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  References</span>

<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>.  Normative References</span>

   [<a id="ref-RFC5441">RFC5441</a>]  Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
              "A Backward-Recursive PCE-Based Computation (BRPC)
              Procedure to Compute Shortest Constrained Inter-Domain
              Traffic Engineering Label Switched Paths", <a href="./rfc5441">RFC 5441</a>, April
              2009.

   [<a id="ref-RFC5541">RFC5541</a>]  Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
              Objective Functions in Path Computation Element
              Communication Protocol (PCEP)", <a href="./rfc5541">RFC 5541</a>, May 2009.

   [<a id="ref-RFC5521">RFC5521</a>]  Oki, E., Takeda, T., and A. Farrel, "Extensions to the
              Path Computation Element Communication Protocol (PCEP) for
              Route Exclusions", <a href="./rfc5521">RFC 5521</a>, April 2009.

   [<a id="ref-RFC5440">RFC5440</a>]  Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", <a href="./rfc5440">RFC 5440</a>,
              March 2009.

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.



<span class="grey">Lee, et al.                 Standards Track                    [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


   [<a id="ref-RFC3209">RFC3209</a>]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", <a href="./rfc3209">RFC 3209</a>, December 2001.

   [<a id="ref-RFC5088">RFC5088</a>]  Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
              Zhang, "OSPF Protocol Extensions for Path Computation
              Element (PCE) Discovery", <a href="./rfc5088">RFC 5088</a>, January 2008.

   [<a id="ref-RFC5089">RFC5089</a>]  Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
              Zhang, "IS-IS Protocol Extensions for Path Computation
              Element (PCE) Discovery", <a href="./rfc5089">RFC 5089</a>, January 2008.

<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>.  Informative References</span>

   [<a id="ref-PCE-MLN">PCE-MLN</a>]  Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
              "Framework for PCE-Based Inter-Layer MPLS and GMPLS
              Traffic Engineering", Work in Progress, March 2009.

   [<a id="ref-PCEP-MIB">PCEP-MIB</a>] Koushik, K. and E. Stephan, "PCE communication protocol
              (PCEP) Management Information Base", Work in Progress,
              November 2008.

   [<a id="ref-RFC5511">RFC5511</a>]  Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
              Used to Form Encoding Rules in Various Routing Protocol
              Specifications", <a href="./rfc5511">RFC 5511</a>, April 2009.

   [<a id="ref-RFC4655">RFC4655</a>]  Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
              Computation Element (PCE)-Based Architecture", <a href="./rfc4655">RFC 4655</a>,
              August 2006.

   [<a id="ref-RFC4657">RFC4657</a>]  Ash, J., Ed., and J. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol Generic
              Requirements", <a href="./rfc4657">RFC 4657</a>, September 2006.

   [<a id="ref-RFC4674">RFC4674</a>]  Le Roux, J., Ed., "Requirements for Path Computation
              Element (PCE) Discovery", <a href="./rfc4674">RFC 4674</a>, October 2006.

   [<a id="ref-RFC5212">RFC5212</a>]  Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
              M., and D. Brungard, "Requirements for GMPLS-Based Multi-
              Region and Multi-Layer Networks (MRN/MLN)", <a href="./rfc5212">RFC 5212</a>, July
              2008.

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  Acknowledgments</span>

   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.




<span class="grey">Lee, et al.                 Standards Track                    [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  RBNF Code Fragments</span>

   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.

   &lt;PCReq Message&gt; ::= &lt;Common Header&gt;
                       [&lt;svec-list&gt;]
                       &lt;request-list&gt;

   &lt;svec-list&gt; ::= &lt;SVEC&gt;
                   [&lt;OF&gt;]
                   [&lt;GC&gt;]
                   [&lt;XRO&gt;]
                   [&lt;svec-list&gt;]









<span class="grey">Lee, et al.                 Standards Track                    [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc5557">RFC 5557</a>    PCEP Requirements &amp; Protocol Extensions for GCO    July 2009</span>


Authors' Addresses

   Young Lee
   Huawei
   1700 Alma Drive, Suite 100
   Plano, TX  75075
   US

   Phone: +1 972 509 5599 x2240
   Fax:   +1 469 229 5397
   EMail: ylee@huawei.com


   JL Le Roux
   France Telecom
   2, Avenue Pierre-Marzin
   Lannion  22307
   FRANCE

   EMail: jeanlouis.leroux@orange-ftgroup.com


   Daniel King
   Old Dog Consulting
   United Kingdom

   EMail: daniel@olddog.co.uk


   Eiji Oki
   University of Electro-Communications
   1-5-1 Chofugaoka
   Chofu, Tokyo  182-8585
   JAPAN

   EMail: oki@ice.uec.ac.jp















Lee, et al.                 Standards Track                    [Page 26]
</pre>