draft-ietf-pce-stateful-pce-app-05.txt   draft-ietf-pce-stateful-pce-app-06.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 21, 2016 Google, Inc. Expires: January 8, 2017 Google, Inc.
October 19, 2015 July 07, 2016
Applicability of a Stateful Path Computation Element (PCE) Applicability of a Stateful Path Computation Element (PCE)
draft-ietf-pce-stateful-pce-app-05 draft-ietf-pce-stateful-pce-app-06
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 21, 2016. This Internet-Draft will expire on January 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of the Stateful PCE Protocol Extensions . . . . . . 4 3. Overview of the Stateful PCE Protocol Extensions . . . . . . 4
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 5
4.1. Multi-PCE Deployments . . . . . . . . . . . . . . . . . . 5 4.1. Multi-PCE Deployments . . . . . . . . . . . . . . . . . . 5
4.2. LSP State Synchronization . . . . . . . . . . . . . . . . 5 4.2. LSP State Synchronization . . . . . . . . . . . . . . . . 5
4.3. PCE Survivability . . . . . . . . . . . . . . . . . . . . 6 4.3. PCE Survivability . . . . . . . . . . . . . . . . . . . . 6
5. Application Scenarios . . . . . . . . . . . . . . . . . . . . 6 5. Application Scenarios . . . . . . . . . . . . . . . . . . . . 6
5.1. Optimization of LSP Placement . . . . . . . . . . . . . . 6 5.1. Optimization of LSP Placement . . . . . . . . . . . . . . 6
5.1.1. Throughput Maximization and Bin Packing . . . . . . . 7 5.1.1. Throughput Maximization and Bin Packing . . . . . . . 7
5.1.2. Deadlock . . . . . . . . . . . . . . . . . . . . . . 9 5.1.2. Deadlock . . . . . . . . . . . . . . . . . . . . . . 9
5.1.3. Minimum Perturbation . . . . . . . . . . . . . . . . 10 5.1.3. Minimum Perturbation . . . . . . . . . . . . . . . . 11
5.1.4. Predictability . . . . . . . . . . . . . . . . . . . 11 5.1.4. Predictability . . . . . . . . . . . . . . . . . . . 12
5.2. Auto-bandwidth Adjustment . . . . . . . . . . . . . . . . 13 5.2. Auto-bandwidth Adjustment . . . . . . . . . . . . . . . . 13
5.3. Bandwidth Scheduling . . . . . . . . . . . . . . . . . . 13 5.3. Bandwidth Scheduling . . . . . . . . . . . . . . . . . . 13
5.4. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 14 5.4. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 14
5.4.1. Protection . . . . . . . . . . . . . . . . . . . . . 14 5.4.1. Protection . . . . . . . . . . . . . . . . . . . . . 14
5.4.2. Restoration . . . . . . . . . . . . . . . . . . . . . 15 5.4.2. Restoration . . . . . . . . . . . . . . . . . . . . . 16
5.4.3. SRLG Diversity . . . . . . . . . . . . . . . . . . . 16 5.4.3. SRLG Diversity . . . . . . . . . . . . . . . . . . . 16
5.5. Maintenance of Virtual Network Topology (VNT) . . . . . . 17 5.5. Maintenance of Virtual Network Topology (VNT) . . . . . . 17
5.6. LSP Re-optimization . . . . . . . . . . . . . . . . . . . 17 5.6. LSP Re-optimization . . . . . . . . . . . . . . . . . . . 17
5.7. Resource Defragmentation . . . . . . . . . . . . . . . . 18 5.7. Resource Defragmentation . . . . . . . . . . . . . . . . 18
5.8. Point-to-Multi-Point Applications . . . . . . . . . . . . 19 5.8. Point-to-Multi-Point Applications . . . . . . . . . . . . 19
5.9. Impairment-Aware Routing and Wavelength Assignment (IA- 5.9. Impairment-Aware Routing and Wavelength Assignment (IA-
RWA) . . . . . . . . . . . . . . . . . . . . . . . . . . 19 RWA) . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 20 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 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
skipping to change at page 5, line 8 skipping to change at page 5, line 8
LSP state report (C-E): a PCC sends an LSP state report to a PCE LSP state report (C-E): a PCC sends an LSP state report to a PCE
whenever the state of an LSP changes. whenever the state of an LSP changes.
LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to 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 update LSP attributes on one or more LSPs; the PCE becomes the
authoritative source of the LSP's attributes as long as the authoritative source of the LSP's attributes as long as the
delegation is in effect; the PCC may withdraw the delegation or delegation is in effect; the PCC may withdraw the delegation or
the PCE may give up the delegation. the PCE may give up the delegation.
[I-D.sivabalan-pce-disco-stateful] defines the extensions needed to [I-D.ietf-pce-pce-initiated-lsp] provides extensions to PCEP which
support auto-discovery of stateful PCEs when using IGP for PCE enable the setup, maintenance and teardown of PCE-initiated LSPs
discovery. 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 4. Deployment Considerations
This section discusses generic issues with stateful PCE deployments, This section discusses generic issues with stateful PCE deployments,
and how specific protocol mechanisms can be used to address them. and how specific protocol mechanisms can be used to address them.
4.1. Multi-PCE Deployments 4.1. Multi-PCE Deployments
Stateless and stateful PCEs can co-exist in the same network and be Stateless and stateful PCEs can co-exist in the same network and be
in charge of path computation of different types. To solve the in charge of path computation of different types. To solve the
skipping to change at page 5, line 32 skipping to change at page 5, line 37
discovery or configuration may be used. The capability negotiation discovery or configuration may be used. The capability negotiation
in [I-D.ietf-pce-stateful-pce] ensures correct operation when the PCE in [I-D.ietf-pce-stateful-pce] ensures correct operation when the PCE
address is configured on the PCC. address is configured on the PCC.
Multiple stateful PCEs can co-exist in the same network. These PCEs Multiple stateful PCEs can co-exist in the same network. These PCEs
may provide redundancy for load sharing, resilience, or partitioning may provide redundancy for load sharing, resilience, or partitioning
of computation features. Regardless of the reason for multiple PCEs, 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 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- time. [I-D.ietf-pce-stateful-pce] describes how LSPs can be re-
delegated between PCEs, and the procedures on a PCE failure. delegated between PCEs, and the procedures on a PCE failure.
[I-D.ietf-pce-questions] discusses various approaches for [RFC7399] discusses various approaches for synchronizing state among
synchronizing state among the PCEs when multiple PCEs are used for the PCEs when multiple PCEs are used for load sharing or backup and
load sharing or backup and compute LSPs for the same network. compute LSPs for the same network.
4.2. LSP State Synchronization 4.2. LSP State Synchronization
The population of the LSP-DB using information received from PCCs is The population of the LSP-DB using information received from PCCs is
supported by the stateful PCE extensions defined in supported by the stateful PCE extensions defined in
[I-D.ietf-pce-stateful-pce] , i.e., via LSP state report messages. [I-D.ietf-pce-stateful-pce] , i.e., via LSP state report messages.
Population of the LSP database via other means is not precluded. Population of the LSP database via other means is not precluded.
Because the accuracy of the computations depends on the accuracy of 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 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 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 from the network. Thus, the use of stateful PCE reduces but cannot
eliminate the possibility of crankbacks, nor can it guarantee optimal eliminate the possibility of crankbacks, nor can it guarantee optimal
computations all the time. [I-D.ietf-pce-questions] discusses these computations all the time. [RFC7399] discusses these limitations and
limitations and potential ways to alleviate them. potential ways to alleviate them.
In case of multiple PCEs with different capabilities, co-existing in In case of multiple PCEs with different capabilities, co-existing in
the same network, such as a passive stateful PCE and an active 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, stateful PCE, it is useful to refer to a LSP, be it delegated or not,
by a unique identifier instead of providing detailed information by a unique identifier instead of providing detailed information
(e.g., route, bandwidth etc.) associated with it, when these PCEs (e.g., route, bandwidth etc.) associated with it, when these PCEs
cooperate on path computation, such as for loading sharing. cooperate on path computation, such as for load sharing.
4.3. PCE Survivability 4.3. PCE Survivability
For a stateful PCE, an important issue is to get the LSP state For a stateful PCE, an important issue is to get the LSP state
information resynchronized after a restart. information resynchronized after a restart.
[I-D.ietf-pce-stateful-pce] defines a synchronization function and [I-D.ietf-pce-stateful-pce] defines a synchronization function and
procedure, allowing a PCC to synchronize its LSP state with the PCE procedure, allowing a PCC to synchronize its LSP state with the PCE
and [I-D.ietf-pce-stateful-sync-optimizations] specifies and [I-D.ietf-pce-stateful-sync-optimizations] specifies
optimizations to the synchronizations procedures. LSP state optimizations to the synchronization procedure. LSP state
synchronization procedures can be applied equally to a network nodes synchronization procedures can be applied equally to a network node
or another PCE, allowing multiple ways of re-acquiring the LSP or another PCE, allowing multiple ways of re-acquiring the LSP
database on a restart. Because synchronization may also be skipped, database on a restart. Because synchronization may also be skipped,
if a PCE implementation has the means to retrieve its database in a if a PCE implementation has the means to retrieve its database in a
different way (for example from a backup copy stored locally), the different way (for example from a backup copy stored locally), the
state can be restored without further overhead in the network. A state can be restored without further overhead in the network. A
hybrid approach where the bulk of the state is recovered locally, and hybrid approach where the bulk of the state is recovered locally, and
a small amount of state is reacquired from the network, is also a small amount of state is reacquired from the network, is also
possible. Note that locally recovering the state would still require possible. Note that locally recovering the state would still require
some degree of resynchronization to ensure that the recovered state some degree of resynchronization to ensure that the recovered state
is indeed up-to-date. Depending on the resynchronization mechanism is indeed up-to-date. Depending on the resynchronization mechanism
skipping to change at page 14, line 12 skipping to change at page 14, line 25
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. If an active stateful PCE is available, the PCE can trigger
the setup/deletion of scheduled requests in a centralized manner, the setup/deletion of scheduled requests in a centralized manner, as
without modification of existing head-end behaviors, by notifying the specified [I-D.ietf-pce-pce-initiated-lsp], without modification of
PCCs to set up or tear down the paths. existing head-end behaviors, by notifying the PCCs to set up or tear
down the paths.
5.4. Recovery 5.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 5.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 or for protection, and a PCC can report the resource by a working path or for protection, and a PCC can report the resource as
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
information relating to existing LSPs is required to avoid allocation information relating to existing LSPs is required to avoid allocation
of shared protection resources to two LSPs that might fail together of shared protection resources to two LSPs that might fail together
and cause protection contention issues. A stateless PCE can and cause protection contention issues. A stateless PCE can
accommodate this use case by having the PCC pass this information as accommodate this use case by having the PCC pass this information as
skipping to change at page 15, line 35 skipping to change at page 15, line 42
E. If the PCE decides LSP2_working follows B->A->E, then the backup 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 path LSP2_backup should not share the same protection resource with
LSP1 since LSP2 shares part of its resource (specifically A->E) 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 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. is no such constraint if B->C->D->E is chosen for LSP2_working.
If a stateless PCE is used, the head node B needs to be aware of the If a stateless PCE is used, the head node B needs to be aware of the
existence of LSPs which share the route of LSP2_working and of the existence of LSPs which share the route of LSP2_working and of the
details of their protection resources. B must pass this information details of their protection resources. B must pass this information
to the PCE as a constraint so as to request a path with diversity. to the PCE as a constraint so as to request a path with diversity.
Alternatively, a stateless PCE may able to compute carry out Shared Alternatively, a stateless PCE may able to compute Shared Risk Link
Risk Link Group (SRLG)-diversified paths if TED is extended so that Group (SRLG)-diversified paths if TED is extended so that it includes
it includes the SRLG information that are protected by a given backup the SRLG information that are protected by a given backup resource,
resource, but at the expense of a high complexity in routing. On the but at the expense of a high complexity in routing. On the other
other hand, a stateful PCE can get the LSPs information by itself hand, a stateful PCE can get the LSPs information by itself given
given that the LSP identifier(s) and can achieve the goal of finding that the LSP identifier(s) and can achieve the goal of finding SRLG-
SRLG-diversified protection paths for both LSPs. This is made diversified protection paths for both LSPs. This is made possible by
possible by comparing the LSP resource usage exploiting the LSP-DB comparing the LSP resource usage exploiting the LSP-DB accessible by
accessible by the stateful PCE. the stateful PCE.
5.4.2. Restoration 5.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].
If a stateless PCE is exploited, it might respond to the rerouting If a stateless PCE is used, it might respond to the rerouting
requests separately if they arrive at different times. Thus, it requests separately if they arrive at different times. Thus, it
might result in sub-optimal resource usage. Even worse, it might might result in sub-optimal resource usage. Even worse, it might
unnecessarily block some of the rerouting requests due to unnecessarily block some of the rerouting requests due to
insufficient resources for later-arrived rerouting messages. If a insufficient resources for later-arrived rerouting messages. If a
passive stateful PCE is used to fulfill this task, the procedure can passive stateful PCE is used to fulfill this task, the procedure can
be simplified. The PCCs reporting the failures can include LSP be simplified. The PCCs reporting the failures can include LSP
identifiers instead of detailed information and the PCE can find identifiers instead of detailed information and the PCE can find
relevant LSP information by inspecting the LSP-DB. Moreover, the PCE relevant LSP information by inspecting the LSP-DB. Moreover, the PCE
can re-compute the affected LSPs concurrently while reusing part of can re-compute the affected LSPs concurrently while reusing part of
the existing LSPs resources when it is informed of the failed link the existing LSPs resources when it is informed of the failed link
skipping to change at page 18, line 47 skipping to change at page 19, line 7
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
stateless PCE since it does not possess the detailed information of stateless PCE since it does not possess the detailed information of
existing LSPs in the network. existing LSPs in the network.
Another case of particular interest is the optical spectrum Another case of particular interest is the optical spectrum
defragmentation in flexible grid networks. In Flexible grid networks defragmentation in flexible grid networks. In Flexible grid networks
[I-D.ietf-ccamp-flexi-grid-fwk], LSPs with different optical spectrum [RFC7698], LSPs with different optical spectrum sizes (such as
sizes (such as 12.5GHz, 25GHz etc.) can co-exist so as to accommodate 12.5GHz, 25GHz etc.) can co-exist so as to accommodate the services
the services with different bandwidth requests. Therefore, even if with different bandwidth requests. Therefore, even if the overall
the overall spectrum size can meet the service request, it may not be spectrum size can meet the service request, it may not be usable if
usable if the available spectrum resource is not contiguous, but the available spectrum resource is not contiguous, but rather
rather fragmented into smaller pieces. Thus, with the help of fragmented into smaller pieces. Thus, with the help of existing LSP
existing LSP state information, a stateful PCE can make the resource state information, a stateful PCE can make the resource grouped
grouped together to be usable. Moreover, a stateful PCE can together to be usable. Moreover, a stateful PCE can proactively
proactively choose routes for upcoming path requests to reduce the choose routes for upcoming path requests to reduce the chance of
chance of spectrum fragmentation. spectrum fragmentation.
5.8. Point-to-Multi-Point Applications 5.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 5.1, Section 5.4 and Section 5.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
skipping to change at page 20, line 16 skipping to change at page 20, line 23
spacing such as 300GHz spacing may be needed. Hence, the spacing such as 300GHz spacing may be needed. Hence, the
characteristics (states) of the existing wavelength LSPs should be characteristics (states) of the existing wavelength LSPs should be
considered for a new RWA request in WSON. considered for a new RWA request in WSON.
In summary, when stateful PCEs are used to perform the IA-RWA In summary, when stateful PCEs are used to perform the IA-RWA
procedure, they need to know the characteristics of the existing procedure, they need to know the characteristics of the existing
wavelength LSPs. The impairment information relating to existing and wavelength LSPs. The impairment information relating to existing and
to-be-established LSPs can be obtained by nodes in WSON networks via to-be-established LSPs can be obtained by nodes in WSON networks via
external configuration or other means such as monitoring or external configuration or other means such as monitoring or
estimation based on a vendor-specific impair model. However, WSON estimation based on a vendor-specific impair model. However, WSON
related routing protocols, i.e., related routing protocols, i.e., [RFC7688] and [RFC7580], only
[I-D.ietf-ccamp-wson-signal-compatibility-ospf] and advertise limited information (i.e., availability) of the existing
[I-D.ietf-ccamp-gmpls-general-constraints-ospf-te], only advertise wavelengths, without defining the supported client bit rates. It
limited information (i.e., availability) of the existing wavelengths, will incur substantial amount of control plane overhead if routing
without defining the supported client bit rates. It will incur protocols are extended to support dissemination of the new
substantial amount of control plane overhead if routing protocols are information relevant for the IA-RWA process. In this scenario,
extended to support dissemination of the new information relevant for stateful PCE(s) would be a more appropriate mechanism to solve this
the IA-RWA process. In this scenario, stateful PCE(s) would be a problem. Stateful PCE(s) can exploit impairment information of LSPs
more appropriate mechanism to solve this problem. Stateful PCE(s) stored in LSP-DB to provide accurate RWA calculation.
can exploit impairment information of LSPs stored in LSP-DB to
provide accurate RWA calculation.
6. Security Considerations 6. Security Considerations
The PCEP extensions in support of stateful PCE and the delegation of The PCEP extensions in support of stateful PCE and the delegation of
path control, result in more information being available for a path control, result in more information being available for a
hypothetical adversary and a number of additional attack surfaces hypothetical adversary and a number of additional attack surfaces
which must be protected. [I-D.ietf-pce-stateful-pce] discusses which must be protected. [I-D.ietf-pce-stateful-pce] discusses
different attack vectors and defines protocol mechanisms to protect different attack vectors and defines protocol mechanisms to protect
against them. It also lays out implementation requirements for against them. It also lays out implementation requirements for
configuration capabilities that allow the operator to control the PCC configuration capabilities that allow the operator to control the PCC
skipping to change at page 22, line 22 skipping to change at page 22, line 29
9. Acknowledgements 9. 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 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-pce-questions]
Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", draft-ietf-pce-
questions-08 (work in progress), October 2014.
[I-D.ietf-pce-stateful-pce] [I-D.ietf-pce-stateful-pce]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful- Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-11 (work in progress), April 2015. pce-14 (work in progress), March 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>.
10.2. Informative References [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", RFC 7399,
[I-D.ietf-ccamp-flexi-grid-fwk] DOI 10.17487/RFC7399, October 2014,
Dios, O. and R. Casellas, "Framework and Requirements for <http://www.rfc-editor.org/info/rfc7399>.
GMPLS-based control of Flexi-grid DWDM networks", draft-
ietf-ccamp-flexi-grid-fwk-07 (work in progress), August
2015.
[I-D.ietf-ccamp-gmpls-general-constraints-ospf-te]
Zhang, F., Lee, Y., Han, J., Bernstein, G., and Y. Xu,
"OSPF-TE Extensions for General Network Element
Constraints", draft-ietf-ccamp-gmpls-general-constraints-
ospf-te-10 (work in progress), March 2015.
[I-D.ietf-ccamp-wson-signal-compatibility-ospf] 10.2. Informative References
Lee, Y. and G. Bernstein, "GMPLS OSPF Enhancement for
Signal and Network Element Compatibility for Wavelength
Switched Optical Networks", draft-ietf-ccamp-wson-signal-
compatibility-ospf-17 (work in progress), August 2015.
[I-D.ietf-pce-gmpls-pcep-extensions] [I-D.ietf-pce-gmpls-pcep-extensions]
Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for
GMPLS", draft-ietf-pce-gmpls-pcep-extensions-11 (work in GMPLS", draft-ietf-pce-gmpls-pcep-extensions-11 (work in
progress), October 2015. 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-05 (work in
progress), October 2015.
[I-D.ietf-pce-stateful-sync-optimizations] [I-D.ietf-pce-stateful-sync-optimizations]
Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", draft- Synchronization Procedures for a Stateful PCE", draft-
ietf-pce-stateful-sync-optimizations-03 (work in ietf-pce-stateful-sync-optimizations-05 (work in
progress), October 2015. progress), April 2016.
[I-D.sivabalan-pce-disco-stateful]
Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions
for Stateful PCE Discovery", draft-sivabalan-pce-disco-
stateful-03 (work in progress), January 2014.
[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,
skipping to change at page 24, line 39 skipping to change at page 24, line 28
(P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671,
DOI 10.17487/RFC5671, October 2009, DOI 10.17487/RFC5671, October 2009,
<http://www.rfc-editor.org/info/rfc5671>. <http://www.rfc-editor.org/info/rfc5671>.
[RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, [RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku,
"Framework for GMPLS and Path Computation Element (PCE) "Framework for GMPLS and Path Computation Element (PCE)
Control of Wavelength Switched Optical Networks (WSONs)", Control of Wavelength Switched Optical Networks (WSONs)",
RFC 6163, DOI 10.17487/RFC6163, April 2011, RFC 6163, DOI 10.17487/RFC6163, April 2011,
<http://www.rfc-editor.org/info/rfc6163>. <http://www.rfc-editor.org/info/rfc6163>.
Authors' Addresses [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,
<http://www.rfc-editor.org/info/rfc7580>.
[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,
<http://www.rfc-editor.org/info/rfc7688>.
[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,
<http://www.rfc-editor.org/info/rfc7698>.
Authors' Addresses
Xian Zhang (editor) Xian Zhang (editor)
Huawei Technologies Huawei Technologies
F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District
Shenzhen, Guangdong 518129 Shenzhen, Guangdong 518129
P.R.China P.R.China
Email: zhang.xian@huawei.com Email: zhang.xian@huawei.com
Ina Minei (editor) Ina Minei (editor)
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US US
Email: inaminei@google.com Email: inaminei@google.com
 End of changes. 28 change blocks. 
89 lines changed or deleted 94 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/