Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 4428

Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)

Pages: 47
Part 2 of 2 – Pages 26 to 47
First   Prev   None

Top   ToC   RFC4428 - Page 26   prevText

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
Top   ToC   RFC4428 - Page 27
   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
Top   ToC   RFC4428 - Page 28
   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.
Top   ToC   RFC4428 - Page 29
   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.
Top   ToC   RFC4428 - Page 30
   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
Top   ToC   RFC4428 - Page 31
   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 working and recovery LSP/span disjointness (see [IPO-IMP] and
Top   ToC   RFC4428 - Page 32
   [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.
Top   ToC   RFC4428 - Page 33

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.
Top   ToC   RFC4428 - Page 34

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
Top   ToC   RFC4428 - Page 35
   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.
Top   ToC   RFC4428 - Page 36

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
Top   ToC   RFC4428 - Page 37
   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})]
Top   ToC   RFC4428 - Page 38
        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
Top   ToC   RFC4428 - Page 39
   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
Top   ToC   RFC4428 - Page 40
   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
Top   ToC   RFC4428 - Page 41
   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
   operations.  Per-component flooding of SRLG identifiers would deeply
   impact the scalability of the link state routing protocol.
   Therefore, one may rely on the usage of an on-line accessible network
   management system.
Top   ToC   RFC4428 - Page 42

9. Summary and Conclusions

The following table summarizes the different recovery types and schemes analyzed throughout this document. -------------------------------------------------------------------- | Path Search (computation and selection) -------------------------------------------------------------------- | Pre-planned (a) | Dynamic (b) -------------------------------------------------------------------- | | faster recovery | Does not apply | | less flexible | | 1 | less robust | | | most resource-consuming | Path | | | Setup ------------------------------------------------------------ | | relatively fast recovery | Does not apply | | relatively flexible | | 2 | relatively robust | | | resource consumption | | | depends on sharing degree | ------------------------------------------------------------ | | relatively fast recovery | less faster (computation) | | more flexible | most flexible | 3 | relatively robust | most robust | | less resource-consuming | least resource-consuming | | depends on sharing degree | -------------------------------------------------------------------- 1a. Recovery LSP setup (before failure occurrence) with resource reservation (i.e., signaling) and selection is referred to as LSP protection. 2a. Recovery LSP setup (before failure occurrence) with resource reservation (i.e., signaling) and with resource pre-selection is referred to as pre-planned LSP re-routing with resource pre- selection. This implies only recovery LSP activation after failure occurrence. 3a. Recovery LSP setup (before failure occurrence) with resource reservation (i.e., signaling) and without resource selection is referred to as pre-planned LSP re-routing without resource pre- selection. This implies recovery LSP activation and resource (i.e., label) selection after failure occurrence. 3b. Recovery LSP setup after failure occurrence is referred to as to as LSP re-routing, which is full when recovery LSP path computation occurs after failure occurrence.
Top   ToC   RFC4428 - Page 43
   Thus, the term pre-planned refers to recovery LSP path pre-
   computation, signaling (reservation), and a priori resource selection
   (optional), but not cross-connection.  Also, the shared-mesh recovery
   scheme can be viewed as a particular case of 2a) and 3a), using the
   additional constraint described in Section 8.4.3.

   The implementation of these recovery mechanisms requires only
   considering extensions to GMPLS signaling protocols (i.e., [RFC3471]
   and [RFC3473]).  These GMPLS signaling extensions should mainly focus
   in delivering (1) recovery LSP pre-provisioning for the cases 1a, 2a,
   and 3a, (2) LSP failure notification, (3) recovery LSP switching
   action(s), and (4) reversion mechanisms.

   Moreover, the present analysis (see Section 8) shows that no GMPLS
   routing extensions are expected to efficiently implement any of these
   recovery types and schemes.

10. Security Considerations

This document does not introduce any additional security issue or imply any specific security consideration from [RFC3945] to the current RSVP-TE GMPLS signaling, routing protocols (OSPF-TE, IS-IS- TE) or network management protocols. However, the authorization of requests for resources by GMPLS-capable nodes should determine whether a given party, presumably already authenticated, has a right to access the requested resources. This determination is typically a matter of local policy control, for example, by setting limits on the total bandwidth made available to some party in the presence of resource contention. Such policies may become quite complex as the number of users, types of resources, and sophistication of authorization rules increases. This is particularly the case for recovery schemes that assume pre-planned sharing of recovery resources, or contention for resources in case of dynamic re-routing. Therefore, control elements should match the requests against the local authorization policy. These control elements must be capable of making decisions based on the identity of the requester, as verified cryptographically and/or topologically.

