draft-ietf-pce-stateful-pce-app-07.txt   draft-ietf-pce-stateful-pce-app-08.txt 
PCE Working Group X. Zhang, Ed. PCE Working Group X. Zhang, Ed.
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational I. Minei, Ed. Intended status: Informational I. Minei, Ed.
Expires: April 1, 2017 Google, Inc. Expires: May 4, 2017 Google, Inc.
September 28, 2016 October 31, 2016
Applicability of a Stateful Path Computation Element (PCE) Applicability of a Stateful Path Computation Element (PCE)
draft-ietf-pce-stateful-pce-app-07 draft-ietf-pce-stateful-pce-app-08
Abstract Abstract
A stateful Path Computation Element (PCE) maintains information about A stateful Path Computation Element (PCE) maintains information about
Label Switched Path (LSP) characteristics and resource usage within a Label Switched Path (LSP) characteristics and resource usage within a
network in order to provide traffic engineering calculations for its network in order to provide traffic engineering calculations for its
associated Path Computation Clients (PCCs). This document describes associated Path Computation Clients (PCCs). This document describes
general considerations for a stateful PCE deployment and examines its general considerations for a stateful PCE deployment and examines its
applicability and benefits, as well as its challenges and limitations applicability and benefits, as well as its challenges and limitations
through a number of use cases. PCE Communication Protocol (PCEP) through a number of use cases. PCE Communication Protocol (PCEP)
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 1, 2017. This Internet-Draft will expire on May 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of the Stateful PCE Protocol Extensions . . . . . . 4 3. Application Scenarios . . . . . . . . . . . . . . . . . . . . 4
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 3.1. Optimization of LSP Placement . . . . . . . . . . . . . . 4
4.1. Multi-PCE Deployments . . . . . . . . . . . . . . . . . . 5 3.1.1. Throughput Maximization and Bin Packing . . . . . . . 5
4.2. LSP State Synchronization . . . . . . . . . . . . . . . . 5 3.1.2. Deadlock . . . . . . . . . . . . . . . . . . . . . . 7
4.3. PCE Survivability . . . . . . . . . . . . . . . . . . . . 6 3.1.3. Minimum Perturbation . . . . . . . . . . . . . . . . 8
5. Application Scenarios . . . . . . . . . . . . . . . . . . . . 6 3.1.4. Predictability . . . . . . . . . . . . . . . . . . . 9
5.1. Optimization of LSP Placement . . . . . . . . . . . . . . 6 3.2. Auto-bandwidth Adjustment . . . . . . . . . . . . . . . . 11
5.1.1. Throughput Maximization and Bin Packing . . . . . . . 7 3.3. Bandwidth Scheduling . . . . . . . . . . . . . . . . . . 11
5.1.2. Deadlock . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1.3. Minimum Perturbation . . . . . . . . . . . . . . . . 11 3.4.1. Protection . . . . . . . . . . . . . . . . . . . . . 12
5.1.4. Predictability . . . . . . . . . . . . . . . . . . . 12 3.4.2. Restoration . . . . . . . . . . . . . . . . . . . . . 13
5.2. Auto-bandwidth Adjustment . . . . . . . . . . . . . . . . 13 3.4.3. SRLG Diversity . . . . . . . . . . . . . . . . . . . 14
5.3. Bandwidth Scheduling . . . . . . . . . . . . . . . . . . 14 3.5. Maintenance of Virtual Network Topology (VNT) . . . . . . 15
5.4. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 14 3.6. LSP Re-optimization . . . . . . . . . . . . . . . . . . . 15
5.4.1. Protection . . . . . . . . . . . . . . . . . . . . . 14 3.7. Resource Defragmentation . . . . . . . . . . . . . . . . 16
5.4.2. Restoration . . . . . . . . . . . . . . . . . . . . . 16 3.8. Point-to-Multi-Point Applications . . . . . . . . . . . . 17
5.4.3. SRLG Diversity . . . . . . . . . . . . . . . . . . . 16 3.9. Impairment-Aware Routing and Wavelength Assignment (IA-
5.5. Maintenance of Virtual Network Topology (VNT) . . . . . . 17 RWA) . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.6. LSP Re-optimization . . . . . . . . . . . . . . . . . . . 17 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 18
5.7. Resource Defragmentation . . . . . . . . . . . . . . . . 18 4.1. Multi-PCE Deployments . . . . . . . . . . . . . . . . . . 18
5.8. Point-to-Multi-Point Applications . . . . . . . . . . . . 19 4.2. LSP State Synchronization . . . . . . . . . . . . . . . . 19
5.9. Impairment-Aware Routing and Wavelength Assignment (IA- 4.3. PCE Survivability . . . . . . . . . . . . . . . . . . . . 19
RWA) . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 20
8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
[RFC4655] defines the architecture for a Path Computation Element [RFC4655] defines the architecture for a Path Computation Element
(PCE)-based model for the computation of Multiprotocol Label (PCE)-based model for the computation of Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
Label Switched Paths (TE LSPs). To perform such a constrained Label Switched Paths (TE LSPs). To perform such a constrained
computation, a PCE stores the network topology (i.e., TE links and computation, a PCE stores the network topology (i.e., TE links and
nodes) and resource information (i.e., TE attributes) in its TE nodes) and resource information (i.e., TE attributes) in its TE
Database (TED). [RFC5440] describes the Path Computation Element Database (TED). [RFC5440] describes the Path Computation Element
Protocol (PCEP) for interaction between a Path Computation Client Protocol (PCEP) for interaction between a Path Computation Client
(PCC) and a PCE, or between two PCEs, enabling computation of TE (PCC) and a PCE, or between two PCEs, enabling computation of TE
LSPs. Extensions for support of GMPLS in PCEP are defined in LSPs.
[I-D.ietf-pce-gmpls-pcep-extensions].
As per [RFC4655], a PCE can be either stateful or stateless. A As per [RFC4655], a PCE can be either stateful or stateless. A
stateful PCE maintains two sets of information for use in path stateful PCE maintains two sets of information for use in path
computation. The first is the Traffic Engineering Database (TED) computation. The first is the Traffic Engineering Database (TED)
which includes the topology and resource state in the network. This which includes the topology and resource state in the network. This
information can be obtained by a stateful PCE using the same information can be obtained by a stateful PCE using the same
mechanisms as a stateless PCE (see [RFC4655]). The second is the LSP mechanisms as a stateless PCE (see [RFC4655]). The second is the LSP
State Database (LSP-DB), in which a PCE stores attributes of all State Database (LSP-DB), in which a PCE stores attributes of all
active LSPs in the network, such as their paths through the network, active LSPs in the network, such as their paths through the network,
bandwidth/resource usage, switching types and LSP constraints. This bandwidth/resource usage, switching types and LSP constraints. This
skipping to change at page 3, line 40 skipping to change at page 3, line 38
various problems for MPLS-TE and GMPLS networks, and the benefits it various problems for MPLS-TE and GMPLS networks, and the benefits it
brings to such deployments. Note that alternative solutions relying brings to such deployments. Note that alternative solutions relying
on stateless PCEs may also be possible for some of these use cases, on stateless PCEs may also be possible for some of these use cases,
and will be mentioned for completeness where appropriate. and will be mentioned for completeness where appropriate.
2. Terminology 2. Terminology
This document uses the following terms defined in [RFC5440]: PCC, This document uses the following terms defined in [RFC5440]: PCC,
PCE, PCEP peer. PCE, PCEP peer.
This document uses the following terms defined in This document defines the following terms:
[I-D.ietf-pce-stateful-pce]: Passive Stateful PCE, Active Stateful
PCE, Delegation, Revocation, Delegation Timeout Interval, LSP State
Report, LSP Update Request, LSP State Database.
This document defines the following term: 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 utilize the
Delegation mechanism to update LSP parameters in those PCCs that
delegated 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 PCC's LSPs. 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: a PCE, assuming LSP delegation granted by default,
can issue recommendations to the network.
Minimum Cut Set: the minimum set of links for a specific source Minimum Cut Set: the minimum set of links for a specific source
destination pair which, when removed from the network, results in destination pair which, when removed from the network, results in
a specific source being completely isolated from specific a specific source being completely isolated from specific
destination. The summed capacity of these links is equivalent to destination. The summed capacity of these links is equivalent to
the maximum capacity from the source to the destination by the the maximum capacity from the source to the destination by the
max-flow min-cut theorem. max-flow min-cut theorem.
3. Overview of the Stateful PCE Protocol Extensions 3. Application Scenarios
This section is included for the convenience of the reader, please
refer to the referenced documents for details of the operation.
[I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to
enable stateful control of LSPs within and across PCEP sessions in
compliance with [RFC4657]. It includes mechanisms to effect LSP
state synchronization between PCCs and PCEs, delegation of control
over LSPs to PCEs, and PCE control of timing and sequence of path
computations within and across PCEP sessions.
[I-D.ietf-pce-stateful-pce] applies equally to MPLS-TE and GMPLS LSPs
and distinguishes between an active and a passive stateful PCE. A
passive stateful PCE uses LSP state information to optimize path
computations but does not actively update LSP state. In contrast, an
active stateful PCE may issue recommendations to the network. For
example, an active stateful PCE may update LSP parameters in those
PCCs that delegated control over their LSPs to the PCE.
Several new functions are added in PCEP to support both active and
passive stateful PCEs. They are described in
[I-D.ietf-pce-stateful-pce]. A function can be initiated either from
a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C). The new
functions are:
Stateful Capability negotiation (E-C,C-E): both the PCC and the PCE
must announce during PCEP session establishment that they support
stateful PCE PCEP extensions.
LSP state synchronization (C-E): after the session between a PCC and
a stateful PCE is initialized, the PCE can perform path
computation and update attributes in a PCC. However, if the goal
of the PCE is to provide accurate path information based on the
most up-to-date state of the network, the PCE should wait until it
learns the state of the PCC's LSP states before doing so.
LSP update request (E-C): A PCE requests the modification of one or
more attributes (e.g., route) on a PCC's LSP.
LSP state report (C-E): a PCC sends an LSP state report to a PCE
whenever the state of an LSP changes.
LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to
update LSP attributes on one or more LSPs; the PCE becomes the
authoritative source of the LSP's attributes as long as the
delegation is in effect; the PCC may withdraw the delegation or
the PCE may give up the delegation.
[I-D.ietf-pce-pce-initiated-lsp] provides extensions to PCEP which
enable the setup, maintenance and teardown of PCE-initiated LSPs
under the stateful PCE model, without the need for local
configuration on the PCC, thus allowing for a dynamic network that is
centrally controlled and deployed.
[I-D.ietf-pce-stateful-pce] defines the extensions needed to support
auto-discovery of stateful PCEs when using IGP for PCE discovery.
4. Deployment Considerations
This section discusses generic issues with stateful PCE deployments,
and how specific protocol mechanisms can be used to address them.
4.1. Multi-PCE Deployments
Stateless and stateful PCEs can co-exist 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. The capability negotiation
in [I-D.ietf-pce-stateful-pce] ensures correct operation when the PCE
address is configured on the PCC.
Multiple stateful PCEs can co-exist 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. [I-D.ietf-pce-stateful-pce] describes how LSPs can be re-
delegated between PCEs, and the procedures on a PCE failure.
[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 population of the LSP-DB using information received from PCCs is
supported by the stateful PCE extensions defined in
[I-D.ietf-pce-stateful-pce] , i.e., via LSP state report messages.
Population of the LSP database via other means is not precluded.
Because the accuracy of the computations depends on the accuracy of
the databases used, it is worth noting that the PCE view lags behind
the true state of the network, because the updates must reach the PCE
from 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, co-existing in
the same network, such as a passive stateful PCE and an active
stateful PCE, it is useful to refer to a LSP, be it delegated or not,
by a unique identifier instead of providing detailed information
(e.g., route, bandwidth etc.) 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.
[I-D.ietf-pce-stateful-pce] defines a synchronization function and
procedure, allowing a PCC to synchronize its LSP state with the PCE
and [I-D.ietf-pce-stateful-sync-optimizations] specifies
optimizations to the synchronization procedure. LSP state
synchronization procedures can be applied equally to a network node
or another PCE, allowing multiple ways of re-acquiring the LSP
database on a restart. Because synchronization may also be skipped,
if a PCE 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. Application Scenarios
In the following sections, several use cases are described, In the following sections, several use cases are described,
showcasing scenarios that benefit from the deployment of a stateful showcasing scenarios that benefit from the deployment of a stateful
PCE. PCE.
5.1. Optimization of LSP Placement 3.1. Optimization of LSP Placement
The following use cases demonstrate a need for visibility into global The following use cases demonstrate a need for visibility into global
LSP states in PCE path computations, and for a PCE control of LSP states in PCE path computations, and for a PCE control of
sequence and timing in altering LSP path characteristics within and sequence and timing in altering LSP path characteristics within and
across PCEP sessions. Reference topologies for the use cases across PCEP sessions. Reference topologies for the use cases
described later in this section are shown in Figures 1 and 2. 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 Some of the use cases below are focused on MPLS-TE deployments, but
may also apply to GMPLS. Unless otherwise cited, use cases assume may also apply to GMPLS. Unless otherwise cited, use cases assume
that all LSPs listed exist at the same LSP priority. that all LSPs listed exist at the same LSP priority.
skipping to change at page 7, line 39 skipping to change at page 5, line 35
| A | | B | | C | | A | | B | | C |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| | | | | |
| | | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| E +--------+ F +--------+ G | | E +--------+ F +--------+ G |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 2: Reference topology 2 Figure 2: Reference topology 2
5.1.1. Throughput Maximization and Bin Packing 3.1.1. Throughput Maximization and Bin Packing
Because LSP attribute changes in [RFC5440] are driven by Path Because LSP attribute changes in [RFC5440] are driven by Path
Computation Request (PCReq) messages under control of a PCC's local Computation Request (PCReq) messages under control of a PCC's local
timers, the sequence of resource reservation arrivals occurring in timers, the sequence of resource reservation arrivals occurring in
the network will be randomized. This, coupled with a lack of global 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 LSP state visibility on the part of a stateless PCE may result in
suboptimal throughput in a given network topology, as will be shown suboptimal throughput in a given network topology, as will be shown
in the example below. in the example below.
Reference topology 2 in Figure 2 and Tables 1 and 2 show an example Reference topology 2 in Figure 2 and Tables 1 and 2 show an example
skipping to change at page 9, line 26 skipping to change at page 7, line 14
+------+-----+-----+-----+--------+----------+---------+ +------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path | | Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+ +------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 5 | Yes | A-C-D-E | | 1 | 1 | A | E | 5 | Yes | A-C-D-E |
| 2 | 2 | B | E | 10 | No | --- | | 2 | 2 | B | E | 10 | No | --- |
+------+-----+-----+-----+--------+----------+---------+ +------+-----+-----+-----+--------+----------+---------+
Table 4: Bin Packing use case demand time series Table 4: Bin Packing use case demand time series
5.1.2. Deadlock 3.1.2. Deadlock
This section discusses a use case of cross-LSP impact under degraded This section discusses a use case of cross-LSP impact under degraded
operation. Most existing RSVP-TE implementations will not tear down operation. Most existing RSVP-TE implementations will not tear down
established LSPs in the event of the failure of the bandwidth established LSPs in the event of the failure of the bandwidth
increase procedure detailed in [RFC3209]. This behavior is directly increase procedure detailed in [RFC3209]. This behavior is directly
implied to be correct in [RFC3209] and is often desirable from an implied to be correct in [RFC3209] and is often desirable from an
operator's perspective, because either a) the destination prefixes operator's perspective, because either a) the destination prefixes
are not reachable via any means other than MPLS or b) this would 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 result in significant packet loss as demand is shifted to other LSPs
in the overlay mesh. in the overlay mesh.
skipping to change at page 11, line 5 skipping to change at page 8, line 40
+------+-----+-----+-----+--------+----------+---------+ +------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path | | Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+ +------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 2 | Yes | A-C-D-E | | 1 | 1 | A | E | 2 | Yes | A-C-D-E |
| 2 | 2 | B | E | 2 | Yes | B-C-D-E | | 2 | 2 | B | E | 2 | Yes | B-C-D-E |
| 3 | 1 | A | E | 20 | No | --- | | 3 | 1 | A | E | 20 | No | --- |
+------+-----+-----+-----+--------+----------+---------+ +------+-----+-----+-----+--------+----------+---------+
Table 6: Degraded operation demand time series Table 6: Degraded operation demand time series
5.1.3. Minimum Perturbation 3.1.3. Minimum Perturbation
As a result of both the lack of visibility into global LSP state and As a result of both the lack of visibility into global LSP state and
the lack of control over event ordering across PCE sessions, the lack of control over event ordering across PCE sessions,
unnecessary perturbations may be introduced into the network by a unnecessary perturbations may be introduced into the network by a
stateless PCE. Tables 7 and 8 show an example of an unnecessary stateless PCE. Tables 7 and 8 show an example of an unnecessary
network perturbation using Reference Topology 1 in Figure 1. In this network perturbation using Reference Topology 1 in Figure 1. In this
case an unimportant (high LSP priority value) LSP (LSP1) is first set 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 up along the shortest path. At time 2, which is assumed to be
relatively close to time 1, a second more important (lower LSP- relatively close to time 1, a second more important (lower LSP-
priority value) LSP (LSP2) is established, preempting LSP1, priority value) LSP (LSP2) is established, preempting LSP1,
skipping to change at page 12, line 8 skipping to change at page 9, line 45
the affected LSPs. Thirdly, the stateful PCE can use the LSP-DB to the affected LSPs. Thirdly, the stateful PCE can use the LSP-DB to
further optimize the placement of LSPs. This will ensure placement further optimize the placement of LSPs. This will ensure placement
of the more important LSP along the shortest path, avoiding the setup of the more important LSP along the shortest path, avoiding the setup
and subsequent preemption of the lower priority LSP. Similarly, when and subsequent preemption of the lower priority LSP. Similarly, when
a new higher priority LSP which requires preemption of existing lower a new higher priority LSP which requires preemption of existing lower
priority LSP(s), a stateful PCE can determine the minimum number of priority LSP(s), a stateful PCE can determine the minimum number of
lower priority LSP(s) to reroute using the make-before-break (MBB) lower priority LSP(s) to reroute using the make-before-break (MBB)
mechanism without disrupting any service and then set up the higher mechanism without disrupting any service and then set up the higher
priority LSP. priority LSP.
5.1.4. Predictability 3.1.4. Predictability
Randomization of reservation events caused by lack of control over Randomization of reservation events caused by lack of control over
event ordering across PCE sessions results in poor predictability in event ordering across PCE sessions results in poor predictability in
LSP routing. An offline system applying a consistent optimization LSP routing. An offline system applying a consistent optimization
method will produce predictable results to within either the boundary method will produce predictable results to within either the boundary
of forecast error (when reservations are over-provisioned by of forecast error (when reservations are over-provisioned by
reasonable margins) or to the variability of the signal and the reasonable margins) or to the variability of the signal and the
forecast error (when applying some hysteresis in order to minimize forecast error (when applying some hysteresis in order to minimize
churn). Predictable results are valuable for being able to simulate churn). Predictable results are valuable for being able to simulate
the network and reliably test it under various scenarios, especially the network and reliably test it under various scenarios, especially
skipping to change at page 13, line 21 skipping to change at page 11, line 5
Table 11: Predictability LSP and demand time series 2 Table 11: Predictability LSP and demand time series 2
As can be shown in the example, both LSPs are routed in both cases, 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 but along very different paths. This would be a challenge if
reliable simulation of the network is attempted. An active stateful reliable simulation of the network is attempted. An active stateful
PCE can solve this through control over LSP ordering. Based on PCE can solve this through control over LSP ordering. Based on
triggers such as a failure or an optimization trigger, the PCE can triggers such as a failure or an optimization trigger, the PCE can
order the computations and path setup in a deterministic way. order the computations and path setup in a deterministic way.
5.2. Auto-bandwidth Adjustment 3.2. Auto-bandwidth Adjustment
The bandwidth requirement of LSPs often change over time, requiring The bandwidth requirement of LSPs often change over time, requiring
resizing the LSP. In most implementations available today, the head- resizing the LSP. In most implementations available today, the head-
end node performs this function by monitoring the actual bandwidth end node performs this function by monitoring the actual bandwidth
usage, triggering a recomputation and resignaling when a threshold is usage, triggering a recomputation and resignaling when a threshold is
reached. This operation is referred as auto-bandwidth adjustment. reached. This operation is referred as auto-bandwidth adjustment.
The head-end node either recomputes the path locally, or it requests 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 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 case, the PCE computes a new path and provides the new route
suggestion. Upon receiving the reply from the PCE, the PCC re- suggestion. Upon receiving the reply from the PCE, the PCC re-
skipping to change at page 14, line 5 skipping to change at page 11, line 34
A more interesting smart bandwidth adjustment case is one where the A more interesting smart bandwidth adjustment case is one where the
LSP resizing decision is done by an external entity, with access to LSP resizing decision is done by an external entity, with access to
additional information such as historical trending data, application- additional information such as historical trending data, application-
specific information about expected demands or policy information, as specific information about expected demands or policy information, as
well as knowledge of the actual desired flow volumes. In this case well as knowledge of the actual desired flow volumes. In this case
an active stateful PCE provides an advantage in both the computation an active stateful PCE provides an advantage in both the computation
with knowledge of all LSPs in the domain and in the ability to with knowledge of all LSPs in the domain and in the ability to
trigger bandwidth modification of the LSP. trigger bandwidth modification of the LSP.
5.3. Bandwidth Scheduling 3.3. Bandwidth Scheduling
Bandwidth scheduling allows network operators to reserve resources in Bandwidth scheduling allows network operators to reserve resources in
advance according to the agreements with their customers, and allow advance according to the agreements with their customers, and allow
them to transmit data with specified starting time and duration, for them to transmit data with specified starting time and duration, for
example for a scheduled bulk data replication between data centers. example for a scheduled bulk data replication between data centers.
Traditionally, this can be supported by network management system Traditionally, this can be supported by network management system
(NMS) operation through path pre-establishment and activation on the (NMS) operation through path pre-establishment and activation on the
agreed starting time. However, this does not provide efficient agreed starting time. However, this does not provide efficient
network usage since the established paths exclude the possibility of network usage since the established paths exclude the possibility of
skipping to change at page 14, line 29 skipping to change at page 12, line 11
(e.g., starting time and duration) across the network. Nevertheless, (e.g., starting time and duration) across the network. Nevertheless,
this method inevitably increases the complexity of signaling and this method inevitably increases the complexity of signaling and
routing process. routing process.
A passive stateful PCE can support this application with better A passive stateful PCE can support this application with better
efficiency since it can alleviate the burden of processing on network efficiency since it can alleviate the burden of processing on network
elements. This requires the PCE to maintain the scheduled LSPs and elements. This requires the PCE to maintain the scheduled LSPs and
their associated resource usage, as well as the ability of head-ends their associated resource usage, as well as the ability of head-ends
to trigger signaling for LSP setup/deletion at the correct time. to trigger signaling for LSP setup/deletion at the correct time.
This approach requires coarse time synchronization between PCEs and This approach requires coarse time synchronization between PCEs and
PCCs. If an active stateful PCE is available, the PCE can trigger PCCs. With PCE initiation capability, a PCE can trigger the setup
the setup/deletion of scheduled requests in a centralized manner, as and deletion of scheduled requests in a centralized manner, without
specified [I-D.ietf-pce-pce-initiated-lsp], without modification of modification of existing head-end behaviors, by notifying the PCCs to
existing head-end behaviors, by notifying the PCCs to set up or tear set up or tear down the paths.
down the paths.
5.4. Recovery 3.4. Recovery
The recovery use cases discussed in the following sections show how The recovery use cases discussed in the following sections show how
leveraging a stateful PCE can simplify the computation of recovery leveraging a stateful PCE can simplify the computation of recovery
path(s). In particular, two characteristics of a stateful PCE are path(s). In particular, two characteristics of a stateful PCE are
used: 1) using information stored in the LSP-DB for determining used: 1) using information stored in the LSP-DB for determining
shared protection resources and 2) performing computations with shared protection resources and 2) performing computations with
knowledge of all LSPs in a domain. knowledge of all LSPs in a domain.
5.4.1. Protection 3.4.1. Protection
If a PCC can specify in a request whether the computation is for a 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 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 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 can send multiple requests to the PCE, asking for two LSPs and use
them as working and backup paths separately. Either way, the them as working and backup paths separately. Either way, the
resources bound to backup paths can be shared by different LSPs to resources bound to backup paths can be shared by different LSPs to
improve the overall network efficiency, such as m:n protection or improve the overall network efficiency, such as m:n protection or
pre-configured shared mesh recovery techniques as specified in pre-configured shared mesh recovery techniques as specified in
[RFC4427]. If resource sharing is supported for LSP protection, the [RFC4427]. If resource sharing is supported for LSP protection, the
skipping to change at page 16, line 9 skipping to change at page 13, line 45
Alternatively, a stateless PCE may able to compute Shared Risk Link Alternatively, a stateless PCE may able to compute Shared Risk Link
Group (SRLG)-diversified paths if TED is extended so that it includes Group (SRLG)-diversified paths if TED is extended so that it includes
the SRLG information that are protected by a given backup resource, the SRLG information that are protected by a given backup resource,
but at the expense of a high complexity in routing. On the other 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 hand, a stateful PCE can get the LSPs information by itself given
that the LSP identifier(s) and can achieve the goal of finding SRLG- that the LSP identifier(s) and can achieve the goal of finding SRLG-
diversified protection paths for both LSPs. This is made possible by diversified protection paths for both LSPs. This is made possible by
comparing the LSP resource usage exploiting the LSP-DB accessible by comparing the LSP resource usage exploiting the LSP-DB accessible by
the stateful PCE. the stateful PCE.
5.4.2. Restoration 3.4.2. Restoration
In case of a link failure, such as a fiber cut, multiple LSPs may 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 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. will be informed of the failure by the nodes detecting the failure.
These source nodes will send requests to a PCE for rerouting. In 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 order to reuse the resource taken by an existing LSP, the source node
can send a PCReq message including the Exclude Route Object (XRO) can send a PCReq message including the Exclude Route Object (XRO)
with Fail (F) bit set, together with the record route object (RRO) with Fail (F) bit set, together with the record route object (RRO)
containing the current route information, as specified in [RFC5521]. containing the current route information, as specified in [RFC5521].
skipping to change at page 16, line 46 skipping to change at page 14, line 34
rerouting requests sent as a result of the link failure. rerouting requests sent as a result of the link failure.
If the target is to avoid resource contention within the time-window If the target is to avoid resource contention within the time-window
of high number of LSP rerouting requests, a stateful PCE can retain of high number of LSP rerouting requests, a stateful PCE can retain
the under-construction LSP resource usage information for a given the under-construction LSP resource usage information for a given
time and exclude it from being used for forthcoming LSPs request. In time and exclude it from being used for forthcoming LSPs request. In
this way, it can ensure that the resource will not be double-booked this way, it can ensure that the resource will not be double-booked
and thus the issue of resource contention and computation crank-backs and thus the issue of resource contention and computation crank-backs
can be alleviated. can be alleviated.
5.4.3. SRLG Diversity 3.4.3. SRLG Diversity
An alternative way to achieve efficient resilience is to maintain An alternative way to achieve efficient resilience is to maintain
SRLG disjointness between LSPs, irrespective of whether these LSPs SRLG disjointness between LSPs, irrespective of whether these LSPs
share the source and destination nodes or not. This can be achieved share the source and destination nodes or not. This can be achieved
at provisioning time, if the routes of all the LSPs are requested at provisioning time, if the routes of all the LSPs are requested
together, using a synchronized computation of the different LSPs with together, using a synchronized computation of the different LSPs with
SRLG disjointness constraint. If the LSPs need to be provisioned at SRLG disjointness constraint. If the LSPs need to be provisioned at
different times, the PCC can specify, as constraints to the path different times, the PCC can specify, as constraints to the path
computation a set of SRLGs using the Exclude Route Object [RFC5521]. computation a set of SRLGs using the Exclude Route Object [RFC5521].
However, for the latter to be effective, it is needed that the entity However, for the latter to be effective, it is needed that the entity
skipping to change at page 17, line 23 skipping to change at page 15, line 13
PCReq message sent by a PCC. PCReq message sent by a PCC.
A passive stateful PCE maintains the updated SRLG information of the A passive stateful PCE maintains the updated SRLG information of the
established LSPs in a centralized manner. Therefore, the PCC can established LSPs in a centralized manner. Therefore, the PCC can
specify as constraints to the path computation the SRLG disjointness specify as constraints to the path computation the SRLG disjointness
of a set of already established LSPs by only providing the LSP of a set of already established LSPs by only providing the LSP
identifiers. Similarly, a passive stateful PCE can also accommodate identifiers. Similarly, a passive stateful PCE can also accommodate
disjointness using other constraints, such as link, node or path disjointness using other constraints, such as link, node or path
segment etc. segment etc.
5.5. Maintenance of Virtual Network Topology (VNT) 3.5. Maintenance of Virtual Network Topology (VNT)
In Multi-Layer Networks (MLN), a 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 [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- which provides TE links to the upper layer. In [RFC5623], the PCE-
based architecture is proposed to support path computation in MLN based architecture is proposed to support path computation in MLN
networks in order to achieve inter-layer TE. networks in order to achieve inter-layer TE.
The establishment/teardown of a TE link in VNT needs to take into 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 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 the higher layer. Hence, when a stateless PCE cannot find the route
skipping to change at page 17, line 45 skipping to change at page 15, line 35
not have enough information to decide whether to set up or remove a not have enough information to decide whether to set up or remove a
TE link or not, which then can result in non-optimal usage of TE link or not, which then can result in non-optimal usage of
resource. On the other hand, a passive stateful PCE can make 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 better decision of when and how to modify the VNT either to
accommodate new LSP requests or to re-optimize resource usage across accommodate new LSP requests or to re-optimize resource usage across
layers irrespective of the PCE models as described in [RFC5623]. layers irrespective of the PCE models as described in [RFC5623].
Furthermore, given the active capability, the stateful PCE can issue Furthermore, given the active capability, the stateful PCE can issue
VNT modification suggestions in order to accommodate path setup VNT modification suggestions in order to accommodate path setup
requests or re-optimize resource usage across layers. requests or re-optimize resource usage across layers.
5.6. LSP Re-optimization 3.6. LSP Re-optimization
In order to make efficient usage of network resources, it is In order to make efficient usage of network resources, it is
sometimes desirable to re-optimize one or more LSPs dynamically. In sometimes desirable to re-optimize one or more LSPs dynamically. In
the case of a stateless PCE, in order to optimize network resource the case of a stateless PCE, in order to optimize network resource
usage dynamically through online planning, a PCC must send a request usage dynamically through online planning, a PCC must send a request
to the PCE together with detailed path/bandwidth information of the to the PCE together with detailed path/bandwidth information of the
LSPs that need to be concurrently optimized. This means the PCC must LSPs that need to be concurrently optimized. This means the PCC must
be able to determine when and which LSPs should be optimized. In the 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 case of a passive stateful PCE, given the LSP state information in
the LSP database, the process of dynamic optimization of network the LSP database, the process of dynamic optimization of network
skipping to change at page 18, line 42 skipping to change at page 16, line 31
o Allow the PCE to determine when re-optimization is needed, with o Allow the PCE to determine when re-optimization is needed, with
which level (GCO or a more incremental optimization) which level (GCO or a more incremental optimization)
o Allow the PCE to determine which LSPs should be re-optimized o Allow the PCE to determine which LSPs should be re-optimized
o Allow a PCE to control the sequence of events across multiple o Allow a PCE to control the sequence of events across multiple
PCCs, allowing for bulk (and truly global) optimization, LSP PCCs, allowing for bulk (and truly global) optimization, LSP
shuffling etc. shuffling etc.
5.7. Resource Defragmentation 3.7. Resource Defragmentation
If LSPs are dynamically allocated and released over time, the If LSPs are dynamically allocated and released over time, the
resource becomes fragmented. In networks with link bundle, the resource becomes fragmented. In networks with link bundle, the
overall available resource on a (bundle) link might be sufficient for overall available resource on a (bundle) link might be sufficient for
a new LSP request, but if the available resource is not continuous, a new LSP request, but if the available resource is not continuous,
the request is rejected. In order to perform the defragmentation the request is rejected. In order to perform the defragmentation
procedure, stateful PCEs can be used, since global visibility of LSPs procedure, stateful PCEs can be used, since global visibility of LSPs
in the network is required to accurately assess resources on the in the network is required to accurately assess resources on the
LSPs, and perform de-fragmentation while ensuring a minimal LSPs, and perform de-fragmentation while ensuring a minimal
disruption of the network. This use case cannot be accommodated by a disruption of the network. This use case cannot be accommodated by a
skipping to change at page 19, line 21 skipping to change at page 17, line 10
12.5GHz, 25GHz etc.) can co-exist so as to accommodate the services 12.5GHz, 25GHz etc.) can co-exist so as to accommodate the services
with different bandwidth requests. Therefore, even if the overall with different bandwidth requests. Therefore, even if the overall
spectrum size can meet the service request, it may not be usable if spectrum size can meet the service request, it may not be usable if
the available spectrum resource is not contiguous, but rather the available spectrum resource is not contiguous, but rather
fragmented into smaller pieces. Thus, with the help of existing LSP fragmented into smaller pieces. Thus, with the help of existing LSP
state information, a stateful PCE can make the resource grouped state information, a stateful PCE can make the resource grouped
together to be usable. Moreover, a stateful PCE can proactively together to be usable. Moreover, a stateful PCE can proactively
choose routes for upcoming path requests to reduce the chance of choose routes for upcoming path requests to reduce the chance of
spectrum fragmentation. spectrum fragmentation.
5.8. Point-to-Multi-Point Applications 3.8. Point-to-Multi-Point Applications
PCE has been identified as an appropriate technology for the PCE has been identified as an appropriate technology for the
determination of the paths of point-to-multipoint (P2MP) TE LSPs determination of the paths of point-to-multipoint (P2MP) TE LSPs
[RFC5671]. The application scenarios and use-cases described in [RFC5671]. The application scenarios and use-cases described in
Section 5.1, Section 5.4 and Section 5.6 are also applicable to P2MP Section 3.1, Section 3.4 and Section 3.6 are also applicable to P2MP
TE LSPs. TE LSPs.
In addition to these, the stateful nature of a PCE simplifies the In addition to these, the stateful nature of a PCE simplifies the
information conveyed in PCEP messages since it is possible to refer information conveyed in PCEP messages since it is possible to refer
to the LSPs via an identifier. For P2MP, this is an added advantage, 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 where the size of the PCEP message is much larger. In case of
stateless PCEs, modification of a P2MP tree requires encoding of all stateless PCEs, modification of a P2MP tree requires encoding of all
leaves along with the paths in PCReq message. But using a stateful leaves along with the paths in PCReq message. But using a stateful
PCE with P2MP capability, the PCEP message can be used to convey only PCE with P2MP capability, the PCEP message can be used to convey only
the modifications (the other information can be retrieved from the the modifications (the other information can be retrieved from the
identifier via the LSP-DB). identifier via the LSP-DB).
5.9. Impairment-Aware Routing and Wavelength Assignment (IA-RWA) 3.9. Impairment-Aware Routing and Wavelength Assignment (IA-RWA)
In Wavelength Switched Optical Networks (WSONs) [RFC6163], a In Wavelength Switched Optical Networks (WSONs) [RFC6163], a
wavelength-switched LSP traverses one or more fiber links. The bit wavelength-switched LSP traverses one or more fiber links. The bit
rates of the client signals carried by the wavelength LSPs may be the 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 same or different. Hence, a fiber link may transmit a number of
wavelength LSPs with equal or mixed bit rate signals. For example, a wavelength LSPs with equal or mixed bit rate signals. For example, a
fiber link may multiplex the wavelengths with only 10Gb/s signals, fiber link may multiplex the wavelengths with only 10Gb/s signals,
mixed 10Gb/s and 40Gb/s signals, or mixed 40Gb/s and 100Gb/s signals. mixed 10Gb/s and 40Gb/s signals, or mixed 40Gb/s and 100Gb/s signals.
IA-RWA in WSONs refers to the process (i.e., lightpath computation) IA-RWA in WSONs refers to the process (i.e., lightpath computation)
skipping to change at page 20, line 37 skipping to change at page 18, line 26
related routing protocols, i.e., [RFC7688] and [RFC7580], only related routing protocols, i.e., [RFC7688] and [RFC7580], only
advertise limited information (i.e., availability) of the existing advertise limited information (i.e., availability) of the existing
wavelengths, without defining the supported client bit rates. It wavelengths, without defining the supported client bit rates. It
will incur substantial amount of control plane overhead if routing will incur substantial amount of control plane overhead if routing
protocols are extended to support dissemination of the new protocols are extended to support dissemination of the new
information relevant for the IA-RWA process. In this scenario, information relevant for the IA-RWA process. In this scenario,
stateful PCE(s) would be a more appropriate mechanism to solve this stateful PCE(s) would be a more appropriate mechanism to solve this
problem. Stateful PCE(s) can exploit impairment information of LSPs problem. Stateful PCE(s) can exploit impairment information of LSPs
stored in LSP-DB to provide accurate RWA calculation. stored in LSP-DB to provide accurate RWA calculation.
6. Security Considerations 4. Deployment Considerations
The PCEP extensions in support of stateful PCE and the delegation of This section discusses general issues with stateful PCE deployments,
path control, result in more information being available for a and identifies areas where additional protocol extensions and
hypothetical adversary and a number of additional attack surfaces precedures are needed to address them. Definitions of protocol
which must be protected. [I-D.ietf-pce-stateful-pce] discusses mechanisms are beyond the scope of this document.
different attack vectors and defines protocol mechanisms to protect
against them. It also lays out implementation requirements for
configuration capabilities that allow the operator to control the PCC
behavior when faced with an attack. This document does not introduce
any new security considerations beyond those discussed in
[I-D.ietf-pce-stateful-pce].
7. IANA Considerations 4.1. Multi-PCE Deployments
Stateless and stateful PCEs can co-exist 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 co-exist 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 re-delegated 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, it is worth noting that the PCE view lags behind
the true state of the network, because the updates must reach the PCE
from 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, co-existing in
the same network, such as a passive stateful PCE and an active
stateful PCE, it is useful to refer to a LSP, be it delegated or not,
by a unique identifier instead of providing detailed information
(e.g., route, bandwidth etc.) 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 of re-acquiring the LSP
database on a restart. Because synchronization may also be skipped,
if a PCE 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 which must be protected. This includes
but not limited to the authentication and encryption of PCEP
sessions, snooping of the state of the LSPs active in the network
etc. Therefore, documents where the PCEP protocol extensions are
defined need to consider the issues and risks associated with a
stateful PCE.
6. IANA Considerations
This document does not require any IANA action. This document does not require any IANA action.
8. Contributing Authors 7. Contributing Authors
The following people all contributed significantly to this document The following people all contributed significantly to this document
and are listed below in alphabetical order: and are listed below in alphabetical order:
Ramon Casellas Ramon Casellas
CTTC - Centre Tecnologic de Telecomunicacions de Catalunya CTTC - Centre Tecnologic de Telecomunicacions de Catalunya
Av. Carl Friedrich Gauss n7 Av. Carl Friedrich Gauss n7
Castelldefels, Barcelona 08860 Castelldefels, Barcelona 08860
Spain Spain
Email: ramon.casellas@cttc.es Email: ramon.casellas@cttc.es
skipping to change at page 22, line 24 skipping to change at page 21, line 31
Huawei Technologies Huawei Technologies
F3-5-B R&D Center, Huawei Base F3-5-B R&D Center, Huawei Base
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 P.R.China Shenzhen 518129 P.R.China
Phone: +86-755-28972912 Phone: +86-755-28972912
Email: zhangfatai@huawei.com Email: zhangfatai@huawei.com
Xiaobing Zi Xiaobing Zi
Email: unknown Email: unknown
9. Acknowledgements 8. Acknowledgements
We would like to thank Cyril Margaria, Adrian Farrel, JP Vasseur and We would like to thank Cyril Margaria, Adrian Farrel, JP Vasseur and
Ravi Torvi for the useful comments and discussions. Ravi Torvi for the useful comments and discussions.
10. References 9. References
10.1. Normative References
[I-D.ietf-pce-stateful-pce] 9.1. Normative References
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-16 (work in progress), September 2016.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>. <http://www.rfc-editor.org/info/rfc4655>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>. <http://www.rfc-editor.org/info/rfc5440>.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", RFC 7399, Computation Element Architecture", RFC 7399,
DOI 10.17487/RFC7399, October 2014, DOI 10.17487/RFC7399, October 2014,
<http://www.rfc-editor.org/info/rfc7399>. <http://www.rfc-editor.org/info/rfc7399>.
10.2. Informative References 9.2. Informative References
[I-D.ietf-pce-gmpls-pcep-extensions]
Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for
GMPLS", draft-ietf-pce-gmpls-pcep-extensions-11 (work in
progress), October 2015.
[I-D.ietf-pce-pce-initiated-lsp]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-ietf-pce-pce-initiated-lsp-07 (work in
progress), July 2016.
[I-D.ietf-pce-stateful-sync-optimizations]
Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", draft-
ietf-pce-stateful-sync-optimizations-05 (work in
progress), April 2016.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>. <http://www.rfc-editor.org/info/rfc3209>.
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized (Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4427, Multi-Protocol Label Switching (GMPLS)", RFC 4427,
DOI 10.17487/RFC4427, March 2006, DOI 10.17487/RFC4427, March 2006,
 End of changes. 34 change blocks. 
233 lines changed or deleted 171 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/