Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 6372


MPLS Transport Profile (MPLS-TP) Survivability Framework

Part 2 of 3, p. 10 to 37
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 10 
4.  Functional Architecture

   This section presents an overview of the elements relating to the
   functional architecture for survivability within an MPLS-TP network.
   The components are presented separately to demonstrate the way in
   which they may be combined to provide the different grades of
   recovery needed to meet the requirements set out in the previous

4.1.  Elements of Control

   Recovery is achieved by implementing specific actions.  These actions
   aim to repair network resources or redirect traffic along paths that
   avoid failures in the network.  They may be triggered automatically
   by the MPLS-TP network nodes upon detection of a network defect, or
   they may be triggered by an operator.  Automated actions may be
   enhanced by in-band (i.e., data-plane-based) OAM mechanisms, or by
   in-band or out-of-band control-plane signaling.

Top      Up      ToC       Page 11 
4.1.1.  Operator Control

   The survivability behavior of the network as a whole, and the
   reaction of each transport path when a fault is reported, may be
   controlled by the operator.  This control can be split into two sets
   of functions: policies and actions performed when the transport path
   is set up, and commands used to control or force recovery actions for
   established transport paths.

   The operator may establish network-wide or local policies that
   determine the actions that will be taken when various defects are
   reported that affect different transport paths.  Also, when a service
   request is made that causes the establishment of one or more
   transport paths in the network, the operator (or requesting
   application) may define a particular grade of service, and this will
   be mapped to specific survivability actions taken before and during
   transport path setup, after the discovery of a failure of network
   resources, and upon recovery of those resources.

   It should be noted that it is unusual to present a user or customer
   with options directly related to recovery actions.  Instead, the
   user/customer enters into an SLA with the network provider, and the
   network operator maps the terms of the SLA (for example, for
   guaranteed delivery, availability, or reliability) to recovery
   schemes within the network.

   The operator can also issue commands to control recovery actions and
   events.  For example, the operator may perform the following actions:

   o  Enable or disable the survivability function.

   o  Invoke the simulation of a network fault.

   o  Force a switchover from a working path to a recovery path or vice

   Forced switchover may be performed for network optimization purposes
   with minimal service interruption, such as when modifying protected
   or unprotected services, when replacing MPLS-TP network nodes, etc.
   In some circumstances, a fault may be reported to the operator, and
   the operator may then select and initiate the appropriate recovery
   action.  A description of the different operator commands is found in
   Section 4.12 of [RFC4427].

Top      Up      ToC       Page 12 
4.1.2.  Defect-Triggered Actions

   Survivability actions may be directly triggered by network defects.
   This means that the device that detects the defect (for example,
   notification of an issue reported from equipment in a lower layer,
   failure to receive an OAM Continuity message, or receipt of an OAM
   message reporting a failure condition) may immediately perform a
   survivability action.

   The action is directly triggered by events in the data plane.  Note,
   however, that coordination of recovery actions between the edges of
   the recovery domain may require message exchanges for some recovery
   functions or for performing a bidirectional recovery action.

4.1.3.  OAM Signaling

   OAM signaling refers to data-plane OAM message exchange.  Such
   messages may be used to detect and localize faults or to indicate a
   degradation in the operation of the network.  However, in this
   context these messages are used to control or trigger survivability
   actions.  The mechanisms to achieve this are discussed in [RFC6371].

   OAM signaling may also be used to coordinate recovery actions within
   the protection domain.

4.1.4.  Control-Plane Signaling

   Control-plane signaling is responsible for setup, maintenance, and
   teardown of transport paths that do not fall under management-plane
   control.  The control plane may also be used to coordinate the
   detection, localization, and reaction to network defects pertaining
   to peer relationships (neighbor-to-neighbor or end-to-end).  Thus,
   control-plane signaling may initiate and coordinate survivability

   The control plane can also be used to distribute topology and
   information relating to resource availability.  In this way, the
   "graceful shutdown" [RFC5817] of resources may be affected by
   withdrawing them; this can be used to invoke a survivability action
   in a similar way to that used when reporting or discovering a fault,
   as described in the previous sections.

   The use of a control plane for MPLS-TP is discussed in [RFC6373].

Top      Up      ToC       Page 13 
4.2.  Recovery Scope

   This section describes the elements of recovery.  These are the
   quantitative aspects of recovery, that is, the parts of the network
   for which recovery can be provided.

   Note that the terminology in this section is consistent with
   [RFC4427].  Where the terms differ from those in [RFC5654], mapping
   is provided.

4.2.1.  Span Recovery

   A span is a single hop between neighboring MPLS-TP nodes in the same
   network layer.  A span is sometimes referred to as a link, and this
   may cause some confusion between the concept of a data link and a
   traffic engineering (TE) link.  LSPs traverse TE links between
   neighboring MPLS-TP nodes in the MPLS-TP network layer.  However, a
   TE link may be provided by any of the following:

   o  A single data link.

   o  A series of data links in a lower layer, established as an LSP and
      presented to the upper layer as a single TE link.

   o A set of parallel data links in the same layer, presented either as
      a bundle of TE links, or as a collection of data links that
      together provide a data-link-layer protection scheme.

   Thus, span recovery may be provided by any of the following:

   o  Selecting a different TE link from a bundle.

   o  Moving the TE link so that it is supported by a different data
      link between the same pair of neighbors.

   o  Rerouting the LSP in the lower layer.

   Moving the protected LSP to another TE link between the same pair of
   neighbors is a form of segment recovery and not a form of span
   recovery.  Segment Recovery is described in Section 4.2.2.

4.2.2.  Segment Recovery

   An LSP segment comprises one or more continuous hops on the path of
   the LSP.  [RFC5654] defines two terms.  A "segment" is a single hop
   along the path of an LSP, while a "concatenated segment" is more than
   one hop along the path of an LSP.  In the context of this document, a
   segment covers both of these concepts.

Top      Up      ToC       Page 14 
   A PW segment refers to a Single-Segment PW (SS-PW) or to a single
   segment of a Multi-Segment PW (MS-PW) that is set up between two PE
   devices that may be Terminating PEs (T-PEs) or Switching PEs (S-PEs)
   so that the full set of possibilities is T-PE to S-PE, S-PE to S-PE,
   S-PE to T-PE, or T-PE to T-PE (for the SS-PW case).  As indicated in
   Section 1, the recovery of PWs and PW segments is beyond the scope of
   this document; however, see Section 7.

   Segment recovery involves redirecting or copying traffic at the
   source end of a segment onto an alternate path leading to the other
   end of the segment.  According to the required grade of recovery
   (described in Section 4.3), traffic may be either redirected to a
   pre-established segment, through rerouting the protected segment, or
   tunneled to the far end of the protected segment through a "bypass"
   LSP.  For details on recovery mechanisms, see Section 4.4.

   Note that protecting a transport path against node failure requires
   the use of segment recovery or end-to-end recovery, while a link
   failure can be protected using span, segment, or end-to-end recovery.

