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

时间:2006-11-02 来源: 作者: 点击:
5.1.Transportvs.ControlPlaneResponsibilities Whenapplicable,recoveryresourcesareprovisioned,forboth protectionandrestoration,usingGMPLSsignalingcapabilities. Thus,thesearecontrolplane-drivenactions(t
  
5.1.  Transport vs. Control Plane Responsibilities

   When applicable, recovery resources are provisioned, for both
   protection and restoration, using GMPLS signaling capabilities.
   Thus, these are control plane-driven actions (topological and
   resource-constrained) that are always performed in this context.

   The following tables give an overview of the responsibilities taken
   by the control plane in case of LSP/span recovery:

   1. LSP/span Protection

   - Phase 1: Failure Detection                  Transport plane
   - Phase 2: Failure Localization/Isolation     Transport/Control plane
   - Phase 3: Failure Notification               Transport/Control plane
   - Phase 4: Protection Switching               Transport/Control plane
   - Phase 5: Reversion (Normalization)          Transport/Control plane

   Note: in the context of LSP/span protection, control plane actions
   can be performed either for operational purposes and/or
   synchronization purposes (vertical synchronization between transport
   and control plane) and/or notification purposes (horizontal
   synchronization between end-nodes at control plane level).  This
   suggests the selection of the responsible plane (in particular for
   protection switching) during the provisioning phase of the
   protected/protection LSP.

   2. LSP/span Restoration

   - Phase 1: Failure Detection                  Transport plane
   - Phase 2: Failure Localization/Isolation     Transport/Control plane
   - Phase 3: Failure Notification               Control plane
   - Phase 4: Recovery Switching                 Control plane
   - Phase 5: Reversion (Normalization)          Control plane

   Therefore, this document primarily focuses on provisioning of LSP
   recovery resources, failure notification mechanisms, recovery
   switching, and reversion operations.  Moreover, some additional
   considerations can be dedicated to the mechanisms associated to the
   failure localization/isolation phase.

5.2.  Technology-Independent and Technology-Dependent Mechanisms

   The present recovery mechanisms analysis applies to any circuit-
   oriented data plane technology with discrete bandwidth increments
   (like SONET/SDH, G.709 OTN, etc.) being controlled by a GMPLS-based
   distributed control plane.

   The following sub-sections are not intended to favor one technology
   versus another.  They list pro and cons for each technology in order
   to determine the mechanisms that GMPLS-based recovery must deliver to
   overcome their cons and make use of their pros in their respective
   applicability context.

5.2.1.  OTN Recovery

   OTN recovery specifics are left for further consideration.

5.2.2.  Pre-OTN Recovery

   Pre-OTN recovery specifics (also referred to as "lambda switching")
   present mainly the following advantages:

   - They benefit from a simpler architecture, making it more suitable
     for mesh-based recovery types and schemes (on a per-channel basis).

   - Failure suppression at intermediate node transponders, e.g., use of
     squelching, implies that failures (such as LoL) will propagate to
     edge nodes.  Thus, edge nodes will have the possibility to initiate
     recovery actions driven by upper layers (vs. use of non-standard
     masking of upstream failures).

   The main disadvantage is the lack of interworking due to the large
   amount of failure management (in particular failure notification
   protocols) and recovery mechanisms currently available.

   Note also, that for all-optical networks, combination of recovery
   with optical physical impairments is left for a future release of
   this document because corresponding detection technologies are under
   specification.

5.2.3.  SONET/SDH Recovery

   Some of the advantages of SONET [T1.105]/SDH [G.707], and more
   generically any Time Division Multiplexing (TDM) transport plane
   recovery, are that they provide:

   - Protection types operating at the data plane level that are
     standardized (see [G.841]) and can operate across protected domains
     and interwork (see [G.842]).

   - Failure detection, notification, and path/section Automatic
     Protection Switching (APS) mechanisms.

   - Greater control over the granularity of the TDM LSPs/links that can
     be recovered with respect to coarser optical channel (or whole
     fiber content) recovery switching

   Some of the limitations of the SONET/SDH recovery are:

   - Limited topological scope: Inherently the use of ring topologies,
     typically, dedicated Sub-Network Connection Protection (SNCP) or
     shared protection rings, has reduced flexibility and resource
     efficiency with respect to the (somewhat more complex) meshed
     recovery.

   - Inefficient use of spare capacity: SONET/SDH protection is largely
     applied to ring topologies, where spare capacity often remains
     idle, making the efficiency of bandwidth usage a real issue.

   - Support of meshed recovery requires intensive network management
     development, and the functionality is limited by both the network
     elements and the capabilities of the element management systems
     (thus justifying the development of GMPLS-based distributed
     recovery mechanisms.)

5.3.  Specific Aspects of Control Plane-Based Recovery Mechanisms

5.3.1.  In-Band vs. Out-Of-Band Signaling

   The nodes communicate through the use of IP terminating control
   channels defining the control plane (transport) topology.  In this
   context, two classes of transport mechanisms can be considered here:
   in-fiber or out-of-fiber (through a dedicated physically diverse
   control network referred to as the Data Communication Network or
   DCN).  The potential impact of the usage of an in-fiber (signaling)
   transport mechanism is briefly considered here.

   In-fiber transport mechanisms can be further subdivided into in-band
   and out-of-band.  As such, the distinction between in-fiber in-band
   and in-fiber out-of-band signaling reduces to the consideration of a
   logically- versus physically-embedded control plane topology with
   respect to the transport plane topology.  In the scope of this
   document, it is assumed that at least one IP control channel between
   each pair of adjacent nodes is continuously available to enable the
   exchange of recovery-related information and messages.  Thus, in
   either case (i.e., in-band or out-of-band) at least one logical or
   physical control channel between each pair of nodes is always
   expected to be available.

   Therefore, the key issue when using in-fiber signaling is whether one
   can assume independence between the fault-tolerance capabilities of
   control plane and the failures affecting the transport plane
   (including the nodes).  Note also that existing specifications like
   the OTN provide a limited form of independence for in-fiber signaling
   by dedicating a separate optical supervisory channel (OSC, see
   [G.709] and [G.874]) to transport the overhead and other control
   traffic.  For OTNs, failure of the OSC does not result in failing the
   optical channels.  Similarly, loss of the control channel must not
   result in failing the data channels (transport plane).

5.3.2.  Uni- vs. Bi-Directional Failures

   The failure detection, correlation, and notification mechanisms
   (described in Section 4) can be triggered when either a uni-
   directional or a bi-directional LSP/Span failure occurs (or a
   combination of both).  As illustrated in Figures 1 and 2, two
   alternatives can be considered here:

   1. Uni-directional failure detection: the failure is detected on the
      receiver side, i.e., it is detected by only the downstream node to
      the failure (or by the upstream node depending on the failure
      propagation direction, respectively).

   2. Bi-directional failure detection: the failure is detected on the
      receiver side of both downstream node AND upstream node to the
      failure.

   Notice that after the failure detection time, if only control-plane-
   based failure management is provided, the peering node is unaware of
   the failure detection status of its neighbor.

    -------             -------           -------             -------
   |       |           |       |Tx     Rx|       |           |       |
   | NodeA |----...----| NodeB |xxxxxxxxx| NodeC |----...----| NodeD |
   |       |----...----|       |---------|       |----...----|       |
    -------             -------           -------             -------

   t0                                >>>>>>> F

   t1                      x <---------------x
                               Notification
   t2  <--------...--------x                 x--------...-------->
          Up Notification                      Down Notification

              Figure 1: Uni-directional failure detection

    -------             -------           -------             -------
   |       |           |       |Tx     Rx|       |           |       |
   | NodeA |----...----| NodeB |xxxxxxxxx| NodeC |----...----| NodeD |
   |       |----...----|       |xxxxxxxxx|       |----...----|       |
    -------             -------           -------             -------

   t0                      F <<<<<<< >>>>>>> F

   t1                      x <-------------> x
                               Notification
   t2  <--------...--------x                 x--------...-------->
          Up Notification                      Down Notification

               Figure 2: Bi-directional failure detection

   After failure detection, the following failure management operations
   can be subsequently considered:

   - Each detecting entity sends a notification message to the
     corresponding transmitting entity.  For instance, in Figure 1, node
     C sends a notification message to node B.  In Figure 2, node C
     sends a notification message to node B while node B sends a
     notification message to node C.  To ensure reliable failure
     notification, a dedicated acknowledgement message can be returned
     back to the sender node.

   - Next, within a certain (and pre-determined) time window, nodes
     impacted by the failure occurrences may perform their correlation.
     In case of uni-directional failure, node B only receives the
     notification message from node C, and thus the time for this
     operation is negligible.  In case of bi-directional failure, node B
     has to correlate the received notification message from node C with
     the corresponding locally detected information (and node C has to
     do the same with the message from node B).

   - After some (pre-determined) period of time, referred to as the
     hold-off time, if the local recovery actions (see Section 5.3.4)
     were not successful, the following occurs.  In case of uni-
     directional failure and depending on the directionality of the LSP,
     node B should send an upstream notification message (see [RFC3473])
     to the ingress node A.  Node C may send a downstream notification
     message (see [RFC3473]) to the egress node D.  However, in that
     case, only node A would initiate an edge to edge recovery action.
     Node A is referred to as the "master", and node D is referred to as
     the "slave", per [RFC4427].  Note that the other LSP end-node (node
     D in this case) may be optionally notified using a downstream
     notification message (see [RFC3473]).

     In case of bi-directional failure, node B should send an upstream
     notification message (see [RFC3473]) to the ingress node A.  Node C
     may send a downstream notification message (see [RFC3473]) to the
     egress node D.  However, due to the dependence on the LSP
     directionality, only ingress node A would initiate an edge-to-edge
     recovery action.  Note that the other LSP end-node (node D in this
     case) should also be notified of this event using a downstream
     notification message (see [RFC3473]).  For instance, if an LSP
     directed from D to A is under failure condition, only the
     notification message sent from node C to D would initiate a
     recovery action.  In this case, per [RFC4427], the deciding and
     recovering node D is referred to as the "master", while node A is
     referred to as the "slave" (i.e., recovering only entity).

     Note: The determination of the master and the slave may be based
     either on configured information or dedicated protocol capability.

   In the above scenarios, the path followed by the upstream and
   downstream notification messages does not have to be the same as the
   one followed by the failed LSP (see [RFC3473] for more details on the
   notification message exchange).  The important point concerning this
   mechanism is that either the detecting/reporting entity (i.e., nodes
   B and C) is also the deciding/recovery entity or the
   detecting/reporting entity is simply an intermediate node in the
   subsequent recovery process.  One refers to local recovery in the
   former case, and to edge-to-edge recovery in the latter one (see also
   Section 5.3.4).

5.3.3.  Partial vs. Full Span Recovery

   When a given span carries more than one LSP or LSP segment, an
   additional aspect must be considered.  In case of span failure, the
   LSPs it carries can be recovered individually, as a group (aka bulk
   LSP recovery), or as independent sub-groups.  When correlation time
   windows are used and simultaneous recovery of several LSPs can be
   performed using a single request, the selection of this mechanism
   would be triggered independently of the failure notification
   granularity.  Moreover, criteria for forming such sub-groups are
   outside of the scope of this document.

   Additional complexity arises in the case of (sub-)group LSP recovery.
   Between a given pair of nodes, the LSPs that a given (sub-)group
   contains may have been created from different source nodes (i.e.,
   initiator) and directed toward different destination nodes.
   Consequently the failure notification messages following a bi-
   directional span failure that affects several LSPs (or the whole
   group of LSPs it carries) are not necessarily directed toward the
   same initiator nodes.  In particular, these messages may be directed

   to both the upstream and downstream nodes to the failure.  Therefore,
   such span failure may trigger recovery actions to be performed from
   both sides (i.e., from both the upstream and the downstream nodes to
   the failure).  In order to facilitate the definition of the
   corresponding recovery mechanisms (and their sequence), one assumes
   here as well that, per [RFC4427], the deciding (and recovering)
   entity (referred to as the "master") is the only initiator of the
   recovery of the whole LSP (sub-)group.

5.3.4.  Difference between LSP, LSP Segment and Span Recovery

   The recovery definitions given in [RFC4427] are quite generic and
   apply for link (or local span) and LSP recovery.  The major
   difference between LSP, LSP Segment and span recovery is related to
   the number of intermediate nodes that the signaling messages have to
   travel.  Since nodes are not necessarily adjacent in the case of LSP
   (or LSP Segment) recovery, signaling message exchanges from the
   reporting to the deciding/recovery entity may have to cross several
   intermediate nodes.  In particular, this applies to the notification
   messages due to the number of hops separating the location of a
   failure occurrence from its destination.  This results in an
   additional propagation and forwarding delay.  Note that the former
   delay may in certain circumstances be non-negligible; e.g., in a
   copper out-of-band network, the delay is approximately 1 ms per
   200km.

   Moreover, the recovery mechanisms applicable to end-to-end LSPs and
   to the segments that may compose an end-to-end LSP (i.e., edge-to-
   edge recovery) can be exactly the same.  However, one expects in the
   latter case, that the destination of the failure notification message
   will be the ingress/egress of each of these segments.  Therefore,
   using the mechanisms described in Section 5.3.2, failure notification
   messages can be exchanged first between terminating points of the LSP
   segment, and after expiration of the hold-off time, between
   terminating points of the end-to-end LSP.

   Note: Several studies provide quantitative analysis of the relative
   performance of LSP/span recovery techniques. [WANG] for instance,
   provides an analysis grid for these techniques showing that dynamic
   LSP restoration (see Section 5.5.2) performs well under medium
   network loads, but suffers performance degradations at higher loads
   due to greater contention for recovery resources.  LSP restoration
   upon span failure, as defined in [WANG], degrades at higher loads
   because paths around failed links tend to increase the hop count of
   the affected LSPs and thus consume additional network resources.
   Also, performance of LSP restoration can be enhanced by a failed
   working LSP’s source node that initiates a new recovery attempt if an
   initial attempt fails.  A single retry attempt is sufficient to

   produce large increases in the restoration success rate and ability
   to initiate successful LSP restoration attempts, especially at high
   loads, while not adding significantly to the long-term average
   recovery time.  Allowing additional attempts produces only small
   additional gains in performance.  This suggests using additional
   (intermediate) crankback signaling when using dynamic LSP restoration
   (described in Section 5.5.2 - case 2).  Details on crankback
   signaling are outside the scope of this document.

5.4.  Difference between Recovery Type and Scheme

   [RFC4427] defines the basic LSP/span recovery types.  This section
   describes the recovery schemes that can be built using these recovery
   types.  In brief, a recovery scheme is defined as the combination of
   several ingress-egress node pairs supporting a given recovery type
   (from the set of the recovery types they allow).  Several examples
   are provided here to illustrate the difference between recovery types
   such as 1:1 or M:N, and recovery schemes such as (1:1)^n or (M:N)^n
   (referred to as shared-mesh recovery).

   1. (1:1)^n with recovery resource sharing

   The exponent, n, indicates the number of times a 1:1 recovery type is
   applied between at most n different ingress-egress node pairs.  Here,
   at most n pairs of disjoint working and recovery LSPs/spans share a
   common resource at most n times.  Since the working LSPs/spans are
   mutually disjoint, simultaneous requests for use of the shared
   (common) resource will only occur in case of simultaneous failures,
   which are less likely to happen.

   For instance, in the common (1:1)^2 case, if the 2 recovery LSPs in
   the group overlap the same common resource, then it can handle only
   single failures; any multiple working LSP failures will cause at
   least one working LSP to be denied automatic recovery.  Consider for
   instance the following topology with the working LSPs A-B-C and F-G-H
   and their respective recovery LSPs A-D-E-C and F-D-E-H that share a
   common D-E link resource.

                          A---------B---------C
                           \                 /
                            \               /
                             D-------------E
                            /               \
                           /                 \
                          F---------G---------H

   2. (M:N)^n with recovery resource sharing

   The (M:N)^n scheme is documented here for the sake of completeness
   only (i.e., it is not mandated that GMPLS capabilities support this
   scheme).  The exponent, n, indicates the number of times an M:N
   recovery type is applied between at most n different ingress-egress
   node pairs.  So the interpretation follows from the previous case,
   except that here disjointness applies to the N working LSPs/spans and
   to the M recovery LSPs/spans while sharing at most n times M common
   resources.

   In both schemes, it results in a "group" of sum{n=1}^N N{n} working
   LSPs and a pool of shared recovery resources, not all of which are
   available to any given working LSP.  In such conditions, defining a
   metric that describes the amount of overlap among the recovery LSPs
   would give some indication of the group’s ability to handle
   simultaneous failures of multiple LSPs.

   For instance, in the simple (1:1)^n case, if n recovery LSPs in a
   (1:1)^n group overlap, then the group can handle only single
   failures; any simultaneous failure of multiple working LSPs will
   cause at least one working LSP to be denied automatic recovery.  But
   if one considers, for instance, a (2:2)^2 group in which there are
   two pairs of overlapping recovery LSPs, then two LSPs (belonging to
   the same pair) can be simultaneously recovered.  The latter case can
   be illustrated by the following topology with 2 pairs of working LSPs
   A-B-C and F-G-H and their respective recovery LSPs A-D-E-C and
   F-D-E-H that share two common D-E link resources.

                           A========B========C
                           \\               //
                            \\             //
                             D =========== E
                            //             \\
                           //               \\
                           F========G========H

   Moreover, in all these schemes, (working) path disjointness can be
   enforced by exchanging information related to working LSPs during the
   recovery LSP signaling.  Specific issues related to the combination
   of shared (discrete) bandwidth and disjointness for recovery schemes
   are described in Section 8.4.2.

5.5.  LSP Recovery Mechanisms

5.5.1.  Classification

   The recovery time and ratio of LSPs/spans depend on proper recovery
   LSP provisioning (meaning pre-provisioning when performed before
   failure occurrence) and the level of overbooking of recovery
   resources (i.e., over-provisioning).  A proper balance of these two
   operations will result in the desired LSP/span recovery time and
   ratio when single or multiple failures occur.  Note also that these
   operations are mostly performed during the network planning phases.

   The different options for LSP (pre-)provisioning and overbooking are
   classified below to structure the analysis of the different recovery
   mechanisms.

   1. Pre-Provisioning

   Proper recovery LSP pre-provisioning will help to alleviate the
   failure of the working LSPs (due to the failure of the resources that
   carry these LSPs).  As an example, one may compute and establish the
   recovery LSP either end-to-end or segment-per-segment, to protect a
   working LSP from multiple failure events affecting link(s), node(s)
   and/or SRLG(s).  The recovery LSP pre-provisioning options are
   classified as follows in the figure below:

   (1) The recovery path can be either pre-computed or computed on-
       demand.

   (2) When the recovery path is pre-computed, it can be either pre-
       signaled (implying recovery resource reservation) or signaled
       on-demand.

   (3) When the recovery resources are pre-signaled, they can be either
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容