summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5557.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5557.txt')
-rw-r--r--doc/rfc/rfc5557.txt1459
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc5557.txt b/doc/rfc/rfc5557.txt
new file mode 100644
index 0000000..5acc013
--- /dev/null
+++ b/doc/rfc/rfc5557.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+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
+
+
+ Path Computation Element Communication Protocol (PCEP) Requirements
+ and Protocol Extensions in Support of Global Concurrent Optimization
+
+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.
+
+
+
+
+
+
+
+
+
+
+Lee, et al. Standards Track [Page 1]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+Copyright Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents in effect on the date of
+ publication of this document (http://trustee.ietf.org/license-info).
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lee, et al. Standards Track [Page 2]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 2. Terminology .....................................................6
+ 3. Applicability of Global Concurrent Optimization (GCO) ...........6
+ 3.1. Application of the PCE Architecture ........................7
+ 3.2. Greenfield Optimization ....................................8
+ 3.2.1. Single-Layer Traffic Engineering ....................8
+ 3.2.2. Multi-Layer Traffic Engineering .....................8
+ 3.3. Reoptimization of Existing Networks ........................8
+ 3.3.1. Reconfiguration of the Virtual Network
+ Topology (VNT) ......................................9
+ 3.3.2. Traffic Migration ...................................9
+ 4. PCECP Requirements .............................................10
+ 5. Protocol Extensions for Support of Global Concurrent
+ Optimization ...................................................13
+ 5.1. Global Objective Function (GOF) Specification .............14
+ 5.2. Indication of Global Concurrent Optimization Requests .....15
+ 5.3. Request for the Order of TE LSP ...........................15
+ 5.4. The Order Response ........................................16
+ 5.5. GLOBAL CONSTRAINTS (GC) Object ............................17
+ 5.6. Error Indicator ...........................................18
+ 5.7. NO-PATH Indicator .........................................19
+ 6. Manageability Considerations ...................................19
+ 6.1. Control of Function and Policy ............................19
+ 6.2. Information and Data Models (e.g., MIB Module) ............20
+ 6.3. Liveness Detection and Monitoring .........................20
+ 6.4. Verifying Correct Operation ...............................20
+ 6.5. Requirements on Other Protocols and Functional
+ Components ................................................20
+ 6.6. Impact on Network Operation ...............................20
+ 7. Security Considerations ........................................21
+ 8. IANA Considerations ............................................21
+ 8.1. Request Parameter Bit Flags ...............................21
+ 8.2. New PCEP TLV ..............................................21
+ 8.3. New Flag in PCE-CAP-FLAGS Sub-TLV in PCED .................22
+ 8.4. New PCEP Object ...........................................22
+ 8.5. New PCEP Error Codes ......................................22
+ 8.5.1. New Error-Values for Existing Error-Types ..........22
+ 8.5.2. New Error-Types and Error-Values ...................23
+ 8.6. New No-Path Reasons .......................................23
+ 9. References .....................................................23
+ 9.1. Normative References ......................................23
+ 9.2. Informative References ....................................24
+ 10. Acknowledgments ...............................................24
+ Appendix A. RBNF Code Fragments ...................................25
+
+
+
+
+
+Lee, et al. Standards Track [Page 3]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+1. Introduction
+
+ [RFC4655] defines the Path Computation Element (PCE)-based
+ architecture and explains how a PCE may compute Label Switched Paths
+ (LSPs) in Multiprotocol Label Switching Traffic Engineering (MPLS-TE)
+ and Generalized MPLS (GMPLS) networks at the request of Path
+ Computation Clients (PCCs). A PCC is shown to be any network
+ component that makes such a request and may be, for instance, a Label
+ Switching Router (LSR) or a Network Management System (NMS). The
+ PCE, itself, is shown to be located anywhere within the network, and
+ 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. [RFC4657] sets out generic protocol requirements for PCEP.
+ Additional application-specific requirements for PCEP are defined in
+ separate documents.
+
+ This document provides a set of requirements and PCEP extensions in
+ support of concurrent path computation applications. A concurrent
+ path computation is a path computation application where a set of TE
+ paths are computed concurrently in order to efficiently utilize
+ network resources. The computation method involved with a concurrent
+ path computation is referred to as "global concurrent optimization"
+ in this document. Appropriate computation algorithms to perform this
+ type of optimization are out of the scope of this document.
+
+ The Global Concurrent Optimization (GCO) application is primarily an
+ NMS or a PCE-Server-based solution. Owing to complex synchronization
+ issues associated with GCO applications, the management-based PCE
+ architecture defined in Section 5.5 of [RFC4655] is considered as the
+ most suitable usage to support GCO application. This does not
+ preclude other architectural alternatives to support GCO application,
+ but they are NOT RECOMMENDED. For instance, GCO might be enabled by
+ distributed LSRs through complex synchronization mechanisms.
+ However, this approach might suffer from significant synchronization
+ overhead between the PCE and each of the PCCs. It would likely
+ affect the network stability and hence significantly diminish the
+ benefits of deploying PCEs.
+
+ The need for global concurrent path computation may also arise when
+ network operators need to establish a set of TE LSPs in their network
+ planning process. It is also envisioned that network operators might
+ require global concurrent path computation in the event of
+ catastrophic network failures, where a set of TE LSPs need to be
+
+
+
+
+
+Lee, et al. Standards Track [Page 4]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+ 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 [RFC4674], [RFC5088], [RFC5089]; but, that is
+ out of the scope of this document.
+
+ It is to be noted that Backward Recursive Path Computation (BRPC)
+ [RFC5441] 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.
+
+
+
+
+Lee, et al. Standards Track [Page 5]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+2. Terminology
+
+ Most of the terminology used in this document is explained in
+ [RFC4655]. A few key terms are repeated here for clarity.
+
+ PCC: Path Computation Client. Any client application requesting a
+ path computation to be performed by a Path Computation Element.
+
+ PCE: Path Computation Element. An entity (component, application, or
+ network node) that is capable of computing a network path or route
+ based on a network graph and applying computational constraints.
+
+ TED: Traffic Engineering Database. 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 RFC 2119 [RFC2119].
+ These terms are used to specify requirements in this document.
+
+3. Applicability of Global Concurrent Optimization (GCO)
+
+ This section discusses the PCE architecture to which GCO is applied.
+ It also discusses various application scenarios for which global
+ concurrent path computation may be applied.
+
+
+
+
+
+
+
+Lee, et al. Standards Track [Page 6]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+3.1. Application of the PCE Architecture
+
+ Figure 1 shows the PCE-based network architecture as defined in
+ [RFC4655] to which GCO application is applied. It must be observed
+ that the PCC is not necessarily an LSR [RFC4655]. The GCO
+ application is primarily an NMS-based solution in which an NMS plays
+ the function of the PCC. Although Figure 1 shows the PCE as remote
+ from the NMS, it might be collocated with the NMS. Note that in the
+ collocated case, there is no need for a standard communication
+ protocol; this can rely on internal APIs.
+
+ -----------
+ Application | ----- |
+ Request | | TED | |
+ | | ----- |
+ v | | |
+ ------------- Request/ | v |
+ | PCC | Response| ----- |
+ | (NMS/Server)|<--------+> | PCE | |
+ | | | ----- |
+ ------------- -----------
+ Service |
+ Request |
+ v
+ ---------- Signaling ----------
+ | Head-End | Protocol | Adjacent |
+ | Node |<---------->| Node |
+ ---------- ----------
+
+ Figure 1: PCE-Based Architecture for
+ Global Concurrent Optimization
+
+ Upon receipt of an application request (e.g., a traffic demand matrix
+ is provided to the NMS by the operator's network planning procedure),
+ the NMS requests a global concurrent path computation from the PCE.
+ The PCE then computes the requested paths concurrently applying some
+ algorithms. Various algorithms and computation techniques have been
+ proposed to perform this function. Specification of such algorithms
+ 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.
+
+
+
+
+
+
+
+Lee, et al. Standards Track [Page 7]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+3.2. Greenfield Optimization
+
+ 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.
+
+3.2.1. Single-Layer Traffic Engineering
+
+ Greenfield optimization can be applied when layer-specific TE LSPs
+ need to be created from a greenfield perspective. For example, an
+ MPLS-TE network can be planned based on Layer 3 specific traffic
+ demands, the network topology, and available network resources.
+ Greenfield optimization for single-layer traffic engineering can be
+ applied to optical transport networks such as Synchronous Digital
+ Hierarchy/Synchronous Optical Network (SDH/SONET), Ethernet
+ Transport, Wavelength Division Multiplexing (WDM), etc.
+
+3.2.2. Multi-Layer Traffic Engineering
+
+ Greenfield optimization is not limited to single-layer traffic
+ engineering. It can also be applied to multi-layer traffic
+ engineering [PCE-MLN]. 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.
+
+3.3. Reoptimization of Existing Networks
+
+ The need for global concurrent path computation may arise in existing
+ networks. When an existing TE LSP network experiences sub-optimal
+ use of its resources, the need for 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.
+
+
+
+Lee, et al. Standards Track [Page 8]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+ 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.
+
+3.3.1. Reconfiguration of the Virtual Network Topology (VNT)
+
+ Reconfiguration of the VNT [RFC5212] [PCE-MLN] is a typical
+ application scenario where global concurrent path computation may be
+ applicable. Triggers for VNT reconfiguration, such as traffic demand
+ changes, network failures, and topological configuration changes may
+ require a set of existing TE LSPs to be re-computed.
+
+3.3.2. Traffic Migration
+
+ When migrating from one set of TE LSPs to a reoptimized set of TE
+ LSPs, it is important that the traffic be moved without causing
+ disruption. Various techniques exist in MPLS and GMPLS, such as
+ make-before-break [RFC3209], to establish the new 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
+
+
+
+Lee, et al. Standards Track [Page 9]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+ 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).
+
+4. PCECP Requirements
+
+ This section provides the PCECP requirements to support global
+ concurrent path computation applications. The requirements specified
+ here should be regarded as application-specific requirements and are
+ justifiable based on the extensibility clause found in Section 6.1.14
+ of [RFC4657]:
+
+ The PCECP MUST support the requirements specified in the
+ application-specific requirements documents. The PCECP MUST also
+ allow extensions as more PCE applications will be introduced in
+ the future.
+
+ It is also to be noted that some of the requirements discussed in
+ this section have already been discussed in the PCECP requirement
+ document [RFC4657]. For example, Section 5.1.16 in [RFC4657]
+ provides a list of generic constraints while Section 5.1.17 in
+ [RFC4657] provides a list of generic objective functions that MUST be
+ supported by the PCECP. While using such generic requirements as the
+
+
+
+Lee, et al. Standards Track [Page 10]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+ baseline, this section provides application-specific requirements in
+ the context of global concurrent path computation and in a more
+ detailed level than the generic requirements.
+
+ The PCEP SHOULD support the following capabilities either via
+ creation of new objects and/or modification of existing objects where
+ applicable.
+
+ o An indicator to convey that the request is for a global concurrent
+ path computation. This indicator is necessary to ensure
+ consistency in applying global objectives and global constraints
+ in all path computations. Note: This requirement is covered by
+ "synchronized path computation" in [RFC4655] and [RFC4657].
+ However, an explicit indicator to request a global concurrent
+ optimization is a new requirement.
+
+
+ o A Global Objective Function (GOF) field in which to specify the
+ global objective function. The global objective function is the
+ overarching objective function to which all individual path
+ computation requests are subjected in order to find a globally
+ optimal solution. Note that this requirement is covered by
+ "synchronized objective functions" in Section 5.1.7 [RFC4657] and
+ that [RFC5541] 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.)
+
+
+
+Lee, et al. Standards Track [Page 11]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+ * 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 [RFC4657] and defined in [RFC5440]).
+
+ * 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 [RFC4657] and defined in
+ [RFC5440]).
+
+ * 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 [RFC5440]. Since the SVEC object as defined in
+ [RFC5440] 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 [RFC4657], but not in this
+ level of detail. The following indicators SHOULD be supported at
+ the minimum:
+
+ * no feasible solution found. Note that this is already covered
+ in [RFC5440].
+
+ * memory overflow.
+
+ * PCE too busy. Note that this is already covered in [RFC5440].
+
+ * PCE not capable of concurrent reoptimization.
+
+ * no migration path available.
+
+ * administrative privileges do not allow global reoptimization.
+
+
+
+Lee, et al. Standards Track [Page 12]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+ 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).
+
+5. Protocol Extensions for Support of Global Concurrent Optimization
+
+ This section provides protocol extensions for support of global
+ concurrent optimization. Protocol extensions discussed in this
+ section are built on [RFC5440].
+
+ 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
+ [RFC5511]. Please see Appendix A for a full set of RBNF fragments
+ defined in this document and the necessary code license.
+
+ <PCReq Message> ::= <Common Header>
+ [<svec-list>]
+ <request-list>
+
+
+
+
+
+
+Lee, et al. Standards Track [Page 13]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+ The <svec-list> is changed as follows:
+
+ <svec-list> ::= <SVEC>
+ [<OF>]
+ [<GC>]
+ [<XRO>]
+ [<svec-list>]
+
+ Note that three optional objects are added, following the SVEC
+ object: the OF (Objective Function) object, which is defined in
+ [RFC5541], the GC (Global Constraints) object, which is defined in
+ this document (Section 5.5), as well as the eXclude Route Object
+ (XRO), which is defined in [RFC5521]. The placement of the OF object
+ (in which the global objective function is specified) in the SVEC-
+ list is defined in [RFC5541]. 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.
+
+5.1. Global Objective Function (GOF) Specification
+
+ The global objective function can be specified in the PCEP Objective
+ Function (OF) object, defined in [RFC5541]. The OF object includes a
+ 16-bit Objective Function identifier. As discussed in [RFC5541],
+ Objective Function identifier code points are managed by IANA.
+
+ Three global objective functions defined in [RFC5541] 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.
+
+
+
+
+
+
+
+Lee, et al. Standards Track [Page 14]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+5.2. Indication of Global Concurrent Optimization Requests
+
+ All the path requests in this application should be indicated so that
+ the global objective function and all of the global constraints are
+ applied to each of the requested path computation. This can be
+ indicated implicitly by placing the GCO related objects (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.
+
+5.3. Request for the Order of TE LSP
+
+ In order to minimize disruption associated with bulk path
+ provisioning, the PCC may indicate to the PCE that the response MUST
+ be ordered. That is, the PCE has to include the order in which 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.
+
+
+
+
+
+
+
+
+
+
+Lee, et al. Standards Track [Page 15]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+5.4. The Order Response
+
+ The PCE MUST specify the order number in response to the Order
+ Request made by the PCC in the PCReq message if so requested by the
+ setting of the D-bit in the RP object in the PCReq message. To
+ support such 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.
+
+
+
+
+Lee, et al. Standards Track [Page 16]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+ 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.
+
+5.5. GLOBAL CONSTRAINTS (GC) Object
+
+ The GLOBAL CONSTRAINTS (GC) Object is used in a PCReq message to
+ specify the necessary global constraints that should be applied to
+ all individual path computations for a global concurrent path
+ optimization request.
+
+ GLOBAL-CONSTRAINTS Object-Class is 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.
+
+
+
+
+
+Lee, et al. Standards Track [Page 17]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+ 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 Section 7.1 of RFC 5440. Any TLVs will be allocated
+ from the "PCEP TLV Type Indicators" registry. Note that no TLVs are
+ defined in this document.
+
+5.6. Error Indicator
+
+ To indicate errors associated with the global concurrent path
+ optimization request, a new Error-Type (14) and subsequent error-
+ values are defined as follows for inclusion in the PCEP-ERROR Object:
+
+ A new Error-Type (15) and subsequent error-values are defined as
+ follows:
+
+ Error-Type=15; 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).
+
+
+
+Lee, et al. Standards Track [Page 18]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+ 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 [RFC5440].
+
+ 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.
+
+5.7. NO-PATH Indicator
+
+ To communicate the reason(s) for not being able to find global
+ concurrent path computation, the NO-PATH object can be used in the
+ PCRep message. The format of the NO-PATH object body is defined in
+ [RFC5440]. 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.
+
+6. Manageability Considerations
+
+ Manageability of global concurrent path computation with PCE must
+ address the following considerations:
+
+6.1. Control of Function and Policy
+
+ In addition to the parameters already listed in Section 8.1 of
+ [RFC5440], a PCEP implementation SHOULD allow configuring the
+ following PCEP session parameters on a PCC:
+
+ o The ability to send a GCO request.
+
+
+
+
+
+
+Lee, et al. Standards Track [Page 19]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+ In addition to the parameters already listed in Section 8.1 of
+ [RFC5440], a PCEP implementation SHOULD allow configuring the
+ following PCEP session parameters on a PCE:
+
+ o The support for Global Concurrent Optimization.
+
+ o The maximum number of synchronized path requests per request
+ message.
+
+ o A set of GCO specific policies (authorized sender, request rate
+ limiter, etc.).
+
+ These parameters may be configured as default parameters for any PCEP
+ session the PCEP speaker participates in, or may apply to a specific
+ session with a given PCEP peer or a specific group of sessions with a
+ specific group of PCEP peers.
+
+6.2. Information and Data Models (e.g., MIB Module)
+
+ Extensions to the PCEP MIB module defined in [PCEP-MIB] should be
+ defined, so as to cover the GCO information introduced in this
+ document.
+
+6.3. Liveness Detection and Monitoring
+
+ Mechanisms defined in this document do not imply any new liveness
+ detection and monitoring requirements in addition to those already
+ listed in Section 8.3 of [RFC5440].
+
+6.4. Verifying Correct Operation
+
+ Mechanisms defined in this document do not imply any new verification
+ requirements in addition to those already listed in Section 8.4 of
+ [RFC5440]
+
+6.5. Requirements on Other Protocols and Functional Components
+
+ The PCE Discovery mechanisms ([RFC5088] and [RFC5089]) 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.
+
+6.6. Impact on Network Operation
+
+ Mechanisms defined in this document do not imply any new network
+ operation requirements in addition to those already listed in Section
+ 8.6 of [RFC5440].
+
+
+
+
+Lee, et al. Standards Track [Page 20]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+7. Security Considerations
+
+ 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 [RFC5440] to secure a PCEP session can be
+ used to secure global concurrent path computation requests/responses.
+
+8. IANA Considerations
+
+ IANA maintains a registry of PCEP parameters. IANA has made
+ allocations from the sub-registries as described in the following
+ sections.
+
+8.1. Request Parameter Bit Flags
+
+ As described in Section 5.3, 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) [RFC5557]
+ 22 Report the request order (D-bit) [RFC5557]
+
+8.2. New PCEP TLV
+
+ As described in Section 5.4, a new PCEP TLV is defined to indicate
+ the setup and delete order of TE LSPs in a GCO. IANA has made the
+ following allocation from the "PCEP TLV Type Indicators" sub-
+ registry.
+
+ TLV Type Meaning Reference
+
+ 5 Order TLV [RFC5557]
+
+
+
+
+
+
+
+
+
+
+
+Lee, et al. Standards Track [Page 21]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+8.3. New Flag in PCE-CAP-FLAGS Sub-TLV in PCED
+
+ As described in Section 6.5, a new PCE-CAP-FLAGS Sub-TLV is 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 Section 7.2 of RFC 5088. It is an
+ OSPF registry.
+
+ FLAG Meaning Reference
+
+ 9 Global Concurrent Optimization (GCO) [RFC5557]
+
+8.4. New PCEP Object
+
+ As descried in Section 5.5, 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 [RFC5557]
+ Object-Type
+ 1: Global Constraints [RFC5557]
+
+8.5. New PCEP Error Codes
+
+ As described in Section 5.6, 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.
+
+8.5.1. New Error-Values for Existing Error-Types
+
+ Error-
+ Type Meaning Reference
+
+ 5 Policy violation
+ Error-value=5: [RFC5557]
+ Global concurrent optimization not allowed
+
+
+
+
+
+
+
+
+
+
+
+
+Lee, et al. Standards Track [Page 22]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+8.5.2. New Error-Types and Error-Values
+
+ Error-
+ Type Meaning Reference
+
+ 15 Global Concurrent Optimization Error [RFC5557]
+ Error-value=1:
+ Insufficient memory [RFC5557]
+ Error-value=2:
+ Global concurrent optimization not supported
+ [RFC5557]
+
+8.6. New No-Path Reasons
+
+ 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 Section 5.7.
+
+ Bit
+ Number Name Reference
+
+ 25 No GCO solution found [RFC5557]
+ 26 No GCO migration path found [RFC5557]
+
+9. References
+
+9.1. Normative References
+
+ [RFC5441] 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", RFC 5441, April
+ 2009.
+
+ [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
+ Objective Functions in Path Computation Element
+ Communication Protocol (PCEP)", RFC 5541, May 2009.
+
+ [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
+ Path Computation Element Communication Protocol (PCEP) for
+ Route Exclusions", RFC 5521, April 2009.
+
+ [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation
+ Element (PCE) Communication Protocol (PCEP)", RFC 5440,
+ March 2009.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+Lee, et al. Standards Track [Page 23]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+ [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+ and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+ Tunnels", RFC 3209, December 2001.
+
+ [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
+ Zhang, "OSPF Protocol Extensions for Path Computation
+ Element (PCE) Discovery", RFC 5088, January 2008.
+
+ [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
+ Zhang, "IS-IS Protocol Extensions for Path Computation
+ Element (PCE) Discovery", RFC 5089, January 2008.
+
+9.2. Informative References
+
+ [PCE-MLN] 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.
+
+ [PCEP-MIB] Koushik, K. and E. Stephan, "PCE communication protocol
+ (PCEP) Management Information Base", Work in Progress,
+ November 2008.
+
+ [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
+ Used to Form Encoding Rules in Various Routing Protocol
+ Specifications", RFC 5511, April 2009.
+
+ [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
+ Computation Element (PCE)-Based Architecture", RFC 4655,
+ August 2006.
+
+ [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation
+ Element (PCE) Communication Protocol Generic
+ Requirements", RFC 4657, September 2006.
+
+ [RFC4674] Le Roux, J., Ed., "Requirements for Path Computation
+ Element (PCE) Discovery", RFC 4674, October 2006.
+
+ [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
+ M., and D. Brungard, "Requirements for GMPLS-Based Multi-
+ Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July
+ 2008.
+
+10. Acknowledgments
+
+ We would like to thank Jerry Ash, Adrian Farrel, J-P Vasseur, Ning
+ So, Lucy Yong, and Fabien Verhaeghe for their useful comments and
+ suggestions.
+
+
+
+
+Lee, et al. Standards Track [Page 24]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+Appendix A. RBNF Code Fragments
+
+ Copyright (c) 2009 IETF Trust and the persons identified as authors
+ of the code. All rights reserved.
+
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions
+ are met:
+
+ - Redistributions of source code must retain the above copyright
+ notice, this list of conditions and the following disclaimer.
+
+ - Redistributions in binary form must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the
+ distribution.
+
+ - Neither the name of Internet Society, IETF or IETF Trust, nor the
+ names of specific contributors, may be used to endorse or promote
+ products derived from this software without specific prior written
+ permission.
+
+ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+ <PCReq Message> ::= <Common Header>
+ [<svec-list>]
+ <request-list>
+
+ <svec-list> ::= <SVEC>
+ [<OF>]
+ [<GC>]
+ [<XRO>]
+ [<svec-list>]
+
+
+
+
+
+
+
+
+
+Lee, et al. Standards Track [Page 25]
+
+RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009
+
+
+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]
+