4.2.3.  End-to-End Recovery

   End-to-end recovery is a special case of segment recovery where the
   protected segment comprises the entire transport path.  End-to-end
   recovery may be provided as link-diverse or node-diverse recovery
   where the recovery path shares no links or no nodes with the working

   Note that node-diverse paths are necessarily link-diverse and that
   full, end-to-end node-diversity is required to guarantee recovery.

   Two observations need to be made about end-to-end recovery.

   - Firstly, there may be circumstances where node-diverse end-to-end
     paths do not guarantee recovery.  The ingress and egress nodes will
     themselves be single points of failure.  Additionally, there may be
     shared risks of failure (for example, geographic collocation,
     shared resources, etc.) between diverse nodes as described in
     Section 4.9.2.

   - Secondly, it is possible to use end-to-end recovery techniques even
     when there is not full diversity and the working and protection
     paths share links or nodes.

Top      Up      ToC       Page 15 
4.3.  Grades of Recovery

   This section describes the qualitative grades of survivability that
   can be provided.  In the event of a network failure, the grade of
   recovery offered directly affects the service grade provided to the
   end-user.  This will be observed as the amount of data lost when a
   network fault occurs, and the length of time required to recover

   In general, there is a correlation between the recovery service grade
   (i.e., the speed of recovery and reduction of data loss) and the
   amount of resources used in the network; better service grades
   require the pre-allocation of resources to the recovery paths, and
   those resources cannot be used for other purposes if high-quality
   recovery is required.  An operator will consider how providing
   different grades of recovery may require that network resources be
   provisioned and allocated for exclusive use of the recovery paths
   such that the resources cannot be used to support other customer

   Sections 6 and 7 of [RFC4427] provide a full breakdown of the
   protection and recovery schemes.  This section summarizes the
   qualitative grades available.

   Note that, in the context of recovery, a useful discussion of the
   term "resource" and its interpretation in both the IETF and ITU-T
   contexts may be found in Section 3.2 of [RFC4397].

   The selection of the recovery grade and schemes to satisfy the
   service grades for an LSP using available network resources is
   subject to network and local policy and may be pre-designated through
   network planning or may be dynamically determined by the network.

4.3.1.  Dedicated Protection

   In dedicated protection, the resources for the recovery entity are
   pre-assigned for the sole use of the protected transport path.  This
   will clearly be the case in 1+1 protection, and may also be the case
   in 1:1 protection where extra traffic (see Section 4.3.3) is not

   Note that when using protection tunnels (see Section 4.4.3),
   resources may also be dedicated to the protection of a specific
   transport path.  In some cases (1:1 protection), the entire bypass
   tunnel may be dedicated to providing recovery for a specific
   transport path, while in other cases (such as facility backup), a
   subset of the resources associated with the bypass tunnel may be pre-
   assigned for the recovery of a specific service.

Top      Up      ToC       Page 16 
   However, as described in Section 4.4.3, the bypass tunnel method can
   also be used for shared protection (Section 4.3.2), either to carry
   extra traffic (Section 4.3.3) or to achieve best-effort recovery
   without the need for resource reservation.

4.3.2.  Shared Protection

   In shared protection, the resources for the recovery entities of
   several services are shared.  These may be shared as 1:n or m:n and
   are shared on individual links.  Link-by-link resource sharing may be
   managed and operated along LSP segments, on PW segments, or on end-
   to-end transport paths (LSP or PW).  Note that there is no
   requirement for m:n recovery in the list of MPLS-TP requirements
   documented in [RFC5654].  Shared protection can be applied in
   different topologies (mesh, ring, etc.) and can utilize different
   protection mechanisms (linear, ring, etc.).

   End-to-end shared protection shares resources between a number of
   paths that have common end points.  Thus, a number of paths (n paths)
   are all protected by one or more protection paths (m paths, where m
   may equal 1).  When there have been m failures, there are no more
   available protection paths, and the n paths are no longer protected.
   Thus, in 1:n protection, one fault can be protected against before
   all the n paths are unprotected.  The fact that the paths have become
   unprotected needs to be conveyed to the path end points since they
   may need to report the change in service grade or may need to take
   further action to increase their protection.  In end-to-end shared
   protection, this communication is simple since the end points are

   In shared mesh protection (see Section 4.7.6), the paths that share
   the protection resources do not necessarily have the same end points.
   This provides a more flexible resource-sharing scheme, but the
   network planning and the coordination of protection state after a
   recovery action are more complex.

   Where a bypass tunnel is used (Section 4.4.3), the tunnel might not
   have sufficient resources to simultaneously protect all of the paths
   for which it offers protection; in the event that all paths were
   affected by network defects and failures at the same time, not all of
   them would be recovered.  Policy would dictate how this situation
   should be handled: some paths might be protected, while others would
   simply fail; the traffic for some paths would be guaranteed, while
   traffic on other paths would be treated as best-effort with the risk
   of dropped packets.  Alternatively, it is possible that protection
   would not be attempted according to local policy at the nodes that
   perform the recovery actions.

Top      Up      ToC       Page 17 
   Shared protection is a trade-off between assigning network resources
   to protection (which is not required most of the time) and risking
   unrecoverable services in the event that multiple network defects or
   failures occur.  Rapid recovery can be achieved with dedicated
   protection, but it is delayed by message exchanges in the management,
   control, or data planes for shared protection.  This means that there
   is also a trade-off between rapid recovery and resource sharing.  In
   some cases, shared protection might not meet the speed required for
   protection, but it may still be faster than restoration.

   These trade-offs may be somewhat mitigated by the following:

   o  Adjusting the value of n in 1:n protection.

   o  Using m:n protection for a value of m > 1.

   o  Establishing new protection paths as each available protection
      path is put into use.

   In an MPLS-TP network, the degree to which a resource is shared
   between LSPs is a policy issue. This policy may be applied to the
   resource or to the LSPs, and may be pre-configured, configured per
   LSP and installed during LSP establishment, or may be dynamically

