working and recovery LSP/span disjointness (see [IPO-IMP] and
[RFC4202]). Otherwise, a failure affecting the working LSP/span
would also potentially affect the recovery LSP/span; one refers to
such an event as "common failure".
7.4.1. SRLG Disjointness
A Shared Risk Link Group (SRLG) is defined as the set of links
sharing a common risk (such as a common physical resource such as a
fiber link or a fiber cable). For instance, a set of links L belongs
to the same SRLG s, if they are provisioned over the same fiber link
f.
The SRLG properties can be summarized as follows:
1) A link belongs to more than one SRLG if and only if it crosses one
of the resources covered by each of them.
2) Two links belonging to the same SRLG can belong individually to
(one or more) other SRLGs.
3) The SRLG set S of an LSP is defined as the union of the individual
SRLG s of the individual links composing this LSP.
SRLG disjointness is also applicable to LSPs:
The LSP SRLG disjointness concept is based on the following
postulate: an LSP (i.e., a sequence of links and nodes) covers an
SRLG if and only if it crosses one of the links or nodes belonging
to that SRLG.
Therefore, the SRLG disjointness for LSPs, can be defined as
follows: two LSPs are disjoint with respect to an SRLG s if and
only if they do not cover simultaneously this SRLG s.
Whilst the SRLG disjointness for LSPs with respect to a set S of
SRLGs, is defined as follows: two LSPs are disjoint with respect
to a set of SRLGs S if and only if the set of SRLGs that are
common to both LSPs is disjoint from set S.
The impact on recovery is noticeable: SRLG disjointness is a
necessary (but not a sufficient) condition to ensure network
survivability. With respect to the physical network resources, a
working-recovery LSP/span pair must be SRLG-disjoint in case of
dedicated recovery type. On the other hand, in case of shared
recovery, a group of working LSP/spans must be mutually SRLG-disjoint
in order to allow for a (single and common) shared recovery LSP that
is itself SRLG-disjoint from each of the working LSPs/spans.
8. Recovery Mechanisms Analysis
In order to provide a structured analysis of the recovery mechanisms
detailed in the previous sections, the following dimensions can be
considered:
1. Fast convergence (performance): provide a mechanism that
aggregates multiple failures (implying fast failure detection and
correlation mechanisms) and fast recovery decision independently
of the number of failures occurring in the optical network (also
implying a fast failure notification).
2. Efficiency (scalability): minimize the switching time required for
LSP/span recovery independently of the number of LSPs/spans being
recovered (this implies efficient failure correlation, fast
failure notification, and time-efficient recovery mechanisms).
3. Robustness (availability): minimize the LSP/span downtime
independently of the underlying topology of the transport plane
(this implies a highly responsive recovery mechanism).
4. Resource optimization (optimality): minimize the resource
capacity, including LSPs/spans and nodes (switching capacity),
required for recovery purposes; this dimension can also be
referred to as optimizing the sharing degree of the recovery
resources.
5. Cost optimization: provide a cost-effective recovery type/scheme.
However, these dimensions are either outside the scope of this
document (such as cost optimization and recovery path computational
aspects) or mutually conflicting. For instance, it is obvious that
providing a 1+1 LSP protection minimizes the LSP downtime (in case of
failure) while being non-scalable and consuming recovery resource
without enabling any extra-traffic.
The following sections analyze the recovery phases and mechanisms
detailed in the previous sections with respect to the dimensions
described above in order to assess the GMPLS protocol suite
capabilities and applicability. In turn, this allows the evaluation
of the potential need for further GMPLS signaling and routing
extensions.
8.1. Fast Convergence (Detection/Correlation and Hold-off Time)
Fast convergence is related to the failure management operations. It
refers to the time elapsed between failure detection/correlation and
hold-off time, the point at which the recovery switching actions are
initiated. This point has been detailed in Section 4.
8.2. Efficiency (Recovery Switching Time)
In general, the more pre-assignment/pre-planning of the recovery
LSP/span, the more rapid the recovery is. Because protection implies
pre-assignment (and cross-connection) of the protection resources, in
general, protection recovers faster than restoration.
Span restoration is likely to be slower than most span protection
types; however this greatly depends on the efficiency of the span
restoration signaling. LSP restoration with pre-signaled and pre-
selected recovery resources is likely to be faster than fully dynamic
LSP restoration, especially because of the elimination of any
potential crankback during the recovery LSP establishment.
If one excludes the crankback issue, the difference between dynamic
and pre-planned restoration depends on the restoration path
computation and selection time. Since computational considerations
are outside the scope of this document, it is up to the vendor to
determine the average and maximum path computation time in different
scenarios and to the operator to decide whether or not dynamic
restoration is advantageous over pre-planned schemes that depend on
the network environment. This difference also depends on the
flexibility provided by pre-planned restoration versus dynamic
restoration. Pre-planned restoration implies a somewhat limited
number of failure scenarios (that can be due, for instance, to local
storage capacity limitation). Dynamic restoration enables on-demand
path computation based on the information received through failure
notification message, and as such, it is more robust with respect to
the failure scenario scope.
Moreover, LSP segment restoration, in particular, dynamic restoration
(i.e., no path pre-computation, so none of the recovery resource is
pre-reserved) will generally be faster than end-to-end LSP
restoration. However, local LSP restoration assumes that each LSP
segment end-point has enough computational capacity to perform this
operation while end-to-end LSP restoration requires only that LSP
end-points provide this path computation capability.
Recovery time objectives for SONET/SDH protection switching (not
including time to detect failure) are specified in [G.841] at 50 ms,
taking into account constraints on distance, number of connections
involved, and in the case of ring enhanced protection, number of
nodes in the ring. Recovery time objectives for restoration
mechanisms have been proposed through a separate effort [RFC3386].
8.3. Robustness
In general, the less pre-assignment (protection)/pre-planning
(restoration) of the recovery LSP/span, the more robust the recovery
type or scheme is to a variety of single failures, provided that
adequate resources are available. Moreover, the pre-selection of the
recovery resources gives (in the case of multiple failure scenarios)
less flexibility than no recovery resource pre-selection. For
instance, if failures occur that affect two LSPs sharing a common
link along their restoration paths, then only one of these LSPs can
be recovered. This occurs unless the restoration path of at least
one of these LSPs is re-computed, or the local resource assignment is
modified on the fly.
In addition, recovery types and schemes with pre-planned recovery
resources (in particular, LSP/spans for protection and LSPs for
restoration purposes) will not be able to recover from failures that
simultaneously affect both the working and recovery LSP/span. Thus,
the recovery resources should ideally be as disjoint as possible
(with respect to link, node, and SRLG) from the working ones, so that
any single failure event will not affect both working and recovery
LSP/span. In brief, working and recovery resources must be fully
diverse in order to guarantee that a given failure will not affect
simultaneously the working and the recovery LSP/span. Also, the risk
of simultaneous failure of the working and the recovery LSPs can be
reduced. It is reduced by computing a new recovery path whenever a
failure occurs along one of the recovery LSPs or by computing a new
recovery path and provision the corresponding LSP whenever a failure
occurs along a working LSP/span. Both methods enable the network to
maintain the number of available recovery path constant.
The robustness of a recovery scheme is also determined by the amount
of pre-reserved (i.e., signaled) recovery resources within a given
shared resource pool: as the sharing degree of recovery resources
increases, the recovery scheme becomes less robust to multiple
LSP/span failure occurrences. Recovery schemes, in particular
restoration, with pre-signaled resource reservation (with or without
pre-selection) should be capable of reserving an adequate amount of
resource to ensure recovery from any specific set of failure events,
such as any single SRLG failure, any two SRLG failures, etc.
8.4. Resource Optimization
It is commonly admitted that sharing recovery resources provides
network resource optimization. Therefore, from a resource
utilization perspective, protection schemes are often classified with
respect to their degree of sharing recovery resources with the
working entities. Moreover, non-permanent bridging protection types
allow (under normal conditions) for extra-traffic over the recovery
resources.
From this perspective, the following statements are true:
1) 1+1 LSP/Span protection is the most resource-consuming protection
type because it does not allow for any extra traffic.
2) 1:1 LSP/span recovery requires dedicated recovery LSP/span
allowing for extra traffic.
3) 1:N and M:N LSP/span recovery require 1 (and M, respectively)
recovery LSP/span (shared between the N working LSP/span) allowing
for extra traffic.
Obviously, 1+1 protection precludes, and 1:1 recovery does not allow
for any recovery LSP/span sharing, whereas 1:N and M:N recovery do
allow sharing of 1 (M, respectively) recovery LSP/spans between N
working LSP/spans. However, despite the fact that 1:1 LSP recovery
precludes the sharing of the recovery LSP, the recovery schemes that
can be built from it (e.g., (1:1)^n, see Section 5.4) do allow
sharing of its recovery resources. In addition, the flexibility in
the usage of shared recovery resources (in particular, shared links)
may be limited because of network topology restrictions, e.g., fixed
ring topology for traditional enhanced protection schemes.
On the other hand, when using LSP restoration with pre-signaled
resource reservation, the amount of reserved restoration capacity is
determined by the local bandwidth reservation policies. In LSP
restoration schemes with re-provisioning, a pool of spare resources
can be defined from which all resources are selected after failure
occurrence for the purpose of restoration path computation. The
degree to which restoration schemes allow sharing amongst multiple
independent failures is then directly inferred from the size of the
resource pool. Moreover, in all restoration schemes, spare resources
can be used to carry preemptible traffic (thus over preemptible
LSP/span) when the corresponding resources have not been committed
for LSP/span recovery purposes.
From this, it clearly follows that less recovery resources (i.e.,
LSP/spans and switching capacity) have to be allocated to a shared
recovery resource pool if a greater sharing degree is allowed. Thus,
the network survivability level is determined by the policy that
defines the amount of shared recovery resources and by the maximum
sharing degree allowed for these recovery resources.
8.4.1. Recovery Resource Sharing
When recovery resources are shared over several LSP/Spans, the use of
the Maximum Reservable Bandwidth, the Unreserved Bandwidth, and the
Maximum LSP Bandwidth (see [RFC4202]) provides the information needed
to obtain the optimization of the network resources allocated for
shared recovery purposes.
The Maximum Reservable Bandwidth is defined as the Maximum Link
Bandwidth but it may be greater in case of link over-subscription.
The Unreserved Bandwidth (at priority p) is defined as the bandwidth
not yet reserved on a given TE link (its initial value for each
priority p corresponds to the Maximum Reservable Bandwidth). Last,
the Maximum LSP Bandwidth (at priority p) is defined as the smaller
of Unreserved Bandwidth (at priority p) and Maximum Link Bandwidth.
Here, one generally considers a recovery resource sharing degree (or
ratio) to globally optimize the shared recovery resource usage. The
distribution of the bandwidth utilization per TE link can be inferred
from the per-priority bandwidth pre-allocation. By using the Maximum
LSP Bandwidth and the Maximum Reservable Bandwidth, the amount of
(over-provisioned) resources that can be used for shared recovery
purposes is known from the IGP.
In order to analyze this behavior, we define the difference between
the Maximum Reservable Bandwidth (in the present case, this value is
greater than the Maximum Link Bandwidth) and the Maximum LSP
Bandwidth per TE link i as the Maximum Shareable Bandwidth or
max_R[i]. Within this quantity, the amount of bandwidth currently
allocated for shared recovery per TE link i is defined as R[i]. Both
quantities are expressed in terms of discrete bandwidth units (and
thus, the Minimum LSP Bandwidth is of one bandwidth unit).
The knowledge of this information available per TE link can be
exploited in order to optimize the usage of the resources allocated
per TE link for shared recovery. If one refers to r[i] as the actual
bandwidth per TE link i (in terms of discrete bandwidth units)
committed for shared recovery, then the following quantity must be
maximized over the potential TE link candidates:
sum {i=1}^N [(R{i} - r{i})/(t{i} - b{i})]
or equivalently: sum {i=1}^N [(R{i} - r{i})/r{i}]
with R{i} >= 1 and r{i} >= 1 (in terms of per component
bandwidth unit)
In this formula, N is the total number of links traversed by a given
LSP, t[i] the Maximum Link Bandwidth per TE link i, and b[i] the sum
per TE link i of the bandwidth committed for working LSPs and other
recovery LSPs (thus except "shared bandwidth" LSPs). The quantity
[(R{i} - r{i})/r{i}] is defined as the Shared (Recovery) Bandwidth
Ratio per TE link i. In addition, TE links for which R[i] reaches
max_R[i] or for which r[i] = 0 are pruned during shared recovery path
computation as well as TE links for which max_R[i] = r[i] that can
simply not be shared.
More generally, one can draw the following mapping between the
available bandwidth at the transport and control plane level:
- ---------- Max Reservable Bandwidth
| ----- ^
|R ----- |
| ----- |
- ----- |max_R
----- |
-------- TE link Capacity - ------ | - Maximum TE Link Bandwidth
----- |r ----- v
----- <------ b ------> - ---------- Maximum LSP Bandwidth
----- -----
----- -----
----- -----
----- -----
----- ----- <--- Minimum LSP Bandwidth
-------- 0 ---------- 0
Note that the above approach does not require the flooding of any per
LSP information or any detailed distribution of the bandwidth
allocation per component link or individual ports or even any per-
priority shareable recovery bandwidth information (using a dedicated
sub-TLV). The latter would provide the same capability as the
already defined Maximum LSP bandwidth per-priority information. This
approach is referred to as a Partial (or Aggregated) Information
Routing as described in [KODIALAM1] and [KODIALAM2]. They show that
the difference obtained with a Full (or Complete) Information Routing
approach (where for the whole set of working and recovery LSPs, the
amount of bandwidth units they use per-link is known at each node and
for each link) is clearly negligible. The Full Information Routing
approach is detailed in [GLI]. Note also that both approaches rely
on the deterministic knowledge (at different degrees) of the network
topology and resource usage status.
Moreover, extending the GMPLS signaling capabilities can enhance the
Partial Information Routing approach. It is enhanced by allowing
working-LSP-related information and, in particular, its path
(including link and node identifiers) to be exchanged with the
recovery LSP request. This enables more efficient admission control
at upstream nodes of shared recovery resources, and in particular,
links (see Section 8.4.3).
8.4.2. Recovery Resource Sharing and SRLG Recovery
Resource shareability can also be maximized with respect to the
number of times each SRLG is protected by a recovery resource (in
particular, a shared TE link) and methods can be considered for
avoiding contention of the shared recovery resources in case of
single SRLG failure. These methods enable the sharing of recovery
resources between two (or more) recovery LSPs, if their respective
working LSPs are mutually disjoint with respect to link, node, and
SRLGs. Then, a single failure does not simultaneously disrupt
several (or at least two) working LSPs.
For instance, [BOUILLET] shows that the Partial Information Routing
approach can be extended to cover recovery resource shareability with
respect to SRLG recoverability (i.e., the number of times each SRLG
is recoverable). By flooding this aggregated information per TE
link, path computation and selection of SRLG-diverse recovery LSPs
can be optimized with respect to the sharing of recovery resource
reserved on each TE link. This yields a performance difference of
less than 5%, which is negligible compared to the corresponding Full
Information Flooding approach (see [GLI]).
For this purpose, additional extensions to [RFC4202] in support of
path computation for shared mesh recovery have been often considered
in the literature. TE link attributes would include, among others,
the current number of recovery LSPs sharing the recovery resources
reserved on the TE link, and the current number of SRLGs recoverable
by this amount of (shared) recovery resources reserved on the TE
link. The latter is equivalent to the current number of SRLGs that
will be recovered by the recovery LSPs sharing the recovery resource
reserved on the TE link. Then, if explicit SRLG recoverability is
considered, a TE link attribute would be added that includes the
explicit list of SRLGs (recoverable by the shared recovery resource
reserved on the TE link) and their respective shareable recovery
bandwidths. The latter information is equivalent to the shareable
recovery bandwidth per SRLG (or per group of SRLGs), which implies
that the amount of shareable bandwidth and the number of listed SRLGs
will decrease over time.
Compared to the case of recovery resource sharing only (regardless of
SRLG recoverability, as described in Section 8.4.1), these additional
TE link attributes would potentially deliver better path computation
and selection (at a distinct ingress node) for shared mesh recovery
purposes. However, due to the lack of evidence of better efficiency
and due to the complexity that such extensions would generate, they
are not further considered in the scope of the present analysis. For
instance, a per-SRLG group minimum/maximum shareable recovery
bandwidth is restricted by the length that the corresponding (sub-)
TLV may take and thus the number of SRLGs that it can include.
Therefore, the corresponding parameter should not be translated into
GMPLS routing (or even signaling) protocol extensions in the form of
TE link sub-TLV.
8.4.3. Recovery Resource Sharing, SRLG Disjointness and Admission
Control
Admission control is a strict requirement to be fulfilled by nodes
giving access to shared links. This can be illustrated using the
following network topology:
A ------ C ====== D
| | |
| | |
| B |
| | |
| | |
------- E ------ F
Node A creates a working LSP to D (A-C-D), B creates simultaneously a
working LSP to D (B-C-D) and a recovery LSP (B-E-F-D) to the same
destination. Then, A decides to create a recovery LSP to D (A-E-F-
D), but since the C-D span carries both working LSPs, node E should
either assign a dedicated resource for this recovery LSP or reject
this request if the C-D span has already reached its maximum recovery
bandwidth sharing ratio. In the latter case, C-D span failure would
imply that one of the working LSP would not be recoverable.
Consequently, node E must have the required information to perform
admission control for the recovery LSP requests it processes
(implying for instance, that the path followed by the working LSP is
carried with the corresponding recovery LSP request). If node E can
guarantee that the working LSPs (A-C-D and B-C-D) are SRLG disjoint
over the C-D span, it may securely accept the incoming recovery LSP
request and assign to the recovery LSPs (A-E-F-D and B-E-F-D) the
same resources on the link E-F. This may occur if the link E-F has
not yet reached its maximum recovery bandwidth sharing ratio. In
this example, one assumes that the node failure probability is
negligible compared to the link failure probability.
To achieve this, the path followed by the working LSP is transported
with the recovery LSP request and examined at each upstream node of
potentially shareable links. Admission control is performed using
the interface identifiers (included in the path) to retrieve in the
TE DataBase the list of SRLG IDs associated to each of the working
LSP links. If the working LSPs (A-C-D and B-C-D) have one or more
link or SRLG ID in common (in this example, one or more SRLG id in
common over the span C-D), node E should not assign the same resource
over link E-F to the recovery LSPs (A-E-F-D and B-E-F-D). Otherwise,
one of these working LSPs would not be recoverable if C-D span
failure occurred.
There are some issues related to this method; the major one is the
number of SRLG IDs that a single link can cover (more than 100, in
complex environments). Moreover, when using link bundles, this
approach may generate the rejection of some recovery LSP requests.
This occurs when the SRLG sub-TLV corresponding to a link bundle
includes the union of the SRLG id list of all the component links
belonging to this bundle (see [RFC4202] and [RFC4201]).
In order to overcome this specific issue, an additional mechanism may
consist of querying the nodes where the information would be
available (in this case, node E would query C). The main drawback of
this method is that (in addition to the dedicated mechanism(s) it
requires) it may become complex when several common nodes are
traversed by the working LSPs. Therefore, when using link bundles,
solving this issue is closely related to the sequence of the recovery