From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5557.txt | 1459 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1459 insertions(+) create mode 100644 doc/rfc/rfc5557.txt (limited to 'doc/rfc/rfc5557.txt') 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. + + ::= + [] + + + + + + + +Lee, et al. Standards Track [Page 13] + +RFC 5557 PCEP Requirements & Protocol Extensions for GCO July 2009 + + + The is changed as follows: + + ::= + [] + [] + [] + [] + + 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. + + ::= + [] + + + ::= + [] + [] + [] + [] + + + + + + + + + +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] + -- cgit v1.2.3