4.3.3.  Extra Traffic

   Section of [RFC5654] says: "Support for extra traffic (as
   defined in [RFC4427]) is not required in MPLS-TP and MAY be omitted
   from the MPLS-TP specifications".  This document observes that extra
   traffic facilities may therefore be provided as part of the MPLS-TP
   survivability toolkit depending upon the development of suitable
   solution specifications.  The remainder of this section explains the
   concepts of extra traffic without prejudging the decision to specify
   or not specify such solutions.

   Network resources allocated for protection represent idle capacity
   during the time that recovery is not actually required, and can be
   utilized by carrying other traffic, referred to as "extra traffic".

   Note that extra traffic does not need to start or terminate at the
   ends of the entity (e.g., LSP) that it uses.

   When a network resource carrying extra traffic is required for the
   recovery of protected traffic from the failed working path, the extra
   traffic is disrupted.  This disruption make take one of two forms:

Top      Up      ToC       Page 18 
   - In "hard preemption", the extra traffic is excluded from the
     protection resource.  The disruption of the extra traffic is total,
     and the service supported by the extra traffic must be dropped, or
     some form of rerouting or restoration must be applied to the extra
     traffic LSP in order to recover the service.

     Hard preemption is achieved by "setting a switch" on the path of
     the extra traffic such that it no longer flows.  This situation may
     be detected by OAM and reported as a fault, or may be proactively
     reported through OAM or control-plane signaling.

   - In "soft preemption", the extra traffic is not explicitly excluded
     from the protection resource, but is given lower priority than the
     protected traffic.  In a packet network (such as MPLS-TP), this can
     result in oversubscription of the protection resource with the
     result that the extra traffic receives "best-effort" delivery.
     Depending on the volume of protection and extra traffic, and the
     level of oversubscription, the extra traffic may be slightly or
     heavily impacted.

     The event of soft preemption may be detected by OAM and reported as
     a degradation of traffic delivery or as a fault.  It may also be
     proactively reported through OAM or control-plane signaling.

   Note that both hard and soft preemption may utilize additional
   message exchanges in the management, control, or data planes.  These
   messages do not necessarily mean that recovery is delayed, but may
   increase the complexity of the protection system.  Thus, the benefits
   of carrying extra traffic must be weighed against the disadvantages
   of delayed recovery, additional network overhead, and the impact on
   the services that support the extra traffic according to the details
   of the solutions selected.

   Note that extra traffic is not protected by definition, but may be

   Extra traffic is not supported on dedicated protection resources,
   which, by definition, are used for 1+1 protection (Section 4.3.1),
   but it can be supported in other protection schemes, including shared
   protection (Section 4.3.2) and tunnel protection (Section 4.4.3).

   Best-effort traffic should not be confused with extra traffic.  For
   best-effort traffic, the network does not guarantee data delivery,
   and the user does not receive guaranteed quality of service (e.g., in
   terms of jitter, packet loss, delay, etc.).  Best-effort traffic
   depends on the current traffic load.  However, for extra traffic,
   quality can only be guaranteed until resources are required for
   recovery.  At this point, the extra traffic may be completely

Top      Up      ToC       Page 19 
   displaced, may be treated as best effort, or may itself be recovered
   (for example, by restoration techniques).

4.3.4.  Restoration

   This section refers to LSP restoration.  Restoration for PWs is
   beyond the scope of this document (but see Section 7).

   Restoration represents the most effective use of network resources,
   since no resources are reserved for recovery.  However, restoration
   requires the computation of a new path and the activation of a new
   LSP (through the management or control plane).  It may be more time-
   consuming to perform these steps than to implement recovery using
   protection techniques.

   Furthermore, there is no guarantee that restoration will be able to
   recover the service.  It may be that all suitable network resources
   are already in use for other LSPs, so that no new path can be found.
   This problem can be partially mitigated by using LSP setup
   priorities, so that recovery LSPs can preempt existing LSPs with
   lower priorities.

   Additionally, when a network defect occurs, multiple LSPs may be
   disrupted by the same event.  These LSPs may have been established by
   different Network Management Stations (NMSes) or they may have been
   signaled by different head-end MPLS-TP nodes, meaning that multiple
   points in the network will try to compute and establish recovery LSPs
   at the same time.  This can lead to a lack of resources within the
   network and cause recovery failures; some recovery actions will need
   to be retried, resulting in even slower recovery times for some

   Both hard and soft LSP restoration may be supported.  For hard LSP
   restoration, the resources of the working LSP are released before the
   recovery LSP is fully established (i.e., break-before-make).  For
   soft LSP restoration, the resources of the working LSP are released
   after an alternate LSP is fully established (i.e., make-before-
   break).  Note that in the case of reversion (Section 4.3.5), the
   resources associated with the working LSP are not released.

   The restoration resources may be pre-calculated and even pre-signaled
   before the restoration action starts, but not pre-allocated.  This is
   known as pre-planned LSP restoration.  The complete
   establishment/activation of the restoration LSP occurs only when the
   restoration action starts.  Pre-planning may occur periodically and
   provides the most accurate information about the available resources
   in the network.

Top      Up      ToC       Page 20 
4.3.5.  Reversion

   After a service has been recovered and traffic is flowing along the
   recovery LSP, the defective network resource may be replaced.
   Traffic can be redirected back onto the original working LSP (known
   as "reversion"), or it can be left where it is on the recovery LSP
   ("non-revertive" behavior).

   It should be possible to specify the reversion behavior of each
   service; this might even be configured for each recovery instance.

   In non-revertive mode, an additional operational option is possible
   where protection roles are switched, so that the recovery LSP becomes
   the working LSP, while the previous working path (or the resources
   used by the previous working path) are used for recovery in the event
   of an additional fault.

   In revertive mode, it is important to prevent excessive swapping
   between the working and recovery paths in the case of an intermittent
   defect.  This can be addressed by using a reversion delay timer (the
   Wait-To-Restore timer), which controls the length of time to wait
   before reversion following the repair of a fault on the original
   working path.  It should be possible for an operator to configure
   this timer per LSP, and a default value should be defined.

4.4.  Mechanisms for Protection

   This section provides general descriptions (MPLS-TP non-specific) of
   the mechanisms that can be used for protection purposes.  As
   indicated above, while the functional architecture applies to both
   LSPs and PWs, the mechanism for recovery described in this document
   refers to LSPs and LSP segments only.  Recovery mechanisms for
   pseudowires and pseudowire segments are for further study and will be
   described in a separate document (see also Section 7).

