RFC 4428 - Analysis of Generalized Multi-Protocol Label Swit(3)

时间:2006-11-02 来源: 作者: 点击:
pre-selectedorselectedon-demand. RecoveryLSPprovisioningphases: (1)PathComputation--On-demand | | --Pre-Computed | | (2)Signaling--On-demand | | --Pre-Signaled | | (3)ResourceSelection--On-demand | |
  
       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
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容