Applicability of a Stateful Path Computation Element (PCE) Huawei TechnologiesF3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District
ShenzhenGuangdong518129P.R.Chinazhang.xian@huawei.comGoogle, Inc.1600 Amphitheatre ParkwayMountain ViewCA94043USinaminei@google.comPCE Working Group
A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP)
characteristics and resource usage within a network in order to provide traffic engineering
calculations for its associated Path Computation Clients (PCCs). This document describes general
considerations for a stateful PCE deployment and examines its applicability and benefits, as well
as its challenges and limitations through a number of use cases. PCE Communication Protocol
(PCEP) extensions required for stateful PCE usage are covered in separate documents.
defines the architecture for a Path Computation Element
(PCE)-based model for the computation of Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs).
To perform such a constrained computation, a PCE stores the network topology
(i.e., TE links and nodes) and resource information (i.e., TE attributes) in
its TE Database (TED). describes the Path Computation Element
Protocol (PCEP) for interaction between a Path Computation Client (PCC) and a PCE,
or between two PCEs, enabling computation of TE LSPs. Extensions for support of GMPLS in
PCEP are defined in .
As per , a PCE can be either stateful or stateless. A stateful PCE
maintains two sets of information for use in path computation. The first is the Traffic
Engineering Database (TED) which includes the topology and resource state in the network.
This information can be obtained by a stateful PCE using the same mechanisms as a stateless
PCE (see ). The second is the LSP State Database (LSP-DB),
in which a PCE stores attributes of all active LSPs in the network, such as their paths
through the network, bandwidth/resource usage, switching types and LSP constraints.
This state information allows the PCE to compute constrained paths while considering individual LSPs
and their inter-dependency. However, this requires reliable state synchronization mechanisms
between the PCE and the network, between the PCE and the PCCs, and between cooperating PCEs,
with potentially significant control plane overhead and maintenance of
a large amount of state data, as explained in .
This document describes how a stateful PCE can be used to solve various problems
for MPLS-TE and GMPLS networks, and the benefits it brings to such deployments.
Note that alternative solutions relying on stateless PCEs may also be
possible for some of these use cases, and will be mentioned for completeness
where appropriate.
This document uses the following terms defined in : PCC, PCE, PCEP peer.This document uses the following terms defined in
: 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:
the minimum set of links for a specific
source destination pair which, when removed from the network, results in
a specific source being completely isolated from specific destination.
The summed capacity of these links is equivalent to the maximum capacity
from the source to the destination by the max-flow min-cut theorem. This section is included for the convenience of the reader, please refer to the
referenced documents for details of the operation.
specifies a set of extensions to PCEP to enable stateful
control of LSPs within and across PCEP sessions in compliance with
. 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. 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 .
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:
both the PCC and the
PCE must announce during PCEP session establishment that they support
stateful PCE PCEP extensions. 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. A PCE requests the modification of
one or more attributes (e.g., route) on a PCC's LSP. a PCC sends an LSP state report
to a PCE whenever the state of an LSP changes. 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. 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. defines the extensions
needed to support auto-discovery of stateful PCEs when using IGP for PCE discovery. This section discusses generic issues with stateful PCE deployments, and
how specific protocol mechanisms can be used to address them.
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 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. describes
how LSPs can be re-delegated between PCEs, and the procedures on a PCE failure.
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. The population of the LSP-DB using information received from PCCs is supported by
the stateful PCE extensions defined in
, 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. 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. For a stateful PCE, an important issue is to get the LSP state information
resynchronized after a restart. defines a
synchronization function and procedure, allowing a PCC to synchronize its LSP
state with the PCE and 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.
In the following sections, several use cases are described, showcasing
scenarios that benefit from the deployment of a stateful PCE. The following use cases demonstrate a need for visibility into
global LSP states in PCE path computations, and for a PCE
control of sequence and timing in altering LSP path characteristics
within and across PCEP sessions. Reference topologies for the use
cases described later in this section are shown in Figures and .Some of the use cases below are focused on MPLS-TE deployments, but may
also apply to GMPLS. Unless otherwise cited, use cases assume that all LSPs
listed exist at the same LSP priority.
The main benefit in the cases below comes from moving away from an asynchronous
PCC-driven mode of operation to a model that allows for central control over LSP
computations and maintenance, and focuses specifically on the active stateful PCE model
of operation. Because LSP attribute changes in are
driven by Path Computation Request (PCReq) messages under control of a PCC's local timers, the
sequence of resource reservation arrivals occurring in the network will
be randomized. This, coupled with a lack of global LSP state
visibility on the part of a stateless PCE may result in suboptimal
throughput in a given network topology, as will be shown in the example
below.
Reference topology 2 in and
Tables
and show an
example in which throughput is at 50% of optimal as a result of lack
of visibility and synchronized control across PCC's. In this
scenario, the decision must be made as to whether to route any
portion of the E-G demand, as any demand routed for this source and
destination will decrease system throughput. LinkMetricCapacityA-E110B-F110C-G110E-F110F-G110TimeLSPSrcDstDemandRoutablePath11EG10YesE-F-G22AB10No---31FC10No---In many cases throughput maximization becomes a bin packing
problem. While bin packing itself is an NP-hard problem, a number of
common heuristics which run in polynomial time can provide
significant improvements in throughput over random reservation event
distribution, especially when traversing links which are members of
the minimum cut set for a large subset of source destination pairs.
Tables
and show a simple
use case using Reference Topology 1 in , where LSP state visibility and
control of reservation order across PCCs would result in significant
improvement in total throughput.LinkMetricCapacityA-C110B-C110C-E105C-D110D-E110TimeLSPSrcDstDemandRoutablePath11AE5YesA-C-D-E22BE10No---This section discusses a use case of cross-LSP impact under
degraded operation. Most existing RSVP-TE implementations will not
tear down established LSPs in the event of the failure of the bandwidth
increase procedure detailed in . This
behavior is directly implied to be correct in and is often desirable from an operator's
perspective, because either a) the destination prefixes are not
reachable via any means other than MPLS or b) this would result in
significant packet loss as demand is shifted to other LSPs in the
overlay mesh.In addition, there are currently few implementations offering
dynamic ingress admission control (policing of the traffic volume mapped
onto an LSP) at the label edge router (LER). Having ingress admission control on a per LSP basis
is not necessarily desirable from an operational perspective, as a) one must
over-provision tunnels significantly in order to avoid deleterious effects
resulting from stacked transport and flow control systems (for
example for tunnels that are dynamically resized based on current traffic) and b)
there is currently no efficient commonly available northbound interface for dynamic
configuration of per LSP ingress admission control.Lack of ingress admission control coupled with the behavior in
may result in LSPs operating
out of profile for significant periods of time. It is reasonable to
expect that these out-of-profile LSPs will be operating in a degraded
state and experience traffic loss, but because they
end up sharing common network interfaces with other LSPs operating within
their bandwidth reservations, thus impacting the operation
of the in-profile LSPs, even when there is unused network capacity elsewhere
in the network. Furthermore, this behavior will cause information loss
in the TED with regards to the actual available bandwidth on the links
used by the out-of-profile LSPs, as the reservations on the links no longer
reflect the capacity used.
Reference Topology 1 in and
Tables
and show a use
case that demonstrates this behavior. Two LSPs, LSP 1 and LSP 2 are
signaled with demand 2 and routed along paths A-C-D-E and B-C-D-E
respectively. At a later time, the demand of LSP 1 increases to
20. Under such a demand, the LSP cannot be resignaled. However, the
existing LSP will not be torn down. In the absence of ingress
policing, traffic on LSP 1 will cause degradation for traffic of LSP
2 (due to oversubscription on the links C-D and D-E), as well as
information loss in the TED with regard to the actual network
state.The problem could be easily ameliorated by global visibility of
LSP state coupled with PCC-external demand measurements and
placement of two LSPs on disjoint links. Note that while the demand
of 20 for LSP 1 could never be satisfied in the given topology, what
could be achieved would be isolation from the ill-effects of the
(unsatisfiable) increased demand.LinkMetricCapacityA-C110B-C110C-E105C-D110D-E110TimeLSPSrcDstDemandRoutablePath11AE2YesA-C-D-E22BE2YesB-C-D-E31AE20No---As a result of both the lack of visibility into global LSP state
and the lack of control over event ordering across PCE sessions,
unnecessary perturbations may be introduced into the network by a
stateless PCE. Tables and show an example of an unnecessary network
perturbation using Reference Topology 1 in . In this case an unimportant (high
LSP priority value) LSP (LSP1) is first set up along the shortest
path. At time 2, which is assumed to be relatively close to time 1,
a second more important (lower LSP-priority value) LSP (LSP2) is
established, preempting LSP1, potentially causing traffic loss.
LSP1 is then reestablished on the longer A-C-E path.LinkMetricCapacityA-C110B-C110C-E1010C-D110D-E110TimeLSPSrcDstDemandLSP PrioRoutablePath11AE77YesA-C-D-E22BE70YesB-C-D-E31AE77YesA-C-E A stateful PCE can help in this scenario by computing both routes at the same
time. The advantages of using a stateful PCE over exploiting a stateless PCE via
Global Concurrent Optimization(GCO) are three folds.
First is the ability to accommodate concurrent path computation from different PCCs.
Second is the reduction of control plane overhead since the stateful PCE has the route
information of the affected LSPs. Thirdly, the stateful PCE can use the LSP-DB to
further optimize the placement of LSPs. This will ensure placement of the more important
LSP along the shortest path, avoiding the setup and subsequent preemption of the lower
priority LSP. Similarly, when a new higher priority
LSP which requires preemption of existing lower priority LSP(s),
a stateful PCE can determine the minimum number of
lower priority LSP(s) to reroute using the make-before-break (MBB)
mechanism without disrupting any service and then set up the higher
priority LSP.Randomization of reservation events caused by lack of control
over event ordering across PCE sessions results in poor
predictability in LSP routing. An offline system applying a
consistent optimization method will produce predictable results to
within either the boundary of forecast error (when reservations are
over-provisioned by reasonable margins) or to the variability of the
signal and the forecast error (when applying some hysteresis in order
to minimize churn). Predictable results are valuable for being able to
simulate the network and reliably test it under various scenarios, especially under various
failure modes and planned maintenances when predictable path characteristics are desired
under contention for network resources.Reference Topology 1 and Tables , and show the impact of
event ordering and predictability of LSP routing.LinkMetricCapacityA-C110B-C110C-E110C-D110D-E110TimeLSPSrcDstDemandRoutablePath11AE7YesA-C-E22BE7YesB-C-D-ETimeLSPSrcDstDemandRoutablePath12BE7YesB-C-E21AE7YesA-C-D-E As can be shown in the example, both LSPs are routed in both cases,
but along very different paths. This would be a challenge if reliable simulation
of the network is attempted. A stateful PCE can solve this through control over
LSP ordering.
The bandwidth requirement of LSPs often change over time, requiring resizing the LSP. In most
implementations available today, the head-end node performs this function by monitoring
the actual bandwidth usage, triggering
a recomputation and resignaling when a threshold is reached. This operation is referred as
auto-bandwidth adjustment. The head-end node either recomputes the path locally, or it requests a
recomputation from a PCE by sending a PCReq message. In the latter case,
the PCE computes a new path and provides the new route suggestion. Upon receiving the reply from
the PCE, the PCC re-signals the LSP in Shared-Explicit (SE) mode along the newly computed path.
With a stateless PCE, the head-end node needs to provide the current used bandwidth and the route information via path computation request messages.
Note that in this scenario, the head-end node is the one that drives the LSP resizing based
on local information, and that the difference between using a stateless and a passive
stateful PCE is in the level of optimization of the LSP placement as discussed in the previous
section. A more interesting smart bandwidth adjustment case is one where the LSP resizing decision
is done by an external entity, with access to additional information such as historical trending
data, application-specific information about expected demands or policy information, as well
as knowledge of the actual desired flow volumes. In this case an active stateful PCE provides
an advantage in both the computation with knowledge of all LSPs in the domain and in the ability
to trigger bandwidth modification of the LSP.
Bandwidth scheduling allows network operators to reserve resources in advance
according to the agreements with their customers, and allow them to transmit data with
specified starting time and duration, for example for a scheduled bulk data replication
between data centers. Traditionally, this can be supported by network management system (NMS) operation through path pre-establishment
and activation on the agreed starting time. However, this does not provide efficient
network usage since the established paths exclude the possibility of being used by other
services even when they are not used for undertaking any service. It can also be accomplished
through GMPLS protocol extensions by carrying the related request information (e.g.,
starting time and duration) across the network. Nevertheless, this method inevitably
increases the complexity of signaling and routing process. A passive stateful PCE can support this application with better efficiency since it can
alleviate the burden of processing on network elements. This requires the PCE to maintain
the scheduled LSPs and their associated resource usage, as well as the ability of head-ends
to trigger signaling for LSP setup/deletion at the correct time. This approach requires coarse time
synchronization between PCEs and PCCs. If an active stateful PCE is available, the PCE can
trigger the setup/deletion of scheduled requests in a centralized manner, as specified
,
without modification of existing head-end behaviors, by notifying the PCCs to
set up or tear down the paths. The recovery use cases discussed in the following sections show how leveraging a stateful PCE
can simplify the computation of recovery path(s). In particular, two characteristics
of a stateful PCE are used: 1) using information stored in the LSP-DB for determining
shared protection resources and 2) performing computations with knowledge
of all LSPs in a domain.
If a PCC can specify in a request whether the computation is for a working path or for protection,
and a PCC can report the resource as a working or protection path, then the following text applies.
A PCC can send multiple requests to the PCE, asking for two LSPs and use them as working
and backup paths separately. Either way, the resources bound to backup paths can be shared by
different LSPs to improve the overall network efficiency, such as m:n protection or
pre-configured shared mesh recovery techniques as specified in .
If resource sharing is supported for LSP protection, the information relating to existing LSPs
is required to avoid allocation of shared protection resources to two LSPs that might fail
together and cause protection contention issues. A stateless PCE can accommodate this use case by
having the PCC pass this information as a constraint in the path computation request.
A passive stateful PCE can more easily accommodate this need using the information stored in its LSP-DB.
Furthermore, an active stateful PCE can help with (re)-optimizization of protection
resource sharing as well as LSP maintenance operation with fewer impact on protection resources.
For example, in the network depicted in Figure ,
suppose there exists LSP1 with working path LSP1_working following A->E and with backup path
LSP1_backup following A->B->E. A request arrives asking for a working and backup path pair to be
computed for LSP2 from B to E. If the PCE decides LSP2_working follows B->A->E,
then the backup path LSP2_backup should not share the same protection resource with LSP1
since LSP2 shares part of its resource (specifically A->E) with LSP1 (i.e., these two LSPs are in
the same shared risk group). There is no such constraint if B->C->D->E is
chosen for LSP2_working.
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 details of their
protection resources. B must pass this information to the PCE as a constraint
so as to request a path with diversity. Alternatively, a stateless PCE may able to
compute Shared Risk Link Group (SRLG)-diversified paths if TED is extended so that it includes the SRLG information
that are protected by a given backup resource, but at the expense of a high complexity in routing.
On the other hand, a stateful PCE can get the LSPs information by itself given that the LSP
identifier(s) and can achieve the goal
of finding SRLG-diversified protection paths for both LSPs. This is made possible by comparing
the LSP resource usage exploiting the LSP-DB accessible by the stateful PCE.
In case of a link failure, such as a fiber cut, multiple LSPs may fail at the same time. Thus,
the source nodes of the affected LSPs will be informed of the failure by the nodes detecting the
failure. These source nodes will send requests to a PCE for rerouting. In order to reuse the
resource taken by an existing LSP, the source node can send a PCReq message including the
Exclude Route Object (XRO) with Fail (F) bit set, together with the record route object (RRO) containing the
current route information, as specified in .
If a stateless PCE is used, it might respond to the rerouting requests separately if they
arrive at different times. Thus, it might result in sub-optimal resource usage. Even worse,
it might unnecessarily block some of the rerouting requests due to insufficient resources for
later-arrived rerouting messages. If a passive stateful PCE is used to fulfill this task, the
procedure can be simplified. The PCCs reporting the failures can include LSP identifiers instead
of detailed information and the PCE can find relevant LSP information by inspecting the LSP-DB.
Moreover, the PCE can
re-compute the affected LSPs concurrently while reusing part of the existing LSPs resources
when it is informed of the failed link identifier provided by the first request. This is made
possible since the passive stateful PCE can check what other LSPs are affected by the failed link and
their route information by inspecting its LSP-DB. As a result, a better performance can be
achieved, such as better resource usage or minimal probability of blocking upcoming new rerouting
requests sent as a result of the link failure.
If the target is to avoid resource contention within the time-window of high number of LSP rerouting
requests, a stateful PCE can retain the under-construction LSP resource usage information for
a given time and exclude it from being used for forthcoming LSPs request. In this way,
it can ensure that the resource will not be double-booked and thus the issue of resource
contention and computation crank-backs can be alleviated.
An alternative way to achieve efficient resilience is to maintain SRLG disjointness between LSPs,
irrespective of whether these LSPs share the source and destination nodes or not. This can be achieved
at provisioning time, if the routes of all the LSPs are requested together,
using a synchronized computation of the different LSPs with SRLG disjointness constraint. If the LSPs
need to be provisioned at different times, the PCC can specify, as constraints to the path computation a set
of SRLGs using the Exclude Route Object .
However, for the latter to be effective, it is needed that the entity
that requests the route to the PCE maintains updated SRLG information of all the LSPs to which
it must maintain the disjointness. A stateless PCE can compute an SRLG-disjoint path by inspecting
the TED and precluding the links with the same SRLG values specified in the PCReq message sent by a PCC.
A passive stateful PCE maintains the updated SRLG information of the established LSPs
in a centralized manner. Therefore, the PCC can specify as constraints to the path
computation the SRLG disjointness of a set of already established LSPs by only providing the LSP
identifiers. Similarly, a passive stateful PCE can also accommodate disjointness using
other constraints, such as link, node or path segment etc.
In Multi-Layer Networks (MLN), a Virtual Network Topology (VNT)
consists of a set of one or more TE LSPs in the lower
layer which provides TE links to the upper layer. In
, the PCE-based architecture is proposed to
support path computation in MLN networks in order to achieve inter-layer TE.
The establishment/teardown of a TE link in VNT needs to take into
consideration the state of existing LSPs and/or new LSP request(s) in
the higher layer. Hence, when a stateless PCE cannot find the
route for a request based on the upper layer topology information, it
does not have enough information to decide whether to set up or
remove a 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 better
decision of when and how to modify the VNT either to accommodate new LSP
requests or to re-optimize resource usage across layers irrespective
of the PCE models as described in . Furthermore,
given the active capability, the stateful PCE can issue VNT
modification suggestions in order to accommodate path setup requests
or re-optimize resource usage across layers.
In order to make efficient usage of network resources,
it is sometimes desirable to re-optimize one or more
LSPs dynamically.
In the case of a stateless PCE, in order to optimize network
resource usage dynamically through online planning, a PCC
must send a request to the PCE together with
detailed path/bandwidth information of the LSPs that need to
be concurrently optimized. This means the PCC must be able
to determine when and which LSPs should be
optimized.
In the case of a passive stateful PCE, given the LSP state information in the LSP
database, the process of dynamic optimization of network resources
can be simplified without requiring the PCC to supply detailed LSP state
information. Moreover, an active stateful PCE can even make the process
automated by triggering the request since a stateful
PCE can maintain information for all LSPs that are in the process of
being set up and it may have the ability to control timing and
sequence of LSP setup/deletion, the optimization procedures can be
performed more intelligently and effectively. A stateful PCE can also determine which LSP
should be re-optimized based on network events. For example, when
a LSP is torn down, its resources are freed. This can trigger
the stateful PCE to automatically determine which LSP should
be reoptimized so that the recently freed resources may be allocated to it.
A special case of LSP re-optimization is GCO .
Global control of LSP operation sequence in is predicated on the use of what is
effectively a stateful (or semi-stateful) NMS. The NMS can
be either not local to the network nodes, in which case another
northbound interface is required for LSP attribute changes,
or local/collocated, in which case there are significant
issues with efficiency in resource usage.
A stateful PCE adds a few features that:
Roll the NMS visibility into the PCE and remove the
requirement for an additional northbound interface Allow the PCE to determine when re-optimization is
needed, with which level (GCO or a more incremental optimization) Allow the PCE to determine which LSPs should be re-optimized Allow a PCE to control the sequence of events across multiple
PCCs, allowing for bulk (and truly global) optimization, LSP shuffling etc.
If LSPs are dynamically allocated and released over time,
the resource becomes fragmented. In networks with link bundle, the overall available resource on
a (bundle) link might
be sufficient for a new LSP request, but if the available resource is not continuous,
the request is rejected. In order to perform the defragmentation procedure,
stateful PCEs can be used, since global visibility of LSPs in the network is required to accurately
assess resources on the LSPs, and perform de-fragmentation while ensuring a minimal
disruption of the network. This use case cannot be accommodated
by a stateless PCE since it does not possess the detailed information of existing LSPs in the network.
Another case of particular interest is the optical spectrum defragmentation in flexible grid networks.
In Flexible grid networks , LSPs with different
optical spectrum sizes (such as 12.5GHz, 25GHz etc.) can co-exist so as to accommodate the
services with different bandwidth requests. Therefore, even if the overall spectrum size can
meet the service request, it may not be usable if the available spectrum resource is not contiguous,
but rather fragmented into smaller pieces. Thus, with the help of existing LSP state information,
a stateful PCE can make the resource grouped
together to be usable. Moreover, a stateful PCE can proactively choose routes for upcoming
path requests to reduce the chance of spectrum fragmentation.
PCE has been identified as an appropriate technology for the determination of the paths
of point-to-multipoint (P2MP) TE LSPs . The application scenarios and
use-cases described in ,
and
are also applicable to P2MP TE LSPs. In addition to these, the stateful nature of a PCE simplifies the information conveyed in
PCEP messages since it is possible to refer to the LSPs via an identifier. For P2MP, this is an
added advantage, where the size of the PCEP message is much larger. In case of stateless PCEs,
modification of a P2MP tree requires encoding of all leaves along with the paths in PCReq message.
But using a stateful PCE with P2MP capability, the PCEP message can be used to convey only the
modifications (the other information can be retrieved from the identifier via the LSP-DB).In Wavelength Switched Optical Networks (WSONs) , a wavelength-switched
LSP traverses one or more fiber links.
The bit rates of the client signals carried by the wavelength LSPs may be the same or different.
Hence, a fiber link may transmit a number of wavelength LSPs with equal or mixed bit rate signals.
For example, a fiber link may multiplex the wavelengths with only 10Gb/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) that takes
into account the optical layer/transmission imperfections by considering as additional
(i.e., physical layer) constraints. To be more specific, linear and non-linear effects
associated with the optical network elements should be incorporated into the route and
wavelength assignment procedure. For example, the physical imperfection can result in
the interference of two adjacent lightpaths. Thus, a guard band should be reserved between
them to alleviate these effects. The width of the guard band between two adjacent wavelengths
depends on their characteristics, such as modulation formats and bit rates. Two adjacent
wavelengths with different characteristics (e.g., different bit rates) may need a wider guard
band and with same characteristics may need a narrower guard band. For example,
50GHz spacing may be acceptable for two adjacent wavelengths with 40G signals. But for
two adjacent wavelengths with different bit rates (e.g., 10G and 40G), a larger spacing
such as 300GHz spacing may be needed. Hence, the characteristics (states) of the existing
wavelength LSPs should be considered for a new RWA request in WSON. In summary, when stateful PCEs are used to perform the IA-RWA procedure, they need to
know the characteristics of the existing wavelength LSPs. The impairment information relating
to existing and to-be-established LSPs can be obtained by nodes in WSON networks via external
configuration or other means such as monitoring or estimation based on a vendor-specific
impair model. However, WSON related routing protocols, i.e.,
and ,
only advertise limited information (i.e., availability) of the existing wavelengths,
without defining the supported client bit rates. It will incur substantial amount of control
plane overhead if routing protocols are extended to support dissemination of the new
information relevant for the IA-RWA process. In this scenario, stateful PCE(s) would be a more
appropriate mechanism to solve this problem. Stateful PCE(s) can exploit impairment
information of LSPs stored in LSP-DB to provide accurate RWA calculation. The PCEP extensions in support of stateful PCE and the delegation of path control,
result in more information being available for a hypothetical adversary and a number
of additional attack surfaces which must be protected.
discusses 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
.This document does not require any IANA action.
The following people all contributed significantly to this document and are listed below in
alphabetical order:
Ramon Casellas
CTTC - Centre Tecnologic de Telecomunicacions de Catalunya
Av. Carl Friedrich Gauss n7
Castelldefels, Barcelona 08860
Spain
Email: ramon.casellas@cttc.es
Edward Crabbe
Email: edward.crabbe@gmail.com
Dhruv Dhody
Huawei Technology
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: dhruv.dhody@huawei.com
Oscar Gonzalez de Dios
Telefonica Investigacion y Desarrollo
Emilio Vargas 6
Madrid, 28045
Spain
Phone: +34 913374013
Email: ogondio@tid.es
Young Lee
Huawei
1700 Alma Drive, Suite 100
Plano, TX 75075
US
Phone: +1 972 509 5599 x2240
Fax: +1 469 229 5397
EMail: leeyoung@huawei.com
Jan Medved
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
US
Email: jmedved@cisco.com
Robert Varga
Pantheon Technologies LLC
Mlynske Nivy 56
Bratislava 821 05
Slovakia
Email: robert.varga@pantheon.sk
Fatai Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972912
Email: zhangfatai@huawei.com
Xiaobing Zi
Email: unknown
We would like to thank Cyril Margaria, Adrian Farrel, JP Vasseur and Ravi Torvi for the useful comments and discussions.