pre-selected or selected on-demand.
Recovery LSP provisioning phases:
(1) Path Computation --> On-demand
|
|
--> Pre-Computed
|
|
(2) Signaling --> On-demand
|
|
--> Pre-Signaled
|
|
(3) Resource Selection --> On-demand
|
|
--> Pre-Selected
Note that these different options lead to different LSP/span recovery
times. The following sections will consider the above-mentioned
pre-provisioning options when analyzing the different recovery
mechanisms.
2. Overbooking
There are many mechanisms available that allow the overbooking of the
recovery resources. This overbooking can be done per LSP (as in the
example mentioned above), per link (such as span protection), or even
per domain. In all these cases, the level of overbooking, as shown
in the below figure, can be classified as dedicated (such as 1+1 and
1:1), shared (such as 1:N and M:N), or unprotected (and thus
restorable, if enough recovery resources are available).
Overbooking levels:
+----- Dedicated (for instance: 1+1, 1:1, etc.)
|
|
+----- Shared (for instance: 1:N, M:N, etc.)
|
Level of |
Overbooking -----+----- Unprotected (for instance: 0:1, 0:N)
Also, when using shared recovery, one may support preemptible extra-
traffic; the recovery mechanism is then expected to allow preemption
of this low priority traffic in case of recovery resource contention
during recovery operations. The following sections will consider the
above-mentioned overbooking options when analyzing the different
recovery mechanisms.
5.5.2. LSP Restoration
The following times are defined to provide a quantitative estimation
about the time performance of the different LSP restoration
mechanisms (also referred to as LSP re-routing):
- Path Computation Time: Tc
- Path Selection Time: Ts
- End-to-end LSP Resource Reservation Time: Tr (a delta for resource
selection is also considered, the corresponding total time is then
referred to as Trs)
- End-to-end LSP Resource Activation Time: Ta (a delta for
resource selection is also considered, the corresponding total
time is then referred to as Tas)
The Path Selection Time (Ts) is considered when a pool of recovery
LSP paths between a given pair of source/destination end-points is
pre-computed, and after a failure occurrence one of these paths is
selected for the recovery of the LSP under failure condition.
Note: failure management operations such as failure detection,
correlation, and notification are considered (for a given failure
event) as equally time-consuming for all the mechanisms described
below:
1. With Route Pre-computation (or LSP re-provisioning)
An end-to-end restoration LSP is established after the failure(s)
occur(s) based on a pre-computed path. As such, one can define this
as an "LSP re-provisioning" mechanism. Here, one or more (disjoint)
paths for the restoration LSP are computed (and optionally pre-
selected) before a failure occurs.
No reservation or selection of resources is performed along the
restoration path before failure occurrence. As a result, there is no
guarantee that a restoration LSP is available when a failure occurs.
The expected total restoration time T is thus equal to Ts + Trs or to
Trs when a dedicated computation is performed for each working LSP.
2. Without Route Pre-computation (or Full LSP re-routing)
An end-to-end restoration LSP is dynamically established after the
failure(s) occur(s). After failure occurrence, one or more
(disjoint) paths for the restoration LSP are dynamically computed and
one is selected. As such, one can define this as a complete "LSP
re-routing" mechanism.
No reservation or selection of resources is performed along the
restoration path before failure occurrence. As a result, there is no
guarantee that a restoration LSP is available when a failure occurs.
The expected total restoration time T is thus equal to Tc (+ Ts) +
Trs. Therefore, time performance between these two approaches
differs by the time required for route computation Tc (and its
potential selection time, Ts).
5.5.3. Pre-Planned LSP Restoration
Pre-planned LSP restoration (also referred to as pre-planned LSP re-
routing) implies that the restoration LSP is pre-signaled. This in
turn implies the reservation of recovery resources along the
restoration path. Two cases can be defined based on whether the
recovery resources are pre-selected.
1. With resource reservation and without resource pre-selection
Before failure occurrence, an end-to-end restoration path is pre-
selected from a set of pre-computed (disjoint) paths. The
restoration LSP is signaled along this pre-selected path to reserve
resources at each node, but these resources are not selected.
In this case, the resources reserved for each restoration LSP may be
dedicated or shared between multiple restoration LSPs whose working
LSPs are not expected to fail simultaneously. Local node policies
can be applied to define the degree to which these resources can be
shared across independent failures. Also, since a restoration scheme
is considered, resource sharing should not be limited to restoration
LSPs that start and end at the same ingress and egress nodes.
Therefore, each node participating in this scheme is expected to
receive some feedback information on the sharing degree of the
recovery resource(s) that this scheme involves.
Upon failure detection/notification message reception, signaling is
initiated along the restoration path to select the resources, and to
perform the appropriate operation at each node crossed by the
restoration LSP (e.g., cross-connections). If lower priority LSPs
were established using the restoration resources, they must be
preempted when the restoration LSP is activated.
Thus, the expected total restoration time T is equal to Tas (post-
failure activation), while operations performed before failure
occurrence take Tc + Ts + Tr.
2. With both resource reservation and resource pre-selection
Before failure occurrence, an end-to-end restoration path is pre-
selected from a set of pre-computed (disjoint) paths. The
restoration LSP is signaled along this pre-selected path to reserve
AND select resources at each node, but these resources are not
committed at the data plane level. So that the selection of the
recovery resources is committed at the control plane level only, no
cross-connections are performed along the restoration path.
In this case, the resources reserved and selected for each
restoration LSP may be dedicated or even shared between multiple
restoration LSPs whose associated working LSPs are not expected to
fail simultaneously. Local node policies can be applied to define
the degree to which these resources can be shared across independent
failures. Also, because a restoration scheme is considered, resource
sharing should not be limited to restoration LSPs that start and end
at the same ingress and egress nodes. Therefore, each node
participating in this scheme is expected to receive some feedback
information on the sharing degree of the recovery resource(s) that
this scheme involves.
Upon failure detection/notification message reception, signaling is
initiated along the restoration path to activate the reserved and
selected resources, and to perform the appropriate operation at each
node crossed by the restoration LSP (e.g., cross-connections). If
lower priority LSPs were established using the restoration resources,
they must be preempted when the restoration LSP is activated.
Thus, the expected total restoration time T is equal to Ta (post-
failure activation), while operations performed before failure
occurrence take Tc + Ts + Trs. Therefore, time performance between
these two approaches differs only by the time required for resource
selection during the activation of the recovery LSP (i.e., Tas - Ta).
5.5.4. LSP Segment Restoration
The above approaches can be applied on an edge-to-edge LSP basis
rather than end-to-end LSP basis (i.e., to reduce the global recovery
time) by allowing the recovery of the individual LSP segments
constituting the end-to-end LSP.
Also, by using the horizontal hierarchy approach described in Section
7.1, an end-to-end LSP can be recovered by multiple recovery
mechanisms applied on an LSP segment basis (e.g., 1:1 edge-to-edge
LSP protection in a metro network, and M:N edge-to-edge protection in
the core). These mechanisms are ideally independent and may even use
different failure localization and notification mechanisms.
6. Reversion
Reversion (a.k.a. normalization) is defined as the mechanism allowing
switching of normal traffic from the recovery LSP/span to the working
LSP/span previously under failure condition. Use of normalization is
at the discretion of the recovery domain policy. Normalization may
impact the normal traffic (a second hit) depending on the
normalization mechanism used.
If normalization is supported, then 1) the LSP/span must be returned
to the working LSP/span when the failure condition clears and 2) the
capability to de-activate (turn-off) the use of reversion should be
provided. De-activation of reversion should not impact the normal
traffic, regardless of whether it is currently using the working or
recovery LSP/span.
Note: during the failure, the reuse of any non-failed resources
(e.g., LSP and/or spans) belonging to the working LSP/span is under
the discretion of recovery domain policy.
6.1. Wait-To-Restore (WTR)
A specific mechanism (Wait-To-Restore) is used to prevent frequent
recovery switching operations due to an intermittent defect (e.g.,
Bit Error Rate (BER) fluctuating around the SD threshold).
First, an LSP/span under failure condition must become fault-free,
e.g., a BER less than a certain recovery threshold. After the
recovered LSP/span (i.e., the previously working LSP/span) meets this
criterion, a fixed period of time shall elapse before normal traffic
uses the corresponding resources again. This duration called Wait-
To-Restore (WTR) period or timer is generally on the order of a few
minutes (for instance, 5 minutes) and should be capable of being set.
The WTR timer may be either a fixed period, or provide for
incrementally longer periods before retrying. An SF or SD condition
on the previously working LSP/span will override the WTR timer value
(i.e., the WTR cancels and the WTR timer will restart).
6.2. Revertive Mode Operation
In revertive mode of operation, when the recovery LSP/span is no
longer required, i.e., the failed working LSP/span is no longer in SD
or SF condition, a local Wait-to-Restore (WTR) state will be
activated before switching the normal traffic back to the recovered
working LSP/span.
During the reversion operation, since this state becomes the highest
in priority, signaling must maintain the normal traffic on the
recovery LSP/span from the previously failed working LSP/span.
Moreover, during this WTR state, any null traffic or extra traffic
(if applicable) request is rejected.
However, deactivation (cancellation) of the wait-to-restore timer may
occur if there are higher priority request attempts. That is, the
recovery LSP/span usage by the normal traffic may be preempted if a
higher priority request for this recovery LSP/span is attempted.
6.3. Orphans
When a reversion operation is requested, normal traffic must be
switched from the recovery to the recovered working LSP/span. A
particular situation occurs when the previously working LSP/span
cannot be recovered, so normal traffic cannot be switched back. In
that case, the LSP/span under failure condition (also referred to as
"orphan") must be cleared (i.e., removed) from the pool of resources
allocated for normal traffic. Otherwise, potential de-
synchronization between the control and transport plane resource
usage can appear. Depending on the signaling protocol capabilities
and behavior, different mechanisms are expected here.
Therefore, any reserved or allocated resources for the LSP/span under
failure condition must be unreserved/de-allocated. Several ways can
be used for that purpose: wait for the clear-out time interval to
elapse, initiate a deletion from the ingress or the egress node, or
trigger the initiation of deletion from an entity (such as an EMS or
NMS) capable of reacting upon reception of an appropriate
notification message.
7. Hierarchies
Recovery mechanisms are being made available at multiple (if not all)
transport layers within so-called "IP/MPLS-over-optical" networks.
However, each layer has certain recovery features, and one needs to
determine the exact impact of the interaction between the recovery
mechanisms provided by these layers.
Hierarchies are used to build scalable complex systems. By hiding
the internal details, abstraction is used as a mechanism to build
large networks or as a technique for enforcing technology,
topological, or administrative boundaries. The same hierarchical
concept can be applied to control the network survivability. Network
survivability is the set of capabilities that allow a network to
restore affected traffic in the event of a failure. Network
survivability is defined further in [RFC4427]. In general, it is
expected that the recovery action is taken by the recoverable
LSP/span closest to the failure in order to avoid the multiplication
of recovery actions. Moreover, recovery hierarchies also can be
bound to control plane logical partitions (e.g., administrative or
topological boundaries). Each logical partition may apply different
recovery mechanisms.
In brief, it is commonly accepted that the lower layers can provide
coarse but faster recovery while the higher layers can provide finer
but slower recovery. Moreover, it is also desirable to avoid similar
layers with functional overlaps in order to optimize network resource
utilization and processing overhead, since repeating the same
capabilities at each layer does not create any added value for the
network as a whole. In addition, even if a lower layer recovery
mechanism is enabled, it does not prevent the additional provision of
a recovery mechanism at the upper layer. The inverse statement does
not necessarily hold; that is, enabling an upper layer recovery
mechanism may prevent the use of a lower layer recovery mechanism.
In this context, this section analyzes these hierarchical aspects
including the physical (passive) layer(s).
7.1. Horizontal Hierarchy (Partitioning)
A horizontal hierarchy is defined when partitioning a single-layer
network (and its control plane) into several recovery domains.
Within a domain, the recovery scope may extend over a link (or span),
LSP segment, or even an end-to-end LSP. Moreover, an administrative
domain may consist of a single recovery domain or can be partitioned
into several smaller recovery domains. The operator can partition
the network into recovery domains based on physical network topology,
control plane capabilities, or various traffic engineering
constraints.
An example often addressed in the literature is the metro-core-metro
application (sometimes extended to a metro-metro/core-core) within a
single transport layer (see Section 7.2). For such a case, an end-
to-end LSP is defined between the ingress and egress metro nodes,
while LSP segments may be defined within the metro or core sub-
networks. Each of these topological structures determines a so-
called "recovery domain" since each of the LSPs they carry can have
its own recovery type (or even scheme). The support of multiple
recovery types and schemes within a sub-network is referred to as a
"multi-recovery capable domain" or simply "multi-recovery domain".
7.2. Vertical Hierarchy (Layers)
It is very challenging to combine the different recovery capabilities
available across the path (i.e., switching capable) and section
layers to ensure that certain network survivability objectives are
met for the network-supported services.
As a first analysis step, one can draw the following guidelines for
a vertical coordination of the recovery mechanisms:
- The lower the layer, the faster the notification and switching.
- The higher the layer, the finer the granularity of the recoverable
entity and therefore the granularity of the recovery resource.
Moreover, in the context of this analysis, a vertical hierarchy
consists of multiple layered transport planes providing different:
- Discrete bandwidth granularities for non-packet LSPs such as OCh,
ODUk, STS_SPE/HOVC, and VT_SPE/LOVC LSPs and continuous bandwidth
granularities for packet LSPs.
- Potential recovery capabilities with different temporal
granularities: ranging from milliseconds to tens of seconds
Note: based on the bandwidth granularity, we can determine four
classes of vertical hierarchies: (1) packet over packet, (2) packet
over circuit, (3) circuit over packet, and (4) circuit over circuit.
Below we briefly expand on (4) only. (2) is covered in [RFC3386]. (1)
is extensively covered by the MPLS Working Group, and (3) by the PWE3
Working Group.
In SONET/SDH environments, one typically considers the VT_SPE/LOVC
and STS SPE/HOVC as independent layers (for example, VT_SPE/LOVC LSP
uses the underlying STS_SPE/HOVC LSPs as links). In OTN, the ODUk
path layers will lie on the OCh path layer, i.e., the ODUk LSPs use
the underlying OCh LSPs as OTUk links. Note here that lower layer
LSPs may simply be provisioned and not necessarily dynamically
triggered or established (control driven approach). In this context,
an LSP at the path layer (i.e., established using GMPLS signaling),
such as an optical channel LSP, appears at the OTUk layer as a link,
controlled by a link management protocol such as LMP.
The first key issue with multi-layer recovery is that achieving
individual or bulk LSP recovery will be as efficient as the
underlying link (local span) recovery. In such a case, the span can
be either protected or unprotected, but the LSP it carries must be
(at least locally) recoverable. Therefore, the span recovery process
can be either independent when protected (or restorable), or
triggered by the upper LSP recovery process. The former case
requires coordination to achieve subsequent LSP recovery. Therefore,
in order to achieve robustness and fast convergence, multi-layer
recovery requires a fine-tuned coordination mechanism.
Moreover, in the absence of adequate recovery mechanism coordination
(for instance, a pre-determined coordination when using a hold-off
timer), a failure notification may propagate from one layer to the
next one within a recovery hierarchy. This can cause "collisions"
and trigger simultaneous recovery actions that may lead to race
conditions and, in turn, reduce the optimization of the resource
utilization and/or generate global instabilities in the network (see
[MANCHESTER]). Therefore, a consistent and efficient escalation
strategy is needed to coordinate recovery across several layers.
One can expect that the definition of the recovery mechanisms and
protocol(s) is technology-independent so that they can be
consistently implemented at different layers; this would in turn
simplify their global coordination. Moreover, as mentioned in
[RFC3386], some looser form of coordination and communication between
(vertical) layers such as a consistent hold-off timer configuration
(and setup through signaling during the working LSP establishment)
can be considered, thereby allowing the synchronization between
recovery actions performed across these layers.
7.2.1. Recovery Granularity
In most environments, the design of the network and the vertical
distribution of the LSP bandwidth are such that the recovery
granularity is finer at higher layers. The OTN and SONET/SDH layers
can recover only the whole section or the individual connections they
transports whereas the IP/MPLS control plane can recover individual
packet LSPs or groups of packet LSPs independently of their
granularity. On the other side, the recovery granularity at the
sub-wavelength level (i.e., SONET/SDH) can be provided only when the
network includes devices switching at the same granularity (and thus
not with optical channel level). Therefore, the network layer can
deliver control-plane-driven recovery mechanisms on a per-LSP basis
if and only if these LSPs have their corresponding switching
granularity supported at the transport plane level.
7.3. Escalation Strategies
There are two types of escalation strategies (see [DEMEESTER]):
bottom-up and top-down.
The bottom-up approach assumes that lower layer recovery types and
schemes are more expedient and faster than upper layer ones.
Therefore, we can inhibit or hold off higher layer recovery.
However, this assumption is not entirely true. Consider for instance
a SONET/SDH based protection mechanism (with a protection switching
time of less than 50 ms) lying on top of an OTN restoration mechanism
(with a restoration time of less than 200 ms). Therefore, this
assumption should be (at least) clarified as: the lower layer
recovery mechanism is expected to be faster than the upper level one,
if the same type of recovery mechanism is used at each layer.
Consequently, taking into account the recovery actions at the
different layers in a bottom-up approach: if lower layer recovery
mechanisms are provided and sequentially activated in conjunction
with higher layer ones, the lower layers must have an opportunity to
recover normal traffic before the higher layers do. However, if
lower layer recovery is slower than higher layer recovery, the lower
layer must either communicate the failure-related information to the
higher layer(s) (and allow it to perform recovery), or use a hold-off
timer in order to temporarily set the higher layer recovery action in
a "standby mode". Note that the a priori information exchange
between layers concerning their efficiency is not within the current
scope of this document. Nevertheless, the coordination functionality
between layers must be configurable and tunable.
For example, coordination between the optical and packet layer
control plane enables the optical layer to perform the failure
management operations (in particular, failure detection and
notification) while giving to the packet layer control plane the
authority to decide and perform the recovery actions. If the packet
layer recovery action is unsuccessful, fallback at the optical layer
can be performed subsequently.
The top-down approach attempts service recovery at the higher layers
before invoking lower layer recovery. Higher layer recovery is
service selective, and permits "per-CoS" or "per-connection" re-
routing. With this approach, the most important aspect is that the
upper layer should provide its own reliable and independent failure
detection mechanism from the lower layer.
[DEMEESTER] also suggests recovery mechanisms incorporating a
coordinated effort shared by two adjacent layers with periodic status
updates. Moreover, some of these recovery operations can be pre-
assigned (on a per-link basis) to a certain layer, e.g., a given link
will be recovered at the packet layer while another will be recovered
at the optical layer.
7.4. Disjointness
Having link and node diverse working and recovery LSPs/spans does not
guarantee their complete disjointness. Due to the common physical
layer topology (passive), additional hierarchical concepts, such as
the Shared Risk Link Group (SRLG), and mechanisms, such as SRLG
diverse path computation, must be developed to provide complete