4.4.1.  Link-Level Protection

   Link-level protection refers to two paradigms: (1) where protection
   is provided in a lower network layer and (2) where protection is
   provided by the MPLS-TP link layer.

   Note that link-level protection mechanisms do not protect the nodes
   at each end of the entity (e.g., a link or span) that is protected.
   End-to-end or segment protection should be used in conjunction with
   link-level protection to protect against a failure of the edge nodes.

Top      Up      ToC       Page 21 
   Link-level protection offers the following grades of protection:

   o  Full protection where a dedicated protection entity (e.g., a link
      or span) is pre-established to protect a working entity.  When the
      working entity fails, the protected traffic is switched to the
      protecting entity.  In this scenario, all LSPs carried over the
      working entity are recovered (in one protection operation) when
      there is a failure condition.  This is referred to in [RFC4427] as
      "bulk recovery".

   o  Partial protection where only a subset of the LSPs or traffic
      carried over a selected entity is recovered when there is a
      failure condition.  The decision as to which LSPs will be
      recovered and which will not depends on local policy.

   When there is no failure on the working entity, the protection entity
   may transport extra traffic that may be preempted when protection
   switching occurs.

   If link-level protection is available, it may be desirable to allow
   this to be attempted before attempting other recovery mechanisms for
   the transport paths affected by the fault because link-level
   protection may be faster and more conservative of network resources.
   This can be achieved both by limiting the propagation of fault
   condition notifications and by delaying the other recovery actions.
   This consideration of other protection can be compared with the
   discussion of recovery domains (Section 4.5) and recovery in multi-
   layer networks (Section 4.9).

   A protection mechanism may be provided at the MPLS-TP link layer
   (which connects two MPLS-TP nodes).  Such a mechanism can make use of
   the procedures defined in [RFC5586] to set up in-band communication
   channels at the MPLS-TP Section level, to use these channels to
   monitor the health of the MPLS-TP link, and to coordinate the
   protection states between the ends of the MPLS-TP link.

4.4.2.  Alternate Paths and Segments

   The use of alternate paths and segments refers to the paradigm
   whereby protection is performed in the network layer in which the
   protected LSP is located; this applies either to the entire end-to-
   end LSP or to a segment of the LSP.  In this case, hierarchical LSPs
   are not used (compare with Section 4.4.3).

   Different grades of protection may be provided:

   o  Dedicated protection where a dedicated entity (e.g., LSP or LSP
      segment) is (fully) pre-established to protect a working entity

Top      Up      ToC       Page 22 
      (e.g., LSP or LSP segment).  When a failure condition occurs on
      the working entity, traffic is switched onto the protection
      entity.  Dedicated protection may be performed using 1:1 or 1+1
      linear protection schemes.  When the failure condition is
      eliminated, the traffic may revert to the working entity.  This is
      subject to local configuration.

   o  Shared protection where one or more protection entities is pre-
      established to protect against a failure of one or more working
      entities (1:n or m:n).

   When the fault condition on the working entity is eliminated, the
   traffic should revert back to the working entity in order to allow
   other related working entities to be protected by the shared
   protection resource.

4.4.3.  Protection Tunnels

   A protection tunnel is pre-provisioned in order to protect against a
   failure condition along a sequence of spans in the network.  This may
   be achieved using LSP heirarchy.  We call such a sequence a network
   segment.  A failure of a network segment may affect one or more LSPs
   that transit the network segment.

   When a failure condition occurs in the network segment (detected
   either by OAM on the network segment, or by OAM on a concatenated
   segment of one of the LSPs transiting the network segment), one or
   more of the protected LSPs are switched over at the ingress point of
   the network segment and are transmitted over the protection tunnel.
   This is implemented through label stacking.  Label mapping may be an
   option as well.

   Different grades of protection may be provided:

   o  Dedicated protection where the protection tunnel reserves
      sufficient resources to provide protection for all protected LSPs
      without causing service degradation.

   o  Partial protection where the protection tunnel has enough
      resources to protect some of the protected LSPs, but not all of
      them simultaneously.  Policy dictates how this situation should be
      handled: it is possible that some LSPs would be protected, while
      others would simply fail; it is possible that traffic would be
      guaranteed for some LSPs, while for other LSPs it would be treated
      as best effort with the risk of packets being dropped.
      Alternatively, it is possible that protection would not be

Top      Up      ToC       Page 23 
4.5.  Recovery Domains

   Protection and restoration are performed in the context of a recovery
   domain.  A recovery domain is defined between two or more recovery
   reference end points that are located at the edges of the recovery
   domain and that border on the element on which recovery can be
   provided (as described in Section 4.2).  This element can be an end-
   to-end path, a segment, or a span.

   An end-to-end path can be observed as a special segment case where
   the ingress and egress Label Edge Routers (LERs) serve as the
   recovery reference end points.

   In this simple case of a point-to-point (P2P) protected entity, two
   end points reside at the boundary of the protection domain.  An LSP
   can enter through one reference end point and exit the recovery
   domain through another reference end point.

   In the case of unidirectional point-to-multipoint (P2MP), three or
   more end points reside at the boundary of the protection domain.  One
   of the end points is referred to as the source/root, while the others
   are referred to as sinks/leaves.  An LSP can enter the recovery
   domain through the root point and exit the recovery domain through
   the leaf points.

   The recovery mechanism should restore traffic that was interrupted by
   a facility (link or node) fault within the recovery domain.  Note
   that a single link may be part of several recovery domains.  If two
   recovery domains have common links, one recovery domain must be
   contained within the other.  This can be referred to as nested
   recovery domains.  The boundaries of recovery domains may coincide,
   but recovery domains must not overlap.

   Note that the edges of a recovery domain are not protected, and
   unless the whole domain is contained within another recovery domain,
   the edges form a single point of failure.

   A recovery group is defined within a recovery domain and consists of
   a working (primary) entity and one or more recovery (backup) entities
   that reside between the end points of the recovery domain.  To
   guarantee protection in all situations, a dedicated recovery entity
   should be pre-provisioned using disjoint resources in the recovery
   domain, in order to protect against a failure of a working entity.
   Of course, mechanisms to detect faults and to trigger protection
   switching are also needed.

   The method used to monitor the health of the recovery element is
   beyond the scope of this document.  The end points that are

