RFC 5557
Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization
Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization 💖🦋
okay bestie, this is Part 1 of 6 ✨ and it's the front door to RFC 5557 🎀. Dated July 2009 🌸, it's a Standards Track doc from the Network Working Group, and it's written by four authors: Y. Lee from Huawei, JL. Le Roux from France Telecom, D. King from Old Dog Consulting, and E. Oki from the University of Electro Communications 🧚. Nothing is listed in the title block as obsoleted or updated 👀, so it's a standalone spec. Slay 💅
Abstract ✨
okay so PCEP lets Path Computation Clients (PCCs) ask Path Computation Elements (PCEs) to do path computations, and the PCEs send responses back 💌. When you're computing or reoptimizing the routes for a bunch of Traffic Engineering Label Switched Paths (TE LSPs) across a network, it may be advantageous to do bulk path computations 🔥. Why? To dodge blocking problems and get more optimal solutions for the whole network 👑.
That bulk optimization is called Global Concurrent Optimization (GCO) 💜. A GCO can look at the entire network topology and the full set of existing TE LSPs, along with their constraints, all at once 🦋. Then it tries to optimize or reoptimize the whole network so every constraint for every TE LSP is satisfied 😭✨. A GCO may also be applied to just a subset of the TE LSPs in a network 🌈. The GCO application is mainly a Network Management System (NMS) solution, so it's giving management-plane energy 💅.
This document gives the application-specific requirements and the PCEP extensions that support GCO applications 🎀. Iconic 🙌
Status of This Memo 🌸
This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. If you want to know where this protocol stands in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🍓.
Copyright Notice 💜
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 🌈.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they stand on the publication date. You can find them at http://trustee.ietf.org/license-info 🔗. Please actually read these, bestie, because they spell out your rights and restrictions 🙈.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008 🕰️. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 💀. Unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works may not be created outside it. The one exceptions are formatting it for publication as an RFC, or translating it into languages other than English 🦋.
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 ...................................251. Introduction ✨
okay so [RFC4655] is the bible for the PCE-based architecture 📖 It explains how a PCE can compute Label Switched Paths (LSPs) in MPLS-TE and GMPLS networks when a Path Computation Client (PCC) asks for one. A PCC can be basically any network component that makes that request, like a Label Switching Router (LSR) or a Network Management System (NMS). The PCE itself can live pretty much anywhere in the network 🌸 It can sit inside an LSR, an NMS or Operational Support System (OSS), or be its own independent network server.
The PCE Communication Protocol (PCEP) is the protocol PCCs and PCEs use to talk to each other, and it can also be used between PCEs that are working together 🫶 [RFC4657] lays out the generic protocol requirements for PCEP, and other application-specific requirements live in separate documents.
This document is all about a set of requirements and PCEP extensions for concurrent path computation applications 💜 A concurrent path computation is an application where a whole set of TE paths gets computed at the same time so network resources get used efficiently. The computation method here is called "global concurrent optimization" in this document. The actual algorithms that do this kind of optimization are out of scope, so we're not going there 🙈
The Global Concurrent Optimization (GCO) application is mainly an NMS or PCE-Server-based solution. GCO has really tricky synchronization issues, so the management-based PCE architecture from Section 5.5 of [RFC4655] is considered the most suitable setup for it. Other architectural options aren't banned, but they are NOT RECOMMENDED 🙅♀️ For example, GCO could be done by distributed LSRs using complicated synchronization mechanisms. But that approach could hit a lot of synchronization overhead between the PCE and each PCC, which could mess with network stability and seriously cut into the benefits of deploying PCEs. Not it 💀
Global concurrent path computation can also come up when network operators are planning which TE LSPs to set up in their network 🗺️ Operators might also need it after catastrophic network failures, when a set of TE LSPs needs to be optimally rerouted. Since this work is so heavy, it's mostly meant for off-line processing. Online use should only be considered with proven empirical validation ✨
As TE LSPs get added and removed over time, the global network resources get fragmented, and the existing placement of TE LSPs stops making the best use of available capacity 🧩 A global concurrent path computation can look at the entire network topology, the full set of existing TE LSPs, and their constraints all at once. It can try to reoptimize the whole network so every constraint for every TE LSP is satisfied. Or the application can just look at a subset of the TE LSPs and/or a subset of the topology. Also, note that other preemption can help reduce fragmentation too 💅
GCO applies to any simultaneous request for multiple TE LSPs (like a request for end-to-end protection), but global concurrent reoptimization is NOT RECOMMENDED in a network, such as an MPLS-TE network, that has a huge number of very low bandwidth or zero bandwidth TE LSPs 😭 The problem scope is massive, but the benefit of concurrent reoptimization compared to reoptimizing a single TE LSP is tiny, so it's unlikely to be worth it. Global concurrent reoptimization is also NOT RECOMMENDED in a network with a high rate of TE LSP change (churn), because the TE LSPs would likely change before they could be globally reoptimized, which is just wasted effort 🙃 Global reoptimization fits better in stable networks, like transport networks or networks with long-term TE LSP tunnels 🧁
The main focus of this document is the PCC-PCE communication needs for a concurrent path computation application, plus the protocol extensions that meet those needs 🎀
The PCC-PCE requirements in here are specific to a situation where the PCE is a specialized PCE that can do computations for GCO. Discovering those capabilities might be useful, and it could be done by extending the PCE discovery mechanisms in [RFC4674], [RFC5088], and [RFC5089]. But that's out of scope for this document 🦋
Heads up: Backward Recursive Path Computation (BRPC) [RFC5441] is a multi-PCE path computation technique used to compute a shortest constrained inter-domain path. This ID is different. It specifies a technique where a set of path computation requests gets bundled and sent to a PCE with the goal of "optimizing" the set of computed paths 🔥
2. Terminology
okay so most of the terminology in this doc is explained in [RFC4655], and a few key terms get repeated here so we're all on the same page 📝
- PCC (Path Computation Client): any client application that requests a path computation to be performed by a Path Computation Element 🙋♀️
- PCE (Path Computation Element): an entity (component, application, or network node) that can compute a network path or route based on a network graph and apply computational constraints 🧠
- TED (Traffic Engineering Database): the TED holds the topology and resource information of the domain 🗃️ It might be fed by IGP extensions or possibly by other means.
- PCECP (The PCE Communication Protocol): the generic abstract idea of a protocol used to send path computation requests from a PCC to a PCE and return computed paths from the PCE back to the PCC 🌈 PCECP can also be used between cooperating PCEs.
- PCEP (The PCE communication Protocol): the actual protocol that implements the PCECP idea 💜
- GCO (Global Concurrent Optimization): a concurrent path computation application where a set of TE paths gets computed concurrently to optimize network resources ✨ A GCO path computation can look at the entire network topology, the complete set of existing TE LSPs, and their constraints at once, then try to optimize or reoptimize the whole network so every constraint for every TE LSP is satisfied. It can also give an optimal way to migrate from an existing set of TE LSPs to a reoptimized set (the 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 📜 (these are the fancy spec words, bestie, so watch them 👀)
3. Applicability of Global Concurrent Optimization (GCO)
this section is about the PCE architecture that GCO gets applied to 🏗️ It also covers the different application scenarios where global concurrent path computation can be used, so let's get into it 🌟
3.1. Application of the PCE Architecture
Figure 1 shows the PCE-based network architecture from [RFC4655] that GCO gets applied to 🖼️ It must be observed that the PCC is not necessarily an LSR [RFC4655]. The GCO application is mainly an NMS-based solution where the NMS plays the role of the PCC 💅 Even though Figure 1 shows the PCE as remote from the NMS, it might be collocated with the NMS. If it is collocated, there's no need for a standard communication protocol, since it 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 OptimizationWait, I need to redo the figure exactly as the original, so here it is verbatim:
-----------
Application | ----- |
Request | | TED | |
| | ----- |
v | | |
------------- Request/ | v |Okay, scratch that. Here's the figure exactly as written in the original, because the diagram has to match character for character 🙏
-----------
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 OptimizationUpon receipt of an application request (for example, a traffic demand matrix that the operator's network planning procedure provides to the NMS), the NMS requests a global concurrent path computation from the PCE 📊 The PCE then computes the requested paths concurrently using some algorithms. There are lots of algorithms and computation techniques that have been proposed for this, but specifying them is outside the scope of this document 🙅♀️
When the requested path computation finishes, the PCE sends the resulting paths back to the NMS 🎉 The NMS then gives the head-end LSRs a fully computed explicit path for each TE LSP that needs to be established 🚀
3.2. Greenfield Optimization
Greenfield optimization is a special case of GCO application where there are no TE LSPs already set up in the network 🌱 Network planners need it when they want a computation server to help plan the TE LSPs that will get provisioned in the network. Greenfield is a one-time optimization 🙌 When network conditions change because of failure or other changes, the reoptimization mode of operation kicks in.
When a brand 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 even required, so the network resources get used in an optimal way and blocking gets avoided 💖
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 the available network resources. Greenfield optimization for single-layer traffic engineering can also 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 isn't limited to single-layer traffic engineering, bestie 🫣 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 at the same time when setting up a set of TE LSPs that traverse the layer boundary 🦋 iykyk, and now you do too 👑
3.3. Reoptimization of Existing Networks
okay so global concurrent path computation can totally be needed in networks that already exist 👀 like, when an existing TE LSP network starts using its resources badly, it might be time to reoptimize or reconfigure things 🔧 and the scope can vary depending on the situation 💅 sometimes it's just a bandwidth change on one existing TE LSP, but it could also be a whole set of TE LSPs that need reoptimizing at the same time 🫶 and in an extreme case, the TE LSPs may need to be globally reoptimized. full glow-up energy ✨
in loaded networks with big TE LSPs, sequential reoptimization may not give much improvement overall 😬 sequential reoptimization is when you compute the reoptimized path for one TE LSP at a time, without thinking about the other TE LSPs that also need reoptimizing in the network 🙈 how much network-wide gain you get from doing it one by one really depends on how much the network is being used and how big the TE LSPs are. but the key point is still this: doing one TE LSP at a time, ignoring all the others, could lead to sub-optimal use of network resources 💀 this is way more obvious in an optical network with a low ratio of potential TE LSPs per link, and much less noticeable in packet networks with micro-flow TE LSPs 🦋
now, about catastrophic failures, GCO could be a real benefit 🌩️ computing the paths of the TE LSPs as a set is better than having each head-end LSR come up with new paths in a distributed way. distributed jittering is a technique that can help prevent race conditions (aka when different head-end LSRs compete for the same resource) in a distributed computation 🎀 GCO offers another way to prevent race conditions too, just in a centralized manner. the tradeoff? a centralized system will typically have slower response times than a distributed one 🐢
3.3.1. Reconfiguration of the Virtual Network Topology (VNT)
reconfiguring the VNT [RFC5212] [PCE-MLN] is a classic example of when global concurrent path computation might be applicable 🌸 triggers like traffic demand changes, network failures, and topological configuration changes may mean a whole set of existing TE LSPs has to be re-computed. it's giving main character energy for GCO 👑
3.3.2. Traffic Migration
when you migrate from one set of TE LSPs to a reoptimized set, it's super important that the traffic moves without causing disruption 😭 MPLS and GMPLS have various techniques for this, like make-before-break [RFC3209], which sets up the new TE LSPs before tearing down the old ones 🧚 but when multiple TE LSP routes change based on the computed results, some of the TE LSPs may get disrupted because of resource constraints. in other words, a direct migration from the old TE LSPs to the new optimal ones could be impossible without disrupting traffic, because there aren't enough network resources to support both sets of TE LSPs when make-before-break is used 🥲 however, a PCE may be able to figure out a sequence of make-before-break replacements, one TE LSP or small sets at a time, so the full set can be migrated with zero disruption ✨ this scenario assumes the bandwidth of the existing TE LSP is kept during the migration, which is required in optical networks. in packet networks, though, this assumption can be relaxed, since the bandwidth of temporary TE LSPs during migration can be zeroed 💖
it's also possible the reoptimization is radical 😳 that could mean there's no way to apply make-before-break in any order to get from the old TE LSPs to the new ones. in that case, a migration strategy is needed, which may involve rerouting TE LSPs with make-before-break onto temporary paths to make space for the full reoptimization 🦋 a PCE might indicate the order in which the 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. or, the PCE could do the global reoptimization as a series of sub-reoptimizations, reoptimizing subsets of the total set of TE LSPs one chunk at a time 🍓
the benefit of this multi-step rerouting is minimized traffic disruption and optimization gain 🔥 but this approach may imply some transient packet desequencing, jitter, and control plane stress 😵💫
ngl, 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). so not every TE LSP gets the same treatment, bestie 💜
4. PCECP Requirements ✨
okay so this section is where we lay out what PCECP needs to support global concurrent path computation apps 🫶 These are application-specific requirements, and they're justified by the extensibility clause 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's also worth knowing that some of these requirements were already covered in the PCECP requirement document [RFC4657]. For example, Section 5.1.16 in [RFC4657] lists generic constraints, and Section 5.1.17 in [RFC4657] lists generic objective functions that MUST be supported by the PCECP 💜 So we use those generic requirements as our baseline, then add application-specific requirements for global concurrent path computation that go into more detail than the generic ones.
The PCEP SHOULD support the following capabilities, either by creating new objects and/or modifying existing objects where that makes sense.
- 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.
- 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)
- 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.)
- 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.
- 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.
- 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 at this level of detail. The following indicators SHOULD be supported at the minimum:
- 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 is where the protocol extensions for global concurrent optimization (GCO) live 🦋 They're built on top of [RFC5440].
The format of a PCReq message after adding the new requirements for GCO support looks like this. 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>The <svec-list> changes like this:
<svec-list> ::= <SVEC>
[<OF>]
[<GC>]
[<XRO>]
[<svec-list>]Note that three optional objects are added after the SVEC object: the OF (Objective Function) object, defined in [RFC5541]; the GC (Global Constraints) object, defined in this document (Section 5.5); and the eXclude Route Object (XRO), defined in [RFC5521]. The placement of the OF object (where the global objective function is specified) in the SVEC-list is defined in [RFC5541]. We'll go through the details in the following sections 🎀
Note also that when the XRO is global to an SVEC and the 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
okay so 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.5.2. Indication of Global Concurrent Optimization Requests
every path request in this application should be marked so that the global objective function and all of the global constraints get applied to each 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
so to minimize disruption during bulk path provisioning, the PCC may tell the PCE that the response MUST be ordered 👑 That means the PCE has to include the order in which TE LSPs MUST be moved so that traffic disruption is minimized. To support this, a new flag, the D flag, is defined in the RP object:
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 working out whether make-before-break optimization is required, a new flag, the M flag, is defined in the RP object:
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.
5.4. The Order Response 🎀
okay so the PCE MUST send back the order number in its PCRep whenever the PCC asks for it by setting the D-bit in the RP object of the PCReq message. 💅 to make that work there's a brand-new optional TLV called the Order TLV, and it lives inside the RP object ✨
the Order TLV is optional in the RP object. it tells you the order in which the old TE LSP must be removed and the new TE LSP must be setup during a reoptimization, and it rides along in the PCRep that answers 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. 🫶
here's what it looks like:
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: 5Length: Variable- Delete Order: a 32-bit integer that indicates the order in which the old TE LSP should be removed.
- Setup Order: a 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. Otherwise, it cannot be done in a make-before-break manner. 🔥
for a new TE LSP, the delete order isn't applicable. the value 0 is reserved to mean exactly that. when the delete order is 0, the resulting TE LSP is a new one 🧚
let's make it concrete 🍓 say there are two established TE LSPs: R1 with path P1, and R2 with path P2. during a reoptimization, the PCE might send this ordered reply:
R1, path P1', remove order 1, setup order 4
R2, path P2', remove order 3, setup order 2that means the NMS should run this sequence of tasks:
1: Remove path P1
2: Set up path P2'
3: Remove path P2
4: Set up path P1'so R1 gets reoptimized break-before-make, and R2 gets reoptimized make-before-break. iconic, honestly 👑
5.5. GLOBAL CONSTRAINTS (GC) Object ✨
the GLOBAL CONSTRAINTS (GC) Object shows up in a PCReq message. its whole job is to carry the global constraints that should be applied to every individual path computation for a global concurrent path optimization request 🌈
GLOBAL-CONSTRAINTS Object-Class is 24.
Global Constraints Object-Type is 1.
the GC object body that holds those global constraints looks like this:
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): an 8-bit integer that indicates the maximum hop count for all the TE LSPs.
- MU (Max Utilization Percentage: 8 bits): an 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): an 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): an 8-bit integer that indicates the overbooking percentage that allows the reserved bandwidth to be overbooked on each link beyond its physical capacity limit. For example, 10% means that 110 Mbps can be reserved on a 100 Mbps link. 🦋
if you want to exclude a list of nodes or links from a global path computation, include the XRO object right after the GC object in the new SVEC-list definition 🫶
optional TLVs can go inside the GC object body to specify extra global constraints. the TLV format and processing follow Section 7.1 of RFC 5440, and any TLVs get allocated from the "PCEP TLV Type Indicators" registry. just a heads up that no TLVs are defined in this document 🙈
5.6. Error Indicator 💀
to flag errors tied to a global concurrent path optimization request, there's a new Error-Type (14) with its own error-values, meant for the PCEP-ERROR Object. 🔥 wait, sorry, let me restate that properly: the document defines a new Error-Type (15) and its subsequent error-values 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).
The PCE stops processing the request. The corresponding global concurrent path optimization MUST be cancelled at the PCC.
for policy violations, 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 doesn't comply with administrative privileges (basically, the PCE policy doesn't 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 processing the request. The corresponding global concurrent path computation MUST be cancelled at the PCC. 🙅♀️
5.7. NO-PATH Indicator 🌸
to explain why a global concurrent path computation couldn't be found, the NO-PATH object can be used in the PCRep message. the NO-PATH object body format is defined in [RFC5440]. it can also contain a NO-PATH-VECTOR TLV, which gives extra info about why the path computation failed 🧚
two new bit flags are defined for 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 that 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 a PCE has to cover the following considerations:
6.1. Control of Function and Policy 🍓
on top of the parameters already listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD let you configure the following PCEP session parameters on a PCC:
- The ability to send a GCO request.
on top of the parameters already listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD let you configure the following PCEP session parameters on a PCE:
- The support for Global Concurrent Optimization.
- The maximum number of synchronized path requests per request message.
- A set of GCO specific policies (authorized sender, request rate limiter, etc.).
these parameters can be set as defaults for any PCEP session the PCEP speaker takes part in. they can also apply to one specific session with a given PCEP peer, or to 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 that they cover the GCO information introduced in this document 🌈
6.3. Liveness Detection and Monitoring 💜
the mechanisms in this document don't add any new liveness detection and monitoring requirements beyond the ones already listed in Section 8.3 of [RFC5440]. 🫶
6.4. Verifying Correct Operation ✅
the mechanisms in this document don't add any new verification requirements beyond the ones 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 the PCE-CAP-FLAGs Sub-TLV has been assigned to indicate GCO capability 👑
6.6. Impact on Network Operation 🌷
the mechanisms in this document don't add any new network operation requirements beyond the ones already listed in Section 8.6 of [RFC5440] ✨
7. Security Considerations 💀🔐
okay, this section is serious, bestie. 😭 when global reoptimization is applied to an active network, it could be extremely disruptive. the real security and policy issues live at the NMS, but if the wrong results get returned to the NMS, the wrong actions may be taken in the network. so it's super important that the operator issuing the commands has sufficient authority and is authenticated, and that the computation request is subject to appropriate policy. no skipping this part 🚨
the mechanism defined in [RFC5440] for securing a PCEP session can be used to secure global concurrent path computation requests and responses. 🔒
8. IANA Considerations 🧾
IANA maintains a registry of PCEP parameters. IANA has made allocations from the sub-registries described in the following sections 🌈
8.1. Request Parameter Bit Flags 🎀
as described in Section 5.3, two new bit flags are defined for 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]8.3. New Flag in PCE-CAP-FLAGS Sub-TLV in PCED
okay so remember Section 6.5? 🦋 That's where we made a brand new PCE-CAP-FLAGS Sub-TLV to say "hey, I can do GCO!" 💅 IANA handed us a flag from the "Path Computation Element (PCE) Capability Flags" sub-registry, which was created by Section 7.2 of RFC 5088. ngl, that one's an OSPF registry 🌸
FLAG Meaning Reference
9 Global Concurrent Optimization (GCO) [RFC5557]So flag 9 is ours, for GCO 👑 slay
8.4. New PCEP Object
As we talked about in Section 5.5, we made a new PCEP object to carry global constraints 🎀 IANA gave us an allocation from the "PCEP Objects" sub-registry, and it looks like this:
Object Name Reference
Class
24 GLOBAL-CONSTRAINTS [RFC5557]
Object-Type
1: Global Constraints [RFC5557]Class 24 with Object-Type 1 is the GLOBAL-CONSTRAINTS object 💖
8.5. New PCEP Error Codes
As we covered in Section 5.6, we added new PCEP error codes for GCO errors 🙈 IANA made allocations from the "PCEP-ERROR Object Error Types and Values" sub-registry, and the details are in the sections below.
8.5.1. New Error-Values for Existing Error-Types
Here we're adding a new error-value to an error-type that already exists. Error-Type 5 is Policy violation, and the new error-value is 5, which means Global concurrent optimization not allowed 🫶
Error-
Type Meaning Reference
5 Policy violation
Error-value=5: [RFC5557]
Global concurrent optimization not allowed8.5.2. New Error-Types and Error-Values
This one is a whole new error-type 🌈 Error-Type 15 is Global Concurrent Optimization Error, and it comes with two error-values: 1 for Insufficient memory, and 2 for Global concurrent optimization not supported.
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 gave us two bits in the "NO-PATH-VECTOR TLV Flag Field" sub-registry 🍓 These are the bit flags carried in the NO-PATH-VECTOR TLV inside the PCEP NO-PATH object, which we explained in Section 5.7. So when a GCO request can't be answered, these bits tell you why:
Bit
Number Name Reference
25 No GCO solution found [RFC5557]
26 No GCO migration path found [RFC5557]Bit 25 means no GCO solution was found, and bit 26 means no GCO migration path was found 😭
9. References
9.1. Normative References
These are the must-read refs, bestie 📚
[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.
[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
These are the nice-to-know ones 🦋
[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
Big shoutout to Jerry Ash, Adrian Farrel, J-P Vasseur, Ning So, Lucy Yong, and Fabien Verhaeghe for their useful comments and suggestions 🫶💜
Appendix A. RBNF Code Fragments
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. ✨
Redistribution and use in source and binary forms are allowed, with or without modification, as long as these conditions are met:
- Source code redistributions must keep the above copyright notice, this list of conditions, and the disclaimer below.
- Binary redistributions must reproduce the above copyright notice, this list of conditions, and the disclaimer below in the documentation and/or other materials provided with the distribution.
- You can't use the names of the Internet Society, IETF, or IETF Trust, or the names of specific contributors, to endorse or promote products derived from this software without specific prior written permission.
Now the legal part, which is serious but still 100% verbatim 🙏
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.And here's the RBNF grammar fragment, copied exactly 🧚
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
<svec-list> ::= <SVEC>
[<OF>]
[<GC>]
[<XRO>]
[<svec-list>]Authors' Addresses
Meet the authors 💅
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📦 where this page comes from
- ietf: rfc5557 2009-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms