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/rfc8051.txt | 1347 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1347 insertions(+) create mode 100644 doc/rfc/rfc8051.txt (limited to 'doc/rfc/rfc8051.txt') diff --git a/doc/rfc/rfc8051.txt b/doc/rfc/rfc8051.txt new file mode 100644 index 0000000..304d015 --- /dev/null +++ b/doc/rfc/rfc8051.txt @@ -0,0 +1,1347 @@ + + + + + + +Internet Engineering Task Force (IETF) X. Zhang, Ed. +Request for Comments: 8051 Huawei Technologies +Category: Informational I. Minei, Ed. +ISSN: 2070-1721 Google, Inc. + January 2017 + + + Applicability of a Stateful Path Computation Element (PCE) + +Abstract + + A stateful Path Computation Element (PCE) maintains information about + Label Switched Path (LSP) characteristics and resource usage within a + network in order to provide traffic-engineering calculations for its + associated Path Computation Clients (PCCs). This document describes + general considerations for a stateful PCE deployment and examines its + applicability and benefits, as well as its challenges and + limitations, through a number of use cases. PCE Communication + Protocol (PCEP) extensions required for stateful PCE usage are + covered in separate documents. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8051. + + + + + + + + + + + + + + + +Zhang & Minei Informational [Page 1] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + +Copyright Notice + + Copyright (c) 2017 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 + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Application Scenarios . . . . . . . . . . . . . . . . . . . . 5 + 3.1. Optimization of LSP Placement . . . . . . . . . . . . . . 5 + 3.1.1. Throughput Maximization and Bin Packing . . . . . . . 6 + 3.1.2. Deadlock . . . . . . . . . . . . . . . . . . . . . . 7 + 3.1.3. Minimum Perturbation . . . . . . . . . . . . . . . . 9 + 3.1.4. Predictability . . . . . . . . . . . . . . . . . . . 10 + 3.2. Auto-Bandwidth Adjustment . . . . . . . . . . . . . . . . 11 + 3.3. Bandwidth Scheduling . . . . . . . . . . . . . . . . . . 12 + 3.4. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 12 + 3.4.1. Protection . . . . . . . . . . . . . . . . . . . . . 13 + 3.4.2. Restoration . . . . . . . . . . . . . . . . . . . . . 14 + 3.4.3. SRLG Diversity . . . . . . . . . . . . . . . . . . . 15 + 3.5. Maintenance of Virtual Network Topology (VNT) . . . . . . 15 + 3.6. LSP Reoptimization . . . . . . . . . . . . . . . . . . . 16 + 3.7. Resource Defragmentation . . . . . . . . . . . . . . . . 17 + 3.8. Point-to-Multipoint Applications . . . . . . . . . . . . 17 + 3.9. Impairment-Aware Routing and Wavelength Assignment + (IA-RWA) . . . . . . . . . . . . . . . . . . . . . . . . 18 + 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 19 + 4.1. Multi-PCE Deployments . . . . . . . . . . . . . . . . . . 19 + 4.2. LSP State Synchronization . . . . . . . . . . . . . . . . 19 + 4.3. PCE Survivability . . . . . . . . . . . . . . . . . . . . 19 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 6.1. Normative References . . . . . . . . . . . . . . . . . . 20 + 6.2. Informative References . . . . . . . . . . . . . . . . . 21 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 + + + +Zhang & Minei Informational [Page 2] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + +1. Introduction + + [RFC4655] defines the architecture for a model based on the Path + Computation Element (PCE) for the computation of Multiprotocol Label + Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering + Label Switched Paths (TE LSPs). To perform such a constrained + computation, a PCE stores the network topology (i.e., TE links and + nodes) and resource information (i.e., TE attributes) in its TE + Database (TED). [RFC5440] describes the Path Computation Element + Protocol (PCEP) for interaction between a Path Computation Client + (PCC) and a PCE, or between two PCEs, enabling computation of TE + LSPs. + + As per [RFC4655], a PCE can be either stateful or stateless. A + stateful PCE maintains two sets of information for use in path + computation. The first is the Traffic Engineering Database (TED), + which includes the topology and resource state in the network. This + information can be obtained by a stateful PCE using the same + mechanisms as a stateless PCE (see [RFC4655]). The second is the LSP + State Database (LSP-DB), in which a PCE stores attributes of all + active LSPs in the network, such as their paths through the network, + bandwidth/resource usage, switching types, and LSP constraints. This + state information allows the PCE to compute constrained paths while + considering individual LSPs and their inter-dependency. However, + this requires reliable state synchronization mechanisms between the + PCE and the network, between the PCE and the PCCs, and between + cooperating PCEs, with potentially significant control-plane overhead + and maintenance of a large amount of state data, as explained in + [RFC4655]. + + This document describes how a stateful PCE can be used to solve + various problems for MPLS-TE and GMPLS networks and the benefits it + brings to such deployments. Note that alternative solutions relying + on stateless PCEs may also be possible for some of these use cases + and will be mentioned for completeness where appropriate. + + + + + + + + + + + + + + + + +Zhang & Minei Informational [Page 3] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + +2. Terminology + + This document uses the following terms defined in [RFC5440]: PCC, + PCE, and PCEP peer. + + This document defines the following terms: + + Stateful PCE: a PCE that has access to not only the network state, + but also to the set of active paths and their reserved resources + for its computations. A stateful PCE might also retain + information regarding LSPs under construction in order to reduce + churn and resource contention. The additional state allows the + PCE to compute constrained paths while considering individual LSPs + and their interactions. Note that this requires reliable state + synchronization mechanisms between the PCE and the network, PCE + and PCC, and between cooperating PCEs. + + Passive Stateful PCE: a PCE that uses LSP state information learned + from PCCs to optimize path computations. It does not actively + update LSP state. A PCC maintains synchronization with the PCE. + + Active Stateful PCE: a PCE that may issue recommendations to the + network. For example, an Active Stateful PCE may use the + Delegation mechanism to update LSP parameters in those PCCs that + delegate control over their LSPs to the PCE. + + Delegation: an operation to grant a PCE temporary rights to modify a + subset of LSP parameters on one or more LSPs of a PCC. LSPs are + delegated from a PCC to a PCE and are referred to as "delegated" + LSPs. The PCC that owns the PCE state for the LSP has the right + to delegate it. An LSP is owned by a single PCC at any given + point in time. For intra-domain LSPs, this PCC should be the LSP + head end. + + LSP State Database: information about all LSPs and their attributes. + + PCE Initiation: assuming LSP delegation granted by default, a PCE + can issue recommendations to the network. + + Minimum Cut Set: the minimum set of links for a specific source + destination pair that, when removed from the network, results in a + specific source being completely isolated from a specific + destination. The summed capacity of these links is equivalent to + the maximum capacity from the source to the destination by the + max-flow min-cut theorem. + + + + + + +Zhang & Minei Informational [Page 4] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + +3. Application Scenarios + + In the following sections, several use cases are described, + showcasing scenarios that benefit from the deployment of a stateful + PCE. + +3.1. Optimization of LSP Placement + + The following use cases demonstrate a need for visibility into global + LSP states in PCE path computations, and for a PCE control of + sequence and timing in altering LSP path characteristics within and + across PCEP sessions. Reference topologies for the use cases + described later in this section are shown in Figures 1 and 2. + + Some of the use cases below are focused on MPLS-TE deployments but + may also apply to GMPLS. Unless otherwise cited, use cases assume + that all LSPs listed exist at the same LSP priority. + + The main benefit in the cases below comes from moving away from an + asynchronous PCC-driven mode of operation to a model that allows for + central control over LSP computations and maintenance, and focuses + specifically on the active stateful PCE model of operation. + + +-----+ + | A | + +-----+ + \ + +-----+ +-----+ + | C |----------------------| E | + +-----+ +-----+ + / \ +-----+ / + +-----+ +-----| D |-----+ + | B | +-----+ + +-----+ + + Figure 1: Reference Topology 1 + + +-----+ +-----+ +-----+ + | A | | B | | C | + +--+--+ +--+--+ +--+--+ + | | | + | | | + +--+--+ +--+--+ +--+--+ + | E +--------+ F +--------+ G | + +-----+ +-----+ +-----+ + + Figure 2: Reference Topology 2 + + + + +Zhang & Minei Informational [Page 5] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + +3.1.1. Throughput Maximization and Bin Packing + + Because LSP attribute changes in [RFC5440] are driven by Path + Computation Request (PCReq) messages under control of a PCC's local + timers, the sequence of resource reservation arrivals occurring in + the network will be randomized. This, coupled with a lack of global + LSP state visibility on the part of a stateless PCE, may result in + suboptimal throughput in a given network topology, as will be shown + in the example below. + + Reference Topology 2 in Figure 2 and Tables 1 and 2 show an example + in which throughput is at 50% of optimal as a result of the lack of + visibility and synchronized control across PCCs. In this scenario, + the decision must be made as to whether to route any portion of the + E-G demand, as any demand routed for this source and destination will + decrease system throughput. + + +------+--------+----------+ + | Link | Metric | Capacity | + +------+--------+----------+ + | A-E | 1 | 10 | + | B-F | 1 | 10 | + | C-G | 1 | 10 | + | E-F | 1 | 10 | + | F-G | 1 | 10 | + +------+--------+----------+ + + Table 1: Link Parameters for Throughput Use Case + + +------+-----+-----+-----+--------+----------+-------+ + | Time | LSP | Src | Dst | Demand | Routable | Path | + +------+-----+-----+-----+--------+----------+-------+ + | 1 | 1 | E | G | 10 | Yes | E-F-G | + | 2 | 2 | A | B | 10 | No | --- | + | 3 | 1 | F | C | 10 | No | --- | + +------+-----+-----+-----+--------+----------+-------+ + + Table 2: Throughput Use Case Demand Time Series + + In many cases, throughput maximization becomes a bin-packing problem. + While bin packing itself is an NP-hard problem, a number of common + heuristics that run in polynomial time can provide significant + improvements in throughput over random reservation event + distribution, especially when traversing links that are members of + the minimum cut set for a large subset of source destination pairs. + + + + + + +Zhang & Minei Informational [Page 6] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + + Tables 3 and 4 show a simple use case using Reference Topology 1 in + Figure 1, where LSP state visibility and control of reservation order + across PCCs would result in significant improvement in total + throughput. + + +------+--------+----------+ + | Link | Metric | Capacity | + +------+--------+----------+ + | A-C | 1 | 10 | + | B-C | 1 | 10 | + | C-E | 10 | 5 | + | C-D | 1 | 10 | + | D-E | 1 | 10 | + +------+--------+----------+ + + Table 3: Link Parameters for Bin-Packing Use Case + + +------+-----+-----+-----+--------+----------+---------+ + | Time | LSP | Src | Dst | Demand | Routable | Path | + +------+-----+-----+-----+--------+----------+---------+ + | 1 | 1 | A | E | 5 | Yes | A-C-D-E | + | 2 | 2 | B | E | 10 | No | --- | + +------+-----+-----+-----+--------+----------+---------+ + + Table 4: Bin-Packing Use Case Demand Time Series + +3.1.2. Deadlock + + This section discusses the use case of cross-LSP impact under + degraded operation. Most existing RSVP-TE implementations will not + tear down established LSPs in the event of the failure of the + bandwidth increase procedure detailed in [RFC3209]. This behavior is + directly implied to be correct in [RFC3209] and is often desirable + from an operator's perspective, because either a) the destination + prefixes are not reachable via any means other than MPLS or b) this + would result in significant packet loss as demand is shifted to other + LSPs in the overlay mesh. + + In addition, there are currently few implementations offering dynamic + ingress admission control (policing of the traffic volume mapped onto + an LSP) at the Label Edge Router (LER). Having ingress admission + control on a per-LSP basis is not necessarily desirable from an + operational perspective, as a) one must over-provision tunnels + significantly in order to avoid deleterious effects resulting from + stacked transport and flow control systems (for example, for tunnels + that are dynamically resized based on current traffic) and b) there + is currently no efficient commonly available northbound interface for + dynamic configuration of per-LSP ingress admission control. + + + +Zhang & Minei Informational [Page 7] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + + Lack of ingress admission control coupled with the behavior in + [RFC3209] may result in LSPs operating out of profile for significant + periods of time. It is reasonable to expect that these out-of- + profile LSPs will be operating in a degraded state and experience + traffic loss. Moreover, because those LSPs end up sharing common + network interfaces with other LPSs operating within their bandwidth + reservations, they will impact the operation of the in-profile LSPs, + even when there is unused network capacity elsewhere in the network. + Furthermore, this behavior will cause information loss in the TED + with regards to the actual available bandwidth on the links used by + the out-of-profile LSPs, as the reservations on the links no longer + reflect the capacity used. + + Reference Topology 1 in Figure 1 and Tables 5 and 6 show a use case + that demonstrates this behavior. Two LSPs, LSP 1 and LSP 2, are + signaled with demand 2 and routed along paths A-C-D-E and B-C-D-E, + respectively. At a later time, the demand of LSP 1 increases to 20. + Under such a demand, the LSP cannot be resignaled. However, the + existing LSP will not be torn down. In the absence of ingress + policing, traffic on LSP 1 will cause degradation for traffic of LSP + 2 (due to oversubscription on the links C-D and D-E), as well as + information loss in the TED with regard to the actual network state. + + The problem could be easily ameliorated by global visibility of the + LSP state coupled with PCC-external demand measurements and placement + of two LSPs on disjoint links. Note that while the demand of 20 for + LSP 1 could never be satisfied in the given topology, isolation from + the ill-effects of the (unsatisfiable) increased demand could be + achieved. + + +------+--------+----------+ + | Link | Metric | Capacity | + +------+--------+----------+ + | A-C | 1 | 10 | + | B-C | 1 | 10 | + | C-E | 10 | 5 | + | C-D | 1 | 10 | + | D-E | 1 | 10 | + +------+--------+----------+ + + Table 5: Link Parameters for the 'Degraded Operation' Example + + + + + + + + + + +Zhang & Minei Informational [Page 8] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + + +------+-----+-----+-----+--------+----------+---------+ + | Time | LSP | Src | Dst | Demand | Routable | Path | + +------+-----+-----+-----+--------+----------+---------+ + | 1 | 1 | A | E | 2 | Yes | A-C-D-E | + | 2 | 2 | B | E | 2 | Yes | B-C-D-E | + | 3 | 1 | A | E | 20 | No | --- | + +------+-----+-----+-----+--------+----------+---------+ + + Table 6: 'Degraded Operation' Demand Time Series + +3.1.3. Minimum Perturbation + + As a result of both the lack of visibility into the global LSP state + and the lack of control over event ordering across PCE sessions, + unnecessary perturbations may be introduced into the network by a + stateless PCE. Tables 7 and 8 show an example of an unnecessary + network perturbation using Reference Topology 1 in Figure 1. In this + case, an unimportant (high LSP priority value) LSP (LSP1) is first + set up along the shortest path. At time 2, which is assumed to be + relatively close to time 1, a second more important (lower LSP- + priority value) LSP (LSP2) is established, preempting LSP1 + potentially causing traffic loss. LSP1 is then reestablished on the + longer A-C-E path. + + +------+--------+----------+ + | Link | Metric | Capacity | + +------+--------+----------+ + | A-C | 1 | 10 | + | B-C | 1 | 10 | + | C-E | 10 | 10 | + | C-D | 1 | 10 | + | D-E | 1 | 10 | + +------+--------+----------+ + + Table 7: Link Parameters for the 'Minimum-Perturbation' Example + + +------+-----+-----+-----+--------+----------+----------+---------+ + | Time | LSP | Src | Dst | Demand | LSP Prio | Routable | Path | + +------+-----+-----+-----+--------+----------+----------+---------+ + | 1 | 1 | A | E | 7 | 7 | Yes | A-C-D-E | + | 2 | 2 | B | E | 7 | 0 | Yes | B-C-D-E | + | 3 | 1 | A | E | 7 | 7 | Yes | A-C-E | + +------+-----+-----+-----+--------+----------+----------+---------+ + + Table 8: 'Minimum-Perturbation' LSP and Demand Time Series + + + + + + +Zhang & Minei Informational [Page 9] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + + A stateful PCE can help in this scenario by computing both routes at + the same time. The advantages of using a stateful PCE over + exploiting a stateless PCE via Global Concurrent Optimization (GCO) + are threefold. First is the ability to accommodate concurrent path + computation from different PCCs. Second is the reduction of control- + plane overhead since the stateful PCE has the route information of + the affected LSPs. Thirdly, the stateful PCE can use the LSP-DB to + further optimize the placement of LSPs. This will ensure placement + of the more important LSP along the shortest path, avoiding the setup + and subsequent preemption of the lower priority LSP. Similarly, when + a new higher priority LSP that requires preemption of an existing + lower priority LSP(s), a stateful PCE can determine the minimum + number of lower priority LSPs to reroute using the Make-Before-Break + (MBB) mechanism without disrupting any service and then set up the + higher priority LSP. + +3.1.4. Predictability + + Randomization of reservation events caused by lack of control over + event ordering across PCE sessions results in poor predictability in + LSP routing. An offline system applying a consistent optimization + method will produce predictable results to within either the boundary + of forecast error (when reservations are over-provisioned by + reasonable margins) or to the variability of the signal and the + forecast error (when applying some hysteresis in order to minimize + churn). Predictable results are valuable for being able to simulate + the network and reliably test it under various scenarios, especially + under various failure modes and planned maintenances when predictable + path characteristics are desired under contention for network + resources. + + Reference Topology 1 and Tables 9, 10, and 11 show the impact of + event ordering and predictability of LSP routing. + + +------+--------+----------+ + | Link | Metric | Capacity | + +------+--------+----------+ + | A-C | 1 | 10 | + | B-C | 1 | 10 | + | C-E | 1 | 10 | + | C-D | 1 | 10 | + | D-E | 1 | 10 | + +------+--------+----------+ + + Table 9: Link Parameters for the 'Predictability' Example + + + + + + +Zhang & Minei Informational [Page 10] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + + +------+-----+-----+-----+--------+----------+---------+ + | Time | LSP | Src | Dst | Demand | Routable | Path | + +------+-----+-----+-----+--------+----------+---------+ + | 1 | 1 | A | E | 7 | Yes | A-C-E | + | 2 | 2 | B | E | 7 | Yes | B-C-D-E | + +------+-----+-----+-----+--------+----------+---------+ + + Table 10: 'Predictability' LSP and Demand Time Series 1 + + +------+-----+-----+-----+--------+----------+---------+ + | Time | LSP | Src | Dst | Demand | Routable | Path | + +------+-----+-----+-----+--------+----------+---------+ + | 1 | 2 | B | E | 7 | Yes | B-C-E | + | 2 | 1 | A | E | 7 | Yes | A-C-D-E | + +------+-----+-----+-----+--------+----------+---------+ + + Table 11: 'Predictability' LSP and Demand Time Series 2 + + As can be shown in the example, both LSPs are routed in both cases, + but along very different paths. This would be a challenge if + reliable simulation of the network is attempted. An active stateful + PCE can solve this through control over LSP ordering. Based on + triggers such as a failure or an optimization trigger, the PCE can + order the computations and path setup in a deterministic way. + +3.2. Auto-Bandwidth Adjustment + + The bandwidth requirements of LSPs often change over time, requiring + LSP resizing. In most implementations available today, the head-end + node performs this function by monitoring the actual bandwidth usage, + triggering a recomputation and resignaling when a threshold is + reached. This operation is referred to as "auto-bandwidth + adjustment". The head-end node either recomputes the path locally, + or it requests a recomputation from a PCE by sending a PCReq message. + In the latter case, the PCE computes a new path and provides the new + route suggestion. Upon receiving the reply from the PCE, the PCC + resignals the LSP in Shared-Explicit (SE) mode along the newly + computed path. With a stateless PCE, the head-end node needs to + provide the currently used bandwidth and the route information via + path computation request messages. Note that in this scenario, the + head-end node is the one that drives the LSP resizing based on local + information, and that the difference between using a stateless and a + passive stateful PCE is in the level of optimization of the LSP + placement as discussed in the previous section. + + A more interesting smart bandwidth adjustment case is one where the + LSP resizing decision is done by an external entity with access to + additional information such as historical trending data, application- + + + +Zhang & Minei Informational [Page 11] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + + specific information about expected demands or policy information, as + well as knowledge of the actual desired flow volumes. In this case, + an active stateful PCE provides an advantage in both the computation + with knowledge of all LSPs in the domain and in the ability to + trigger bandwidth modification of the LSP. + +3.3. Bandwidth Scheduling + + Bandwidth scheduling allows network operators to reserve resources in + advance according to the agreements with their customers and allows + them to transmit data with a specified starting time and duration, + for example, for a scheduled bulk data replication between data + centers. + + Traditionally, this can be supported by Network Management System + (NMS) operation through path pre-establishment and activation on the + agreed starting time. However, this does not provide efficient + network usage since the established paths exclude the possibility of + being used by other services even when they are not used for + undertaking any service. It can also be accomplished through GMPLS + protocol extensions by carrying the related request information + (e.g., starting time and duration) across the network. Nevertheless, + this method inevitably increases the complexity of the signaling and + routing process. + + A passive stateful PCE can support this application with better + efficiency since it can alleviate the burden of processing on network + elements. This requires the PCE to maintain the scheduled LSPs and + their associated resource usage, as well as the ability of head-ends + to trigger signaling for LSP setup/deletion at the correct time. + This approach requires coarse time synchronization between PCEs and + PCCs. With PCE initiation capability, a PCE can trigger the setup + and deletion of scheduled requests in a centralized manner, without + modification of existing head-end behaviors, by notifying the PCCs to + set up or tear down the paths. + +3.4. Recovery + + The recovery use cases discussed in the following sections show how + leveraging a stateful PCE can simplify the computation of recovery + path(s). In particular, two characteristics of a stateful PCE are + used: 1) using information stored in the LSP-DB for determining + shared protection resources and 2) performing computations with + knowledge of all LSPs in a domain. + + + + + + + +Zhang & Minei Informational [Page 12] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + +3.4.1. Protection + + If a PCC can specify in a request whether the computation is for a + working path or for protection and a PCC can report the resource as a + working or protection path, then the following text applies. A PCC + can send multiple requests to the PCE, asking for two LSPs, and use + them as working and backup paths separately. Either way, the + resources bound to backup paths can be shared by different LSPs to + improve the overall network efficiency, such as m:n protection or + pre-configured shared mesh recovery techniques as specified in + [RFC4427]. If resource sharing is supported for LSP protection, the + information relating to existing LSPs is required to avoid allocation + of shared protection resources to two LSPs that might fail together + and cause protection contention issues. A stateless PCE can + accommodate this use case by having the PCC pass this information as + a constraint in the path computation request. A passive stateful PCE + can more easily accommodate this need using the information stored in + its LSP-DB. Furthermore, an active stateful PCE can help with + (re)optimization of protection resource sharing as well as LSP + maintenance operation with less impact on protection resources. + + +----+ + |PCE | + +----+ + + +------+ +------+ +------+ + | A +----------+ B +----------+ C | + +--+---+ +---+--+ +---+--+ + | | | + | +---------+ | + | | | + | +--+---+ +------+ | + +-----+ E +----------+ D +-----+ + +------+ +------+ + + Figure 3: Reference Topology 3 + + For example, in the network depicted in Figure 3, suppose there + exists LSP1 with working path LSP1_working following A->E and with + backup path LSP1_backup following A->B->E. A request arrives asking + for a working and backup path pair to be computed for LSP2 from B to + E. If the PCE decides LSP2_working follows B->A->E, then the backup + path LSP2_backup should not share the same protection resource with + LSP1 since LSP2 shares part of its resource (specifically A->E) with + LSP1 (i.e., these two LSPs are in the same shared risk group). There + is no such constraint if B->C->D->E is chosen for LSP2_working. + + + + + +Zhang & Minei Informational [Page 13] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + + If a stateless PCE is used, the head node B needs to be aware of the + existence of LSPs that share the route of LSP2_working and of the + details of their protection resources. B must pass this information + to the PCE as a constraint so as to request a path with diversity. + Alternatively, a stateless PCE may be able to compute paths + diversified by SRLG (Shared Risk Link Group) if TED is extended so + that it includes the SRLG information that is protected by a given + backup resource, but at the expense of a high complexity in routing. + On the other hand, a stateful PCE can get the LSPs information by + itself given the LSP identifier(s) and can then find SRLG-diversified + protection paths for both LSPs. This is made possible by comparing + the LSP resource usage exploiting the LSP-DB accessible by the + stateful PCE. + +3.4.2. Restoration + + In case of a link failure, such as a fiber cut, multiple LSPs may + fail at the same time. Thus, the source nodes of the affected LSPs + will be informed of the failure by the nodes detecting the failure. + These source nodes will send requests to a PCE for rerouting. In + order to reuse the resource taken by an existing LSP, the source node + can send a PCReq message that includes the Exclude Route Object (XRO) + with Fail (F) bit set together with the Record Route Object (RRO) + that contains the current route information, as specified in + [RFC5521]. + + If a stateless PCE is used, it might respond to the rerouting + requests separately if the requests arrive at different times. Thus, + it might result in suboptimal resource usage. Even worse, it might + unnecessarily block some of the rerouting requests due to + insufficient resources for rerouting messages that arrive later. If + a passive stateful PCE is used to fulfill this task, the procedure + can be simplified. The PCCs reporting the failures can include LSP + identifiers instead of detailed information, and the PCE can find + relevant LSP information by inspecting the LSP-DB. Moreover, the PCE + can recompute the affected LSPs concurrently while reusing part of + the existing LSP's resources when it is informed of the failed link + identifier provided by the first request. This is made possible + because the passive stateful PCE can check what other LSPs are + affected by the failed link and their route information by inspecting + its LSP-DB. As a result, a better performance can be achieved, such + as better resource usage or minimal probability of blocking upcoming + new rerouting requests sent as a result of the link failure. + + If the target is to avoid resource contention within the time window + of a high number of LSP rerouting requests, a stateful PCE can retain + the under-construction LSP resource usage information for a given + time and exclude it from being used for a forthcoming LSP's request. + + + +Zhang & Minei Informational [Page 14] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + + In this way, it can ensure that the resource will not be double- + booked; thus, the issue of resource contention and computation crank- + backs can be alleviated. + +3.4.3. SRLG Diversity + + An alternative way to achieve efficient resilience is to maintain + SRLG disjointness between LSPs, irrespective of whether or not these + LSPs share the source and destination nodes. This can be achieved at + provisioning time, if the routes of all the LSPs are requested + together, using a synchronized computation of the different LSPs with + SRLG disjointness constraint. If the LSPs need to be provisioned at + different times, the PCC can specify, as constraints to the path + computation, a set of SRLGs using the Exclude Route Object [RFC5521]. + However, for the latter to be effective, the entity that requests the + route to the PCE needs to maintain updated SRLG information regarding + all of the LSPs to which it must maintain the disjointness. A + stateless PCE can compute an SRLG-disjoint path by inspecting the TED + and precluding the links with the same SRLG values specified in the + PCReq message sent by a PCC. + + A passive stateful PCE maintains the updated SRLG information of the + established LSPs in a centralized manner. Therefore, the PCC can + specify, as constraints to the path computation, the SRLG + disjointness of a set of already established LSPs by only providing + the LSP identifiers. Similarly, a passive stateful PCE can also + accommodate disjointness using other constraints, such as link, node, + or path segment. + +3.5. Maintenance of Virtual Network Topology (VNT) + + In Multi-Layer Networks (MLN), a Virtual Network Topology (VNT) + [RFC5212] consists of a set of one or more TE LSPs in the lower + layer, which provides TE links to the upper layer. In [RFC5623], the + PCE-based architecture is proposed to support path computation in MLN + networks in order to achieve inter-layer TE. + + The establishment/teardown of a TE link in VNT needs to take into + consideration the state of existing LSPs and/or new LSP request(s) in + the higher layer. Hence, when a stateless PCE cannot find the route + for a request based on the upper-layer topology information, it does + not have enough information to decide whether or not to set up or + remove a TE link, which then can result in non-optimal usage of a + resource. On the other hand, a passive stateful PCE can make a + better decision of when and how to modify the VNT either to + accommodate new LSP requests or to reoptimize resource usage across + layers irrespective of the PCE models as described in [RFC5623]. + Furthermore, given the active capability, the stateful PCE can issue + + + +Zhang & Minei Informational [Page 15] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + + VNT modification suggestions in order to accommodate path setup + requests or reoptimize resource usage across layers. + +3.6. LSP Reoptimization + + In order to make efficient usage of network resources, it is + sometimes desirable to reoptimize one or more LSPs dynamically. In + the case of a stateless PCE, in order to optimize network resource + usage dynamically through online planning, a PCC must send a request + to the PCE together with detailed path/bandwidth information of the + LSPs that need to be concurrently optimized. This means that the PCC + must be able to determine when and which LSPs should be optimized. + In the case of a passive stateful PCE, given the LSP state + information in the LSP database, the process of dynamic optimization + of network resources can be simplified without requiring the PCC to + supply detailed LSP state information. Moreover, an active stateful + PCE can even make the process automated by triggering the request. + Because a stateful PCE can maintain information for all LSPs that are + in the process of being set up and it may have the ability to control + timing and sequence of LSP setup/deletion, the optimization + procedures can be performed more intelligently and effectively. A + stateful PCE can also determine which LSP should be reoptimized based + on network events. For example, when an LSP is torn down, its + resources are freed. This can trigger the stateful PCE to + automatically determine which LSP should be reoptimized so that the + recently freed resources may be allocated to it. + + A special case of LSP reoptimization is GCO [RFC5557]. Global + control of the LSP operation sequence in [RFC5557] is predicated on + the use of what is effectively a stateful (or semi-stateful) NMS. + The NMS can be either not local to the network nodes, in which case + another northbound interface is required for LSP attribute changes, + or local/collocated, in which case there are significant issues with + efficiency in resource usage. A stateful PCE adds a few features + that: + + o Roll the NMS visibility into the PCE and remove the requirement + for an additional northbound interface. + + o Allow the PCE to determine when reoptimization is needed, with + which level (GCO or a more incremental optimization). + + o Allow the PCE to determine which LSPs should be reoptimized. + + o Allow a PCE to control the sequence of events across multiple + PCCs, allowing for bulk (and truly global) optimization, LSP + shuffling, etc. + + + + +Zhang & Minei Informational [Page 16] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + +3.7. Resource Defragmentation + + If LSPs are dynamically allocated and released over time, the + resource becomes fragmented. In networks with link bundle, the + overall available resource on a (bundle) link might be sufficient for + a new LSP request, but if the available resource is not continuous, + the request is rejected. Stateful PCEs can be used to perform the + defragmentation procedure, because global visibility of LSPs in the + network is required to accurately assess resources on the LSPs and to + perform defragmentation while ensuring a minimal disruption of the + network. This use case cannot be accommodated by a stateless PCE + because it does not possess the detailed information of existing LSPs + in the network. + + Another case of particular interest is the optical spectrum + defragmentation in flexible-grid networks. In flexible-grid networks + [RFC7698], LSPs with different optical spectrum sizes (such as + 12.5GHz, 25GHz, etc.) can coexist so as to accommodate the services + with different bandwidth requests. Therefore, even if the overall + spectrum size can meet the service request, it may not be usable if + the available spectrum resource is not contiguous, but rather + fragmented into smaller pieces. Thus, with the help of existing LSP + state information, a stateful PCE can make the resource grouped + together to be usable. Moreover, a stateful PCE can proactively + choose routes for upcoming path requests to reduce the chance of + spectrum fragmentation. + +3.8. Point-to-Multipoint Applications + + PCE has been identified as an appropriate technology for the + determination of the paths of Point-to-Multipoint (P2MP) TE LSPs + [RFC5671]. The application scenarios and use cases described in + Sections 3.1, 3.4, and 3.6 are also applicable to P2MP TE LSPs. + + In addition to these, the stateful nature of a PCE simplifies the + information conveyed in PCEP messages since it is possible to refer + to the LSPs via an identifier. For P2MP, this is an added advantage + where the size of the PCEP message is much larger. In case of + stateless PCEs, modification of a P2MP tree requires encoding of all + leaves along with the paths in a PCReq message. But by using a + stateful PCE with P2MP capability, the PCEP message can be used to + convey only the modifications (the other information can be retrieved + from the identifier via the LSP-DB). + + + + + + + + +Zhang & Minei Informational [Page 17] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + +3.9. Impairment-Aware Routing and Wavelength Assignment (IA-RWA) + + In Wavelength Switched Optical Networks (WSONs) [RFC6163], a + wavelength-switched LSP traverses one or more fiber links. The bit + rates of the client signals carried by the wavelength LSPs may be the + same or different. Hence, a fiber link may transmit a number of + wavelength LSPs with equal or mixed bit-rate signals. For example, a + fiber link may multiplex the wavelengths with only 10 Gbit/s signals, + mixed 10 Gbit/s and 40 Gbit/s signals, or mixed 40 Gbit/s and 100 + Gbit/s signals. + + IA-RWA in WSONs refers to the process (i.e., lightpath computation) + that takes into account the optical layer/transmission imperfections + as additional (i.e., physical layer) constraints. To be more + specific, linear and non-linear effects associated with the optical + network elements should be incorporated into the route and wavelength + assignment procedure. For example, the physical imperfection can + result in the interference of two adjacent lightpaths. Thus, a guard + band should be reserved between them to alleviate these effects. The + width of the guard band between two adjacent wavelengths depends on + their characteristics, such as modulation formats and bit rates. Two + adjacent wavelengths with different characteristics (e.g., different + bit rates) may need a wider guard band and those with the same + characteristics may need a narrower guard band. For example, 50 GHz + spacing may be acceptable for two adjacent wavelengths with 40 G + signals. But for two adjacent wavelengths with different bit rates + (e.g., 10 G and 40 G), a larger spacing such as 300 GHz may be + needed. Hence, the characteristics (states) of the existing + wavelength LSPs should be considered for a new RWA request in WSON. + + In summary, when stateful PCEs are used to perform the IA-RWA + procedure, they need to know the characteristics of the existing + wavelength LSPs. The impairment information relating to existing and + to-be-established LSPs can be obtained by nodes in WSON networks via + external configuration or other means such as monitoring or + estimation based on a vendor-specific impair model. However, WSON- + related routing protocols, i.e., [RFC7688] and [RFC7580], only + advertise limited information (i.e., availability) of the existing + wavelengths, without defining the supported client bit rates. It + will incur a substantial amount of control-plane overhead if routing + protocols are extended to support dissemination of the new + information relevant for the IA-RWA process. In this scenario, + stateful PCE(s) would be a more appropriate mechanism to solve this + problem. Stateful PCE(s) can exploit impairment information of LSPs + stored in LSP-DB to provide accurate RWA calculation. + + + + + + +Zhang & Minei Informational [Page 18] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + +4. Deployment Considerations + + This section discusses general issues with stateful PCE deployments + and identifies areas where additional protocol extensions and + procedures are needed to address them. Definitions of protocol + mechanisms are beyond the scope of this document. + +4.1. Multi-PCE Deployments + + Stateless and stateful PCEs can coexist in the same network and be in + charge of path computation of different types. To solve the problem + of distinguishing between the two types of PCEs, either discovery or + configuration may be used. + + Multiple stateful PCEs can coexist in the same network. These PCEs + may provide redundancy for load sharing, resilience, or partitioning + of computation features. Regardless of the reason for multiple PCEs, + an LSP is only delegated to one of the PCEs at any given point in + time. However, an LSP can be redelegated between PCEs, for example, + when a PCE fails. [RFC7399] discusses various approaches for + synchronizing state among the PCEs when multiple PCEs are used for + load sharing or backup and compute LSPs for the same network. + +4.2. LSP State Synchronization + + The LSP-DB is populated using information received from the PCC. + Because the accuracy of the computations depends on the accuracy of + the databases used and because the updates must reach the PCE from + the network, it is worth noting that the PCE view lags behind the + true state of the network. Thus, the use of stateful PCE reduces but + cannot eliminate the possibility of crankbacks, nor can it guarantee + optimal computations all the time. [RFC7399] discusses these + limitations and potential ways to alleviate them. + + In case of multiple PCEs with different capabilities coexisting in + the same network, such as a passive stateful PCE and an active + stateful PCE, it is useful to refer to an LSP, be it delegated or + not, by a unique identifier instead of providing detailed information + (e.g., route, bandwidth) associated with it, when these PCEs + cooperate on path computation, such as for load sharing. + +4.3. PCE Survivability + + For a stateful PCE, an important issue is to get the LSP state + information resynchronized after a restart. LSP state + synchronization procedures can be applied equally to a network node + or another PCE, allowing multiple ways to reacquire the LSP database + on a restart. Because synchronization may also be skipped, if a PCE + + + +Zhang & Minei Informational [Page 19] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + + implementation has the means to retrieve its database in a different + way (for example, from a backup copy stored locally), the state can + be restored without further overhead in the network. A hybrid + approach where the bulk of the state is recovered locally, and a + small amount of state is reacquired from the network, is also + possible. Note that locally recovering the state would still require + some degree of resynchronization to ensure that the recovered state + is indeed up-to-date. Depending on the resynchronization mechanism + used, there may be an additional load on the PCE, and there may be a + delay in reaching the synchronized state, which may negatively affect + survivability. Different resynchronization methods are suited for + different deployments and objectives. + +5. Security Considerations + + This document describes general considerations for a stateful PCE + deployment and examines its applicability and benefits, as well as + its challenges and limitations through a number of use cases. No new + protocol extensions to PCEP are defined in this document. + + The PCEP extensions in support of the stateful PCE and the delegation + of path control ability can result in more information and control + being available for a hypothetical adversary and a number of + additional attack surfaces that must be protected. This includes, + but is not limited to, the authentication and encryption of PCEP + sessions, snooping of the state of the LSPs active in the network, + etc. Therefore, documents in which the PCEP protocol extensions are + defined need to consider the issues and risks associated with a + stateful PCE. + +6. References + +6.1. Normative References + + [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation + Element (PCE)-Based Architecture", RFC 4655, + DOI 10.17487/RFC4655, August 2006, + . + + [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation + Element (PCE) Communication Protocol (PCEP)", RFC 5440, + DOI 10.17487/RFC5440, March 2009, + . + + [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path + Computation Element Architecture", RFC 7399, + DOI 10.17487/RFC7399, October 2014, + . + + + +Zhang & Minei Informational [Page 20] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + +6.2. Informative References + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., + and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP + Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, + . + + [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery + (Protection and Restoration) Terminology for Generalized + Multi-Protocol Label Switching (GMPLS)", RFC 4427, + DOI 10.17487/RFC4427, March 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, + DOI 10.17487/RFC5212, July 2008, + . + + [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the + Path Computation Element Communication Protocol (PCEP) for + Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April + 2009, . + + [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path + Computation Element Communication Protocol (PCEP) + Requirements and Protocol Extensions in Support of Global + Concurrent Optimization", RFC 5557, DOI 10.17487/RFC5557, + July 2009, . + + [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, + "Framework for PCE-Based Inter-Layer MPLS and GMPLS + Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, + September 2009, . + + [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the + Path Computation Element (PCE) to Point-to-Multipoint + (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, + DOI 10.17487/RFC5671, October 2009, + . + + [RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, + "Framework for GMPLS and Path Computation Element (PCE) + Control of Wavelength Switched Optical Networks (WSONs)", + RFC 6163, DOI 10.17487/RFC6163, April 2011, + . + + + + + +Zhang & Minei Informational [Page 21] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + + [RFC7580] Zhang, F., Lee, Y., Han, J., Bernstein, G., and Y. Xu, + "OSPF-TE Extensions for General Network Element + Constraints", RFC 7580, DOI 10.17487/RFC7580, June 2015, + . + + [RFC7688] Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF + Enhancement for Signal and Network Element Compatibility + for Wavelength Switched Optical Networks", RFC 7688, + DOI 10.17487/RFC7688, November 2015, + . + + [RFC7698] Gonzalez de Dios, O., Ed., Casellas, R., Ed., Zhang, F., + Fu, X., Ceccarelli, D., and I. Hussain, "Framework and + Requirements for GMPLS-Based Control of Flexi-Grid Dense + Wavelength Division Multiplexing (DWDM) Networks", + RFC 7698, DOI 10.17487/RFC7698, November 2015, + . + +Acknowledgements + + We would like to thank Cyril Margaria, Adrian Farrel, JP Vasseur, and + Ravi Torvi for the useful comments and discussions. + +Contributors + + The following people all contributed significantly to this document + and are listed below in alphabetical order: + + Ramon Casellas + CTTC - Centre Tecnologic de Telecomunicacions de Catalunya + Av. Carl Friedrich Gauss n7 + Castelldefels, Barcelona 08860 + Spain + Email: ramon.casellas@cttc.es + + Edward Crabbe + Email: edward.crabbe@gmail.com + + Dhruv Dhody + Huawei Technology + Leela Palace + Bangalore, Karnataka 560008 + India + Email: dhruv.dhody@huawei.com + + + + + + + +Zhang & Minei Informational [Page 22] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + + Oscar Gonzalez de Dios + Telefonica Investigacion y Desarrollo + Emilio Vargas 6 + Madrid, 28045 + Spain + Phone: +34 913374013 + Email: ogondio@tid.es + + Young Lee + Huawei + 1700 Alma Drive, Suite 100 + Plano, TX 75075 + United States of America + Phone: +1 972 509 5599 x2240 + Fax: +1 469 229 5397 + Email: leeyoung@huawei.com + + Jan Medved + Cisco Systems, Inc. + 170 West Tasman Dr. + San Jose, CA 95134 + United States of America + Email: jmedved@cisco.com + + Robert Varga + Pantheon Technologies LLC + Mlynske Nivy 56 + Bratislava 821 05 + Slovakia + Email: robert.varga@pantheon.sk + + Fatai Zhang + Huawei Technologies + F3-5-B R&D Center, Huawei Base + Bantian, Longgang District + Shenzhen 518129 + China + Phone: +86-755-28972912 + Email: zhangfatai@huawei.com + + Xiaobing Zi + + + + + + + + + + +Zhang & Minei Informational [Page 23] + +RFC 8051 Applicability for a Stateful PCE January 2017 + + +Authors' Addresses + + Xian Zhang (editor) + Huawei Technologies + F3-5-B R&D Center + Huawei Industrial Base + Bantian, Longgang District + Shenzhen, Guangdong 518129 + China + + Email: zhang.xian@huawei.com + + + Ina Minei (editor) + Google, Inc. + 1600 Amphitheatre Parkway + Mountain View, CA 94043 + United States of America + + Email: inaminei@google.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhang & Minei Informational [Page 24] + -- cgit v1.2.3