Top      Up      ToC       Page 24 
   responsible for the recovery action must receive information on its
   condition.  The condition of the recovery element may be 'OK',
   'failed', or 'degraded'.

   When the recovery operation is to be triggered by OAM mechanisms, an
   OAM Maintenance Entity Group must be defined for each of the working
   and protection entities.

   The recovery entities and functions in a recovery domain can be
   configured using a management plane or a control plane.  A management
   plane may be used to configure the recovery domain by setting the
   reference points, the working and recovery entities, and the recovery
   type (e.g., 1:1 bidirectional linear protection, ring protection,
   etc.).  Additional parameters associated with the recovery process
   may also be configured.  For more details, see Section 6.1.

   When a control plane is used, the ingress LERs may communicate with
   the recovery reference points that request that protection or
   restoration be configured across a recovery domain.  For details, see
   Section 6.5.

   Cases of multiple interconnections between distinct recovery domains
   create a hierarchical arrangement of recovery domains, since a single
   top-level recovery domain is created from the concatenation of two
   recovery domains with multiple interconnections.  In this case,
   recovery actions may be taken both in the individual, lower-level
   recovery domains to protect any LSP segment that crosses the domain,
   and within the higher-level recovery domain to protect the longer LSP
   segment that traverses the higher-level domain.

   The MPLS-TP recovery mechanism can be arranged to ensure coordination
   between domains.  In interconnected rings, for example, it may be
   preferable to allow the upstream ring to perform recovery before the
   downstream ring, in order to ensure that recovery takes place in the
   ring in which the defect occurred.  Coordination of recovery actions
   is particularly important in nested domains and is discussed further
   in Section 4.9.

4.6.  Protection in Different Topologies

   As described in the requirements listed in Section 3 and detailed in
   [RFC5654], the selected recovery techniques may be optimized for
   different network topologies if the optimized mechanisms perform
   significantly better than the generic mechanisms in the same

   These mechanisms are required (R91 of [RFC5654]) to interoperate with
   the mechanisms defined for arbitrary topologies, in order to allow

Top      Up      ToC       Page 25 
   end-to-end protection and to ensure that consistent protection
   techniques are used across the entire network.  In this context,
   'interoperate' means that the use of one technique must not inhibit
   the use of another technique in an adjacent part of the network for
   use on the same end-to-end transport path, and must not prohibit the
   use of end-to-end protection mechanisms.

   The next sections (4.7 and 4.8) describe two different topologies and
   explain how recovery may be markedly different in those different
   scenarios.  They also develop the concept of a recovery domain and
   show how end-to-end survivability may be achieved through a
   concatenation of recovery domains, each providing some grade of
   recovery in part of the network.

4.7.  Mesh Networks

   A mesh network is any network where there is arbitrary
   interconnectivity between nodes in the network.  Mesh networks are
   usually contrasted with more specific topologies such as hub-and-
   spoke or ring (see Section 4.8), although such networks are actually
   examples of mesh networks.  This section is limited to the discussion
   of protection techniques in the context of mesh networks.  That is,
   it does not include optimizations for specific topologies.

   Linear protection is a protection mechanism that provides rapid and
   simple protection switching.  In a mesh network, linear protection
   provides a very suitable protection mechanism because it can operate
   between any pair of points within the network.  It can protect
   against a defect in a node, a span, a transport path segment, or an
   end-to-end transport path.  Linear protection gives a clear
   indication of the protection status.

   Linear protection operates in the context of a protection domain.  A
   protection domain is a special type of recovery domain (see Section
   4.5) associated with the protection function.  A protection domain is
   composed of the following architectural elements:

   o  A set of end points that reside at the boundary of the protection
      domain.  In the simple case of 1:n or 1+1 P2P protection, two end
      points reside at the boundary of the protection domain.  In each
      transmission direction, one of the end points is referred to as
      the source, and the other is referred to as the sink.  For
      unidirectional P2MP protection, three or more end points reside at
      the boundary of the protection domain.  One of the end points is
      referred to as the source/root, while the others are referred to
      as sinks/leaves.

Top      Up      ToC       Page 26 
   o  A Protection Group consists of one or more working (primary) paths
      and one or more protection (backup) paths that run between the end
      points belonging to the protection domain.  To guarantee
      protection in all scenarios, a dedicated protection path should be
      pre-provisioned to protect against a defect of a working path
      (i.e., 1:1 or 1+1 protection schemes).  In addition, the working
      and the protection paths should be disjoint; i.e., the physical
      routes of the working and the protection paths should be
      physically diverse in every respect.

   Note that if the resources of the protection path are less than those
   of the working path, the protection path may not have sufficient
   resources to protect the traffic of the working path.

   As mentioned in Section 4.3.2, the resources of the protection path
   may be shared as 1:n.  In this scenario, the protection path will not
   have sufficient resources to protect all the working paths at a
   specific time.

   For bidirectional P2P paths, both unidirectional and bidirectional
   protection switching are supported.  If a defect occurs when
   bidirectional protection switching is defined, the protection actions
   are performed in both directions (even if the defect is
   unidirectional).  The protection state is required to operate with a
   level of coordination between the end points of the protection

   In unidirectional protection switching, the protection actions are
   only performed in the affected direction.

   Revertive and non-revertive operations are provided as options for
   the network operator.

   Linear protection supports the protection schemes described in the
   following sub-sections.