11. Acknowledgements

The authors would like to thank Fabrice Poppe (Alcatel) and Bart Rousseau (Alcatel) for their revision effort, and Richard Rabbat (Fujitsu Labs), David Griffith (NIST), and Lyndon Ong (Ciena) for their useful comments.
Top   ToC   RFC4428 - Page 44
   Thanks also to Adrian Farrel for the thorough review of the document.

12. References

12.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005. [RFC4209] Fredette, A., Ed. and J. Lang, Ed., "Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems", RFC 4209, October 2005. [RFC4427] Mannie E., Ed. and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006.

12.2. Informative References

[BOUILLET] E. Bouillet, et al., "Stochastic Approaches to Compute Shared Meshed Restored Lightpaths in Optical Network Architectures," IEEE Infocom 2002, New York City, June 2002.
Top   ToC   RFC4428 - Page 45
   [DEMEESTER]  P. Demeester, et al., "Resilience in Multilayer
                Networks," IEEE Communications Magazine, Vol. 37, No. 8,
                pp. 70-76, August 1998.

   [GLI]        G. Li, et al., "Efficient Distributed Path Selection for
                Shared Restoration Connections," IEEE Infocom 2002, New
                York City, June 2002.

   [IPO-IMP]    Strand, J. and A. Chiu, "Impairments and Other
                Constraints on Optical Layer Routing", RFC 4054, May

   [KODIALAM1]  M. Kodialam and T.V. Lakshman, "Restorable Dynamic
                Quality of Service Routing," IEEE Communications
                Magazine, pp. 72-81, June 2002.

   [KODIALAM2]  M. Kodialam and T.V. Lakshman, "Dynamic Routing of
                Restorable Bandwidth-Guaranteed Tunnels using Aggregated
                Network Resource Usage Information," IEEE/ ACM
                Transactions on Networking, pp. 399-410, June 2003.

   [MANCHESTER] J. Manchester, P. Bonenfant and C. Newton, "The
                Evolution of Transport Network Survivability," IEEE
                Communications Magazine, August 1999.

   [RFC3386]    Lai, W. and D. McDysan, "Network Hierarchy and
                Multilayer Survivability", RFC 3386, November 2002.

   [T1.105]     ANSI, "Synchronous Optical Network (SONET): Basic
                Description Including Multiplex Structure, Rates, and
                Formats," ANSI T1.105, January 2001.

   [WANG]       J. Wang, L. Sahasrabuddhe, and B. Mukherjee, "Path vs.
                Subpath vs. Link Restoration for Fault Management in
                IP-over-WDM Networks: Performance Comparisons Using
                GMPLS Control Signaling," IEEE Communications Magazine,
                pp. 80-87, November 2002.

   For information on the availability of the following documents,
   please see

   [G.707]      ITU-T, "Network Node Interface for the Synchronous
                Digital Hierarchy (SDH)," Recommendation G.707, October

   [G.709]      ITU-T, "Network Node Interface for the Optical Transport
                Network (OTN)," Recommendation G.709, February 2001 (and
                Amendment no.1, October 2001).
Top   ToC   RFC4428 - Page 46
   [G.783]      ITU-T, "Characteristics of Synchronous Digital Hierarchy
                (SDH) Equipment Functional Blocks," Recommendation
                G.783, October 2000.

   [G.798]      ITU-T, "Characteristics of optical transport network
                hierarchy equipment functional block," Recommendation
                G.798, June 2004.

   [G.806]      ITU-T, "Characteristics of Transport Equipment -
                Description Methodology and Generic Functionality",
                Recommendation G.806, October 2000.

   [G.841]      ITU-T, "Types and Characteristics of SDH Network
                Protection Architectures," Recommendation G.841, October

   [G.842]      ITU-T, "Interworking of SDH network protection
                architectures," Recommendation G.842, October 1998.

   [G.874]      ITU-T, "Management aspects of the optical transport
                network element," Recommendation G.874, November 2001.

Editors' Addresses

Dimitri Papadimitriou Alcatel Francis Wellesplein, 1 B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 EMail: Eric Mannie Perceval Rue Tenbosch, 9 1000 Brussels Belgium Phone: +32-2-6409194 EMail:
Top   ToC   RFC4428 - Page 47
Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).