4.7.1.  1:n Linear Protection

   In the 1:1 scheme, a protection path is allocated to protect against
   a defect, failure, or a degradation in a working path.  As described
   above, to guarantee protection, the protection entity should support
   the full capacity and bandwidth, although it may be configured (for
   example, because of limited network resource availability) to offer a
   degraded service when compared with the working entity.

   Figure 1 presents 1:1 protection architecture.  In normal conditions,
   data traffic is transmitted over the working entity, while the
   protection entity functions in the idle state.  (OAM may run on the

Top      Up      ToC       Page 27 
   protection entity to verify its state.)  Normal conditions are
   defined when there is no defect, failure, or degradation on the
   working entity, and no administrative configuration or request causes
   traffic to flow over the protection entity.

           |-----------------Protection Domain---------------|

                   /**********Working path***********\
         +--------+   ==============================   +--------+
         | Node  /|                                    |\  Node |
         |  A {<  |                                    | >}  B  |
         |        |                                    |        |
         +--------+   ==============================   +--------+
                              Protection path

                  Figure 1: 1:1 Protection Architecture

   If there is a defect on the working entity or a specific
   administrative request, traffic is switched to the protection entity.

   Note that when operating with non-revertive behavior (see Section
   4.3.5), after the conditions causing the switchover have been
   cleared, the traffic continues to flow on the protection path, but
   the working and protection roles are not switched.

   In each transmission direction, the protection domain source bridges
   traffic onto the appropriate entity, while the sink selects traffic
   from the appropriate entity.  The source and the sink need to
   coordinate the protection states to ensure that bridging and
   selection are performed to and from the same entity.  For this
   reason, a signaling coordination protocol (either a data-plane in-
   band signaling protocol or a control-plane-based signaling protocol)
   is required.

   In bidirectional protection switching, both ends of the protection
   domain are switched to the protection entity (even when the fault is
   unidirectional).  This requires a protocol to coordinate the
   protection state between the two end points of the protection domain.

   When there is no defect, the bandwidth resources of the idle entity
   may be used for traffic with lower priority.  When protection
   switching is performed, the traffic with lower priority may be
   preempted by the protected traffic through tearing down the LSP with
   lower priority, reporting a fault on the LSP with lower priority, or
   by treating the traffic with lower priority as best effort and
   discarding it when there is congestion.

Top      Up      ToC       Page 28 
   In the general case of 1:n linear protection, one protection entity
   is allocated to protect n working entities.  The protection entity
   might not have sufficient resources to protect all the working
   entities that may be affected by fault conditions at a specific time.
   In this case, in order to guaranteed protection, the protection
   entity should support enough capacity and bandwidth to protect any of
   the n working entities.

   When defects or failures occur along multiple working entities, the
   entity to be protected should be prioritized.  The protection states
   between the edges of the protection domain should be fully
   coordinated to ensure consistent behavior.  As explained in Section
   4.3.5, revertive behavior is recommended when 1:n is supported.

4.7.2.  1+1 Linear Protection

   In the 1+1 protection scheme, a fully dedicated protection entity is

   As depicted in Figure 2, data traffic is copied and fed at the source
   to both the working and the protection entities.  The traffic on the
   working and the protection entities is transmitted simultaneously to
   the sink of the protection domain, where selection between the
   working and protection entities is performed (based on some
   predetermined criteria).

            |---------------Protection Domain---------------|

                   /**********Working path************\
         +--------+   ==============================   +--------+
         | Node  /|                                    |\  Node |
         |  A {<  |                                    | >}  Z  |
         |       \|                                    |/       |
         +--------+   ==============================   +--------+
                   \**********Protection path*********/

                 Figure 2: 1+1 Protection Architecture

   Note that control traffic between the edges of the protection domain
   (such as OAM or a control protocol to coordinate the protection
   state, etc.) may be transmitted on an entity that differs from the
   one used for the protected traffic.  These packets should not be
   discarded by the sink.

Top      Up      ToC       Page 29 
   In 1+1 unidirectional protection switching, there is no need to
   coordinate the protection state between the protection controllers at
   both ends of the protection domain.  In 1+1 bidirectional protection
   switching, a protocol is required to coordinate the protection state
   between the edges of the protection domain.

   In both protection schemes, traffic flows end-to-end on the working
   entity after the conditions causing the switchover have been cleared.
   Data selection may return to selecting traffic from the working
   entity if reversion is enabled, and it will require coordination of
   the protection state between the edges of the protection domain.  To
   avoid frequent switching caused by intermittent defects or failures
   when the network is not stable, traffic is not selected from the
   working entity before the Wait-To-Restore (WTR) timer has expired.

4.7.3.  P2MP Linear Protection

   Linear protection may be applied to protect unidirectional P2MP
   entities using 1+1 protection architecture.  The source/root MPLS-TP
   node bridges the user traffic to both the working and protection
   entities.  Each sink/leaf MPLS-TP node selects the traffic from one
   entity according to some predetermined criteria.  Note that when
   there is a fault condition on one of the branches of the P2MP path,
   some leaf MPLS-TP nodes may select the working entity, while other
   leaf MPLS-TP nodes may select traffic from the protection entity.

   In a 1:1 P2MP protection scheme, the source/root MPLS-TP node needs
   to identify the existence of a fault condition on any of the branches
   of the network.  This means that the sink/leaf MPLS-TP nodes need to
   notify the source/root MPLS-TP node of any fault condition.  This
   also necessitates a return path from the sinks/leaves to the
   source/root MPLS-TP node.  When protection switching is triggered,
   the source/root MPLS-TP node selects the protection transport path
   for traffic transfer.

   A form of "segment recovery for P2MP LSPs" could be constructed.
   Given a P2MP LSP, one can protect any possible point of failure (link
   or node) using N backup P2MP LSPs.  Each backup P2MP LSP originates
   from the upstream node with respect to a different possible failure
   point and terminates at all of the destinations downstream of the
   potential failure point.  In case of a failure, traffic is redirected
   to the backup P2MP path.

   Note that such mechanisms do not yet exist, and their exact behavior
   is for further study.

   A 1:n protection scheme for P2MP transport paths is also required by
   [RFC5654].  Such a mechanism is for future study.

Top      Up      ToC       Page 30 
4.7.4.  Triggers for the Linear Protection Switching Action

  Protection switching may be performed when:

   o  A defect condition is detected on the working entity, and the
      protection entity has "no" or an inferior condition.  Proactive
      in-band OAM Continuity Check and Connectivity Verification (CC-V)
      monitoring of both the working and the protection entities may be
      used to enable the rapid detection of a fault condition.  For
      protection switching, it is common to run a CC-V every 3.33 ms.
      In the absence of three consecutive CC-V messages, a fault
      condition is declared.  In order to monitor the working and the
      protection entities, an OAM Maintenance Entity Group should be
      defined for each entity.  OAM indications associated with fault
      conditions should be provided at the edges of the protection
      domain that is responsible for the protection-switching operation.
      Input from OAM performance monitoring that indicates degradation
      in the working entity may also be used as a trigger for protection
      switching.  In the case of degradation, switching to the
      protection entity is needed only if the protection entity can
      exhibit better operating conditions.

   o  An indication is received from a lower-layer server that there is
      a defect in the lower layer.

   o  An external operator command is received (e.g., 'Forced Switch',
      'Manual Switch').  For details, see Section 6.1.2.

   o  A request to switch over is received from the far end.  The far
      end may initiate this request, for example, on receipt of an
      administrative request to switch over, or when bidirectional 1:1
      protection switching is supported and a defect occurred that could
      only be detected by the far end, etc.

   As described above, the protection state should be coordinated
   between the end points of the protection domain.  Control messages
   should be exchanged between the edges of the protection domain to
   coordinate the protection state of the edge nodes.  Control messages
   can be delivered using an in-band, data-plane-driven control protocol
   or a control-plane-based protocol.

   For 50-ms protection switching, it is recommended that an in-band,
   data-plane-driven signaling protocol be used in order to coordinate
   the protection states.  An in-band, data-plane protocol for use in
   MPLS-TP networks is documented in [MPLS-TP-LP] for linear protection
   (ring protection is discussed in Section 4.8 of this document).  This
   protocol is also used to detect mismatches between the configurations
   provisioned at the ends of the protection domain.

Top      Up      ToC       Page 31 
   As described in Section 6.5, the GMPLS control plane already includes
   procedures and message elements to coordinate the protection states
   between the edges of the protection domain.  These procedures and
   protocol messages are specified in [RFC4426], [RFC4872], and
   [RFC4873].  However, these messages lack the capability to coordinate
   the revertive/non-revertive behavior and the consistency of
   configured timers at the edges of the protection domain (timers such
   as WTR, hold-off timer, etc.).

4.7.5.  Applicability of Linear Protection for LSP Segments

   In order to implement data-plane-based linear protection on LSP
   segments, use is made of the Sub-Path Maintenance Element (SPME), an
   MPLS-TP architectural element defined in [RFC5921].  Maintenance
   operations (e.g., monitoring, protection, or management) engage with
   message transmission (e.g., OAM, Protection Path Coordination, etc.)
   in the maintained domain.  Further discussion of the architecture for
   OAM and SPME is found in [RFC5921] and [RFC6371].  An SPME is an LSP
   that is basically defined and used for the purposes of OAM
   monitoring, protection, or management of LSP segments.  The SPME uses
   the MPLS construct of a hierarchical, nested LSP, as defined in

   For linear protection, SPMEs should be defined over the working and
   protection entities between the edges of a protection domain.  OAM
   messages and messages used to coordinate protection state can be
   initiated at the edge of the SPME and sent to the peer edge of the
   SPME.  Note that these messages are sent over the Generic Associated
   Channel (G-ACh) within the SPME, and that they use a two-label stack,
   the SPME label, and, at the bottom of the stack, the G-ACh label
   (GAL) [RFC5586].

   The end-to-end traffic of the LSP, which includes data traffic and
   control traffic (messages for OAM, management, signaling, and to
   coordinate protection state), is tunneled within the SPMEs by means
   of label stacking, as defined in [RFC3031].

   Mapping between an LSP and an SPME can be 1:1; this is similar to the
   ITU-T Tandem Connection element that defines a sub-layer
   corresponding to a segment of a path.  Mapping can also be 1:n to
   allow the scalable protection of a set of LSP segments traversing the
   part of the network in which a protection domain is defined.  Note
   that each of these LSPs can be initiated or terminated at different
   end points in the network, but that they all traverse the protection
   domain and share similar constraints (such as requirements for
   quality of service (QoS), terms of protection, etc.).

Top      Up      ToC       Page 32 
   Note also that in the context of segment protection, the SPMEs serve
   as the working and protection entities.

4.7.6.  Shared Mesh Protection

   For shared mesh protection, the protection resources are used to
   protect multiple LSPs that do not all share the same end points; for
   example, in Figure 3 there are two paths, ABCDE and VWXYZ.  These
   paths do not share end points and cannot, therefore, make use of 1:n
   linear protection, even though they do not have any common points of

   ABCDE may be protected by the path APQRE, while VWXYZ can be
   protected by the path VPQRZ.  In both cases, 1:1 or 1+1 protection
   may be used.  However, it can be seen that if 1:1 protection is used
   for both paths, the PQR network segment does not carry traffic when
   no failures affect either of the two working paths.  Furthermore, in
   the event of only one failure, the PQR segment carries traffic from
   only one of the working paths.

   Thus, it is possible for the network resources on the PQR segment to
   be shared by the two recovery paths.  In this way, mesh protection
   can substantially reduce the number of network resources that have to
   be reserved in order to provide 1:n protection.

              \                 /
               \               /
                \             /
                /             \
               /               \
              /                 \

       Figure 3: A Shared Mesh Protection Topology

   As the network becomes more complex and the number of LSPs increases,
   the potential for shared mesh protection also increases.  However,
   this can quickly become unmanageable owing to the increased
   complexity.  Therefore, shared mesh protection is normally pre-
   planned and configured by the operator, although an automated system
   cannot be ruled out.

   Note that shared mesh protection operates as 1:n linear protection
   (see Section 4.7.1).  However, the protection state needs to be
   coordinated between a larger number of nodes: the end points of the
   shared concatenated protection segment (nodes P and R in the example)

Top      Up      ToC       Page 33 
   as well as the end points of the protected LSPs (nodes A, E, V, and Z
   in the example).

   Additionally, note that the shared-protection resources could be used
   to carry extra traffic.  For example, in Figure 4, an LSP JPQRK could
   be a preemptable LSP that constitutes extra traffic over the PQR
   hops; it would be displaced in the event of a protection event.  In
   this case, it should be noted that the protection state must also be
   coordinated with the ends of the extra-traffic LSPs.

              \                 /
               \               /
                \             /
                /             \
               /               \
              /                 \

       Figure 4: Shared Mesh Protection with Extra Traffic

4.8.  Ring Networks

   Several service providers have expressed great interest in the
   operation of MPLS-TP in ring topologies; they demand a high degree of
   survivability functionality in these topologies.

   Various criteria for optimization are considered in ring topologies,
   such as:

   1.  Simplification in ring operation in terms of the number of OAM
       Maintenance Entities that are needed to trigger the recovery
       actions, the number of recovery elements, the number of
       management-plane transactions during maintenance operations, etc.

   2.  Optimization of resource consumption around the ring, such as the
       number of labels needed for the protection paths that traverse
       the network, the total bandwidth required in the ring to ensure
       path protection, etc. (see R91 of [RFC5654]).

   [RFC5654] introduces a list of requirements for ring protection
   covering the recovery mechanisms needed to protect traffic in a
   single ring as well as traffic that traverses more than one ring.
   Note that configuration and the operation of the recovery mechanisms
   in a ring must scale well with the number of transport paths, the
   number of nodes, and the number of ring interconnects.

Top      Up      ToC       Page 34 
   The requirements for ring protection are fully compatible with the
   generic requirements for recovery.

   The architecture and the mechanisms for ring protection are specified
   in separate documents.  These mechanisms need to be evaluated against
   the requirements specified in [RFC5654], which includes guidance on
   the principles for the development of new mechanisms.

4.9.  Recovery in Layered Networks

   In multi-layer or multi-regional networking [RFC5212], recovery may
   be performed at multiple layers or across nested recovery domains.

   The MPLS-TP recovery mechanism must ensure that the timing of
   recovery is coordinated in order to avoid race scenarios.  This also
   allows the recovery mechanism of the server layer to fix the problem
   before recovery takes place in the MPLS-TP layer, or the MPLS-TP
   layer to perform recovery before a client network.

   A hold-off timer is required to coordinate recovery timing in
   multiple layers or across nested recovery domains.  Setting this
   configurable timer involves a trade-off between rapid recovery and
   the creation of a race condition where multiple layers respond to the
   same fault, potentially allocating resources in an inefficient
   manner.  Thus, the detection of a defect condition in the MPLS-TP
   layer should not immediately trigger the recovery process if the
   hold-off timer is configured as a value other than zero.  Instead,
   the hold-off timer should be started when the defect is detected and,
   on expiry, the recovery element should be checked to determine
   whether the defect condition still exists.  If it does exist, the
   defect triggers the recovery operation.

   The hold-off timer should be configurable.

   In other configurations, where the lower layer does not have a
   restoration capability, or where it is not expected to provide
   protection, the lower layer needs to trigger the higher layer to
   immediately perform recovery.  Although this can be forced by
   configuring the hold-off timer as zero, it may be that because of
   layer independence, the higher layer does not know whether the lower
   layer will perform restoration.  In this case, the higher layer will
   configure a non-zero hold-off timer and rely on the receipt of a
   specific notification from the lower layer if the lower layer cannot
   perform restoration.  Since layer boundaries are always within nodes,
   such coordination is implementation-specific and does not need to be
   covered here.

Top      Up      ToC       Page 35 
   Reference should be made to [RFC3386], which discusses the
   interaction between layers in survivable networks.

4.9.1.  Inherited Link-Level Protection

   Where a link in the MPLS-TP network is formed through connectivity
   (i.e., a packet or non-packet LSP) in a lower-layer network, that
   connectivity may itself be protected; for example, the LSP in the
   lower-layer network may be provisioned with 1+1 protection.  In this
   case, the link in the MPLS-TP network has an inherited grade of

   An LSP in the MPLS-TP network may be provisioned with protection in
   the MPLS-TP network, as already described, or it may be provisioned
   to utilize only those links that have inherited protection.

   By classifying the links in the MPLS-TP network according to the
   grade of protection that they inherited from the server network, it
   is possible to compute an end-to-end path in the MPLS-TP network that
   uses only those links with a specific or superior grade of inherited
   protection.  This means that the end-to-end MPLS-TP LSP can be
   protected at the grade necessary to conform to the SLA without
   needing to provide any additional protection in the MPLS-TP layer.
   This reduces complexity, saves network resources, and eliminates
   protection-switching coordination problems.

   When the requisite grade of inherited protection is not available on
   all segments along the path in the MPLS-TP network, segment
   protection may be used to achieve the desired protection grade.

   It should be noted, however, that inherited protection only applies
   to links.  Nodes cannot be protected in this way.  An operator will
   need to perform an analysis of the relative likelihood and
   consequences of node failure if this approach is taken without
   providing protection in the MPLS-TP LSP or PW layer to handle node

4.9.2.  Shared Risk Groups

   When an MPLS-TP protection scheme is established, it is important
   that the working and protection paths do not share resources in the
   network.  If this is not achieved, a single defect may affect both
   the working and the protection paths with the result that traffic
   cannot be delivered -- since under such a condition the traffic was
   not protected.

Top      Up      ToC       Page 36 
   Note that this restriction does not apply to restoration, since this
   takes place after the fault has occurred, which means that the point
   of failure can be avoided if an available path exists.

   When planning a recovery scheme, it is possible to use a topology map
   of the MPLS-TP layer to select paths that use diverse links and nodes
   within the MPLS-TP network.  However, this does not guarantee that
   the paths are truly diverse; for example, two separate links in an
   MPLS-TP network may be provided by two lambdas in the same optical
   fiber, or by two fibers that cross the same bridge.  Moreover, two
   completely separate MPLS-TP nodes might be situated in the same
   building with a shared power supply.

   Thus, in order to achieve proper recovery planning, the MPLS-TP
   network must have an understanding of the groups of lower-layer
   resources that share a common risk of failure.  From this, MPLS-TP
   shared risk groups can be constructed that show which MPLS-TP
   resources share a common risk of failure.  Diversity of working and
   protection paths can be planned, not only with regard to nodes and
   links but also in order to refrain from using resources from the same
   shared risk groups.

4.9.3.  Fault Correlation

   In a layered network, a low-layer fault may be detected and reported
   by multiple layers and may sometimes lead to the generation of
   multiple fault reports from the same layer.  For example, a failure
   of a data link may be reported by the line cards in an MPLS-TP node,
   but it could also be detected and reported by the MPLS-TP OAM.

   Section 4.6 explains how it is important to coordinate the
   survivability actions configured and operated in a multi-layer
   network in a way that will avoid over-equipping the survivability
   resources in the network, while ensuring that recovery actions are
   performed in only one layer at a time.

   Fault correlation is about understanding which single event has
   generated a set of fault reports, so that recovery actions can be
   coordinated, and so that the fault logging system does not become
   overloaded.  Fault correlation depends on understanding resource use
   at lower layers, shared risk groups, and a wider view with regard to
   the way in which the layers are interrelated.

   Fault correlation is most easily performed at the point of fault
   detection; for example, an MPLS-TP node that receives a fault
   notification from the lower layer, and detects a fault on an LSP in
   the MPLS-TP layer, can easily correlate these two events.
   Furthermore, if the same node detects multiple faults on LSPs that

Top      Up      ToC       Page 37 
   share the same faulty data link, it can easily correlate them.  Such
   a node may use correlation to perform group-based recovery actions
   and can reduce the number of alarm events that it generates to its
   management station.

   Fault correlation may also be performed at a management station that
   receives fault reports from different layers and different nodes in
   the network.  This enables the management station to coordinate
   management-originated recovery actions and to present consolidated
   fault information to the user and automated management systems.

   It is also necessary to correlate fault information detected and
   reported through OAM.  This function would enable a fault detected at
   a lower layer, and reported at a transit node of an MPLS-TP LSP, to
   be correlated with an MPLS-TP-layer fault detected at a Maintenance
   End Point (MEP) -- for example, the egress of the MPLS-TP LSP.  Such
   correlation allows the coordination of recovery actions performed at
   the MEP, but it also requires that the lower-layer fault information
   is propagated to the MEP, which is most easily achieved using a
   control plane, management plane, or OAM message.

(page 37 continued on part 3)

Next RFC Part