GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc6372

Internet Engineering Task Force (IETF) N. Sprecher, Ed. Request for Comments: 6372 Nokia Siemens Networks Category: Informational A. Farrel, Ed. ISSN: 2070-1721 Juniper Networks

                                                        September 2011
      MPLS Transport Profile (MPLS-TP) Survivability Framework

Abstract

 Network survivability is the ability of a network to recover traffic
 delivery following failure or degradation of network resources.
 Survivability is critical for the delivery of guaranteed network
 services, such as those subject to strict Service Level Agreements
 (SLAs) that place maximum bounds on the length of time that services
 may be degraded or unavailable.
 The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a
 packet-based transport technology based on the MPLS data plane that
 reuses many aspects of the MPLS management and control planes.
 This document comprises a framework for the provision of
 survivability in an MPLS-TP network; it describes recovery elements,
 types, methods, and topological considerations.  To enable data-plane
 recovery, survivability may be supported by the control plane,
 management plane, and by Operations, Administration, and Maintenance
 (OAM) functions.  This document describes mechanisms for recovering
 MPLS-TP Label Switched Paths (LSPs).  A detailed description of
 pseudowire recovery in MPLS-TP networks is beyond the scope of this
 document.
 This document is a product of a joint Internet Engineering Task Force
 (IETF) / International Telecommunication Union Telecommunication
 Standardization Sector (ITU-T) effort to include an MPLS Transport
 Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge
 (PWE3) architectures to support the capabilities and functionalities
 of a packet-based transport network as defined by the ITU-T.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents

Sprecher & Farrel Informational [Page 1] RFC 6372 MPLS-TP Survivability Framework September 2011

 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6372.

Copyright Notice

 Copyright (c) 2011 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1. Introduction ....................................................4
    1.1. Recovery Schemes ...........................................4
    1.2. Recovery Action Initiation .................................5
    1.3. Recovery Context ...........................................6
    1.4. Scope of This Framework ....................................7
 2. Terminology and References ......................................8
 3. Requirements for Survivability .................................10
 4. Functional Architecture ........................................10
    4.1. Elements of Control .......................................10
         4.1.1. Operator Control ...................................11
         4.1.2. Defect-Triggered Actions ...........................12
         4.1.3. OAM Signaling ......................................12
         4.1.4. Control-Plane Signaling ............................12
    4.2. Recovery Scope ............................................13
         4.2.1. Span Recovery ......................................13
         4.2.2. Segment Recovery ...................................13
         4.2.3. End-to-End Recovery ................................14
    4.3. Grades of Recovery ........................................15
         4.3.1. Dedicated Protection ...............................15
         4.3.2. Shared Protection ..................................16
         4.3.3. Extra Traffic ......................................17
         4.3.4. Restoration ........................................19
         4.3.5. Reversion ..........................................20
    4.4. Mechanisms for Protection .................................20

Sprecher & Farrel Informational [Page 2] RFC 6372 MPLS-TP Survivability Framework September 2011

         4.4.1. Link-Level Protection ..............................20
         4.4.2. Alternate Paths and Segments .......................21
         4.4.3. Protection Tunnels .................................22
    4.5. Recovery Domains ..........................................23
    4.6. Protection in Different Topologies ........................24
    4.7. Mesh Networks .............................................25
         4.7.1. 1:n Linear Protection ..............................26
         4.7.2. 1+1 Linear Protection ..............................28
         4.7.3. P2MP Linear Protection .............................29
         4.7.4. Triggers for the Linear Protection
                Switching Action ...................................30
         4.7.5. Applicability of Linear Protection for LSP
                Segments ...........................................31
         4.7.6. Shared Mesh Protection .............................32
    4.8. Ring Networks .............................................33
    4.9. Recovery in Layered Networks ..............................34
         4.9.1. Inherited Link-Level Protection ....................35
         4.9.2. Shared Risk Groups .................................35
         4.9.3. Fault Correlation ..................................36
 5. Applicability and Scope of Survivability in MPLS-TP ............37
 6. Mechanisms for Providing Survivability for MPLS-TP LSPs ........39
    6.1. Management Plane ..........................................39
         6.1.1. Configuration of Protection Operation ..............40
         6.1.2. External Manual Commands ...........................41
    6.2. Fault Detection ...........................................41
    6.3. Fault Localization ........................................42
    6.4. OAM Signaling .............................................43
         6.4.1. Fault Detection ....................................44
         6.4.2. Testing for Faults .................................44
         6.4.3. Fault Localization .................................45
         6.4.4. Fault Reporting ....................................45
         6.4.5. Coordination of Recovery Actions ...................46
    6.5. Control Plane .............................................46
         6.5.1. Fault Detection ....................................47
         6.5.2. Testing for Faults .................................47
         6.5.3. Fault Localization .................................48
         6.5.4. Fault Status Reporting .............................48
         6.5.5. Coordination of Recovery Actions ...................49
         6.5.6. Establishment of Protection and Restoration LSPs ...49
 7. Pseudowire Recovery Considerations .............................50
    7.1. Utilization of Underlying MPLS-TP Recovery ................50
    7.2. Recovery in the Pseudowire Layer ..........................51
 8. Manageability Considerations ...................................51
 9. Security Considerations ........................................52
 10. Acknowledgments ...............................................52
 11. References ....................................................53
    11.1. Normative References .....................................53
    11.2. Informative References ...................................54

Sprecher & Farrel Informational [Page 3] RFC 6372 MPLS-TP Survivability Framework September 2011

1. Introduction

 Network survivability is the network's ability to recover traffic
 delivery following the failure or degradation of traffic delivery
 caused by a network fault or a denial-of-service attack on the
 network.  Survivability plays a critical role in the delivery of
 reliable services in transport networks.  Guaranteed services in the
 form of Service Level Agreements (SLAs) require a resilient network
 that very rapidly detects facility or node degradation or failures,
 and immediately starts to recover network operations in accordance
 with the terms of the SLA.
 The MPLS Transport Profile (MPLS-TP) is described in [RFC5921].
 MPLS-TP is designed to be consistent with existing transport network
 operations and management models, while providing survivability
 mechanisms, such as protection and restoration.  The functionality
 provided is intended to be similar to or better than that found in
 established transport networks that set a high benchmark for
 reliability.  That is, it is intended to provide the operator with
 functions with which they are familiar through their experience with
 other transport networks, although this does not preclude additional
 techniques.
 This document provides a framework for MPLS-TP-based survivability
 that meets the recovery requirements specified in [RFC5654].  It uses
 the recovery terminology defined in [RFC4427], which draws heavily on
 [G.808.1], and it refers to the requirements specified in [RFC5654].
 This document is a product of a joint Internet Engineering Task Force
 (IETF) / International Telecommunication Union Telecommunication
 Standardization Sector (ITU-T) effort to include an MPLS Transport
 Profile within the IETF MPLS and PWE3 architectures to support the
 capabilities and functionalities of a packet-based transport network,
 as defined by the ITU-T.

1.1. Recovery Schemes

 Various recovery schemes (for protection and restoration) and
 processes have been defined and analyzed in [RFC4427] and [RFC4428].
 These schemes can also be applied in MPLS-TP networks to re-establish
 end-to-end traffic delivery according to the agreed service
 parameters, and to trigger recovery from "failed" or "degraded"
 transport entities.  In the context of this document, transport
 entities are nodes, links, transport path segments, concatenated
 transport path segments, and entire transport paths.  Recovery
 actions are initiated by the detection of a defect, or by an external
 request (e.g., an operator's request for manual control of protection
 switching).

Sprecher & Farrel Informational [Page 4] RFC 6372 MPLS-TP Survivability Framework September 2011

 [RFC4427] makes a distinction between protection switching and
 restoration mechanisms.
  1. Protection switching uses pre-assigned capacity between nodes,

where the simplest scheme has a single, dedicated protection entity

   for each working entity, while the most complex scheme has m
   protection entities shared between n working entities (m:n).
  1. Restoration uses any capacity available between nodes and usually

involves rerouting. The resources used for restoration may be pre-

   planned (i.e., predetermined, but not yet allocated to the recovery
   path), and recovery priority may be used as a differentiation
   mechanism to determine which services are recovered and which are
   not recovered.
 Both protection switching and restoration may be either
 unidirectional or bidirectional; unidirectional implies that
 protection switching is performed independently for each direction of
 a bidirectional transport path, while bidirectional means that both
 directions are switched simultaneously using appropriate
 coordination, even if the fault applies to only one direction of the
 path.
 Both protection and restoration mechanisms may be either revertive or
 non-revertive as described in Section 4.11 of [RFC4427].
 Preemption priority may be used to determine which services are
 sacrificed to enable the recovery of other services.  Restoration may
 also be either unidirectional or bidirectional.  In general,
 protection actions are completed within time frames amounting to tens
 of milliseconds, while automated restoration actions are normally
 completed within periods ranging from hundreds of milliseconds to a
 maximum of a few seconds.  Restoration is not guaranteed (for
 example, because network resources may not be available at the time
 of the defect).

1.2. Recovery Action Initiation

 The recovery schemes described in [RFC4427] and evaluated in
 [RFC4428] are presented in the context of control-plane-driven
 actions (such as the configuration of the protection entities and
 functions, etc.).  The presence of a distributed control plane in an
 MPLS-TP network is optional.  However, the absence of such a control
 plane does not affect the operation of the network and the use of
 MPLS-TP forwarding, Operations, Administration, and Maintenance
 (OAM), and survivability capabilities.  In particular, the concepts

Sprecher & Farrel Informational [Page 5] RFC 6372 MPLS-TP Survivability Framework September 2011

 discussed in [RFC4427] and [RFC4428] refer to recovery actions
 effected in the data plane; they are equally applicable in MPLS-TP,
 with or without the use of a control plane.
 Thus, some of the MPLS-TP recovery mechanisms do not depend on a
 control plane and use MPLS-TP OAM mechanisms or management actions to
 trigger recovery actions.
 The principles of MPLS-TP protection-switching actions are similar to
 those described in [RFC4427], since the protection mechanism is based
 on the capability to detect certain defects in the transport entities
 within the recovery domain.  The protection-switching controller does
 not care which initiation method is used, provided that it can be
 given information about the status of the transport entities within
 the recovery domain (e.g., OK, signal failure, signal degradation,
 etc.).
 In the context of MPLS-TP, it is imperative to ensure that performing
 switchovers is possible, regardless of the way in which the network
 is configured and managed (for example, regardless of whether a
 control-plane, management-plane, or OAM initiation mechanism is
 used).
 All MPLS and GMPLS protection mechanisms [RFC4428] are applicable in
 an MPLS-TP environment.  It is also possible to provision and manage
 the related protection entities and functions defined in MPLS and
 GMPLS using the management plane [RFC5654].  Regardless of whether an
 OAM, management, or control plane initiation mechanism is used, the
 protection-switching operation is a data-plane operation.
 In some recovery schemes (such as bidirectional protection
 switching), it is necessary to coordinate the protection state
 between the edges of the recovery domain to achieve initiation of
 recovery actions for both directions.  An MPLS-TP protocol may be
 used as an in-band (i.e., data-plane based) control protocol in order
 to coordinate the protection state between the edges of the
 protection domain.  When the MPLS-TP control plane is in use, a
 control-plane-based mechanism can also be used to coordinate the
 protection states between the edges of the protection domain.

1.3. Recovery Context

 An MPLS-TP Label Switched Path (LSP) may be subject to any part of or
 all of MPLS-TP link recovery, path-segment recovery, or end-to-end
 recovery, where:

Sprecher & Farrel Informational [Page 6] RFC 6372 MPLS-TP Survivability Framework September 2011

 o  MPLS-TP link recovery refers to the recovery of an individual link
    (and hence all or a subset of the LSPs routed over the link)
    between two MPLS-TP nodes.  For example, link recovery may be
    provided by server-layer recovery.
 o  Segment recovery refers to the recovery of an LSP segment (i.e.,
    segment and concatenated segment in the language of [RFC5654])
    between two nodes and is used to recover from the failure of one
    or more links or nodes.
 o  End-to-end recovery refers to the recovery of an entire LSP, from
    its ingress to its egress node.
 For additional resiliency, more than one of these recovery techniques
 may be configured concurrently for a single path.
 Co-routed bidirectional MPLS-TP LSPs are defined in a way that allows
 both directions of the LSP to follow the same route through the
 network.  In this scenario, the operator often requires the
 directions to fate-share (that is, if one direction fails, both
 directions should cease to operate).
 Associated bidirectional MPLS-TP LSPs exist where the two directions
 of a bidirectional LSP follow different paths through the network.
 An operator may also request fate-sharing for associated
 bidirectional LSPs.
 The requirement for fate-sharing causes a direct interaction between
 the recovery processes affecting the two directions of an LSP, so
 that both directions of the bidirectional LSP are recovered at the
 same time.  This mode of recovery is termed bidirectional recovery
 and may be seen as a consequence of fate-sharing.
 The recovery scheme operating at the data-plane level can function in
 a multi-domain environment (in the wider sense of a "domain"
 [RFC4726]).  It can also protect against a failure of a boundary node
 in the case of inter-domain operation.  MPLS-TP recovery schemes are
 intended to protect client services when they are sent across the
 MPLS-TP network.

1.4. Scope of This Framework

 This framework introduces the architecture of the MPLS-TP recovery
 domain and describes the recovery schemes in MPLS-TP (based on the
 recovery types defined in [RFC4427]) as well as the principles of
 operation, recovery states, recovery triggers, and information
 exchanges between the different elements that support the reference
 model.

Sprecher & Farrel Informational [Page 7] RFC 6372 MPLS-TP Survivability Framework September 2011

 The framework also describes the qualitative grades of the
 survivability functions that can be provided, such as dedicated
 recovery, shared protection, restoration, etc.  In the event of a
 network failure, the grade of recovery directly affects the service
 grade provided to the end-user.
 The general description of the functional architecture is applicable
 to both LSPs and pseudowires (PWs); however, PW recovery is only
 introduced in Section 7, and the relevant details are beyond the
 scope of this document and are for further study.
 This framework applies to general recovery schemes as well as to
 mechanisms that are optimized for specific topologies and are
 tailored to efficiently handle protection switching.
 This document addresses the need for the coordination of protection
 switching across multiple layers and at sub-layers (for clarity, we
 use the term "layer" to refer equally to layers and sub-layers).
 This allows an operator to prevent race conditions and allows the
 protection-switching mechanism of one layer to recover from a failure
 before switching is invoked at another layer.
 This framework also specifies the functions that must be supported by
 MPLS-TP to provide the recovery mechanisms.  MPLS-TP introduces a
 tool kit to enable recovery in MPLS-TP-based networks and to ensure
 that affected services are recovered in the event of a failure.
 Generally, network operators aim to provide the fastest, most stable,
 and best protection mechanism at a reasonable cost in accordance with
 customer requirements.  The greater the grade of protection required,
 the greater the number of resources will be consumed.  It is
 therefore expected that network operators will offer a wide spectrum
 of service grade.  MPLS-TP-based recovery offers the flexibility to
 select a recovery mechanism, define the granularity at which traffic
 delivery is to be protected, and choose the specific traffic types
 that are to be protected.  With MPLS-TP-based recovery, it should be
 possible to provide different grades of protection for different
 traffic classes within the same path based on the service
 requirements.

2. Terminology and References

 The terminology used in this document is consistent with that defined
 in [RFC4427].  The latter is consistent with [G.808.1].
 However, certain protection concepts (such as ring protection) are
 not discussed in [RFC4427]; for those concepts, the terminology used
 in this document is drawn from [G.841].

Sprecher & Farrel Informational [Page 8] RFC 6372 MPLS-TP Survivability Framework September 2011

 Readers should refer to those documents for normative definitions.
 This document supplies brief summaries of a number of terms for
 reasons of clarity and to assist the reader, but it does not redefine
 terms.
 Note, in particular, the distinction and definitions made in
 [RFC4427] for the following three terms:
 o  Protection: re-establishing end-to-end traffic delivery using pre-
    allocated resources.
 o  Restoration: re-establishing end-to-end traffic delivery using
    resources allocated at the time of need; sometimes referred to as
    "repair" of a service, LSP, or the traffic.
 o  Recovery: a generic term covering both Protection and Restoration.
 Note that the term "survivability" is used in [RFC5654] to cover the
 functional elements of "protection" and "restoration", which are
 collectively known as "recovery".
 Important background information on survivability can be found in
 [RFC3386], [RFC3469], [RFC4426], [RFC4427], and [RFC4428].
 In this document, the following additional terminology is applied:
 o  "Fault Management", as defined in [RFC5950].
 o  The terms "defect" and "failure" are used interchangeably to
    indicate any defect or failure in the sense that they are defined
    in [G.806].  The terms also include any signal degradation event
    as defined in [G.806].
 o  A "fault" is a fault or fault cause as defined in [G.806].
 o  "Trigger" indicates any event that may initiate a recovery action.
    See Section 4.1 for a more detailed discussion of triggers.
 o  The acronym "OAM" is defined as Operations, Administration, and
    Maintenance, consistent with [RFC6291].
 o  A "Transport Entity" is a node, link, transport path segment,
    concatenated transport path segment, or entire transport path.
 o  A "Working Entity" is a transport entity that carries traffic
    during normal network operation.

Sprecher & Farrel Informational [Page 9] RFC 6372 MPLS-TP Survivability Framework September 2011

 o  A "Protection Entity" is a transport entity that is pre-allocated
    and used to protect and transport traffic when the working entity
    fails.
 o  A "Recovery Entity" is a transport entity that is used to recover
    and transport traffic when the working entity fails.
 o  "Survivability Actions" are the steps that may be taken by network
    nodes to communicate faults and to switch traffic from faulted or
    degraded paths to other paths.  This may include sending messages
    and establishing new paths.
 General terminology for MPLS-TP is found in [RFC5921] and [ROSETTA].
 Background information on MPLS-TP requirements can be found in
 [RFC5654].

3. Requirements for Survivability

 MPLS-TP requirements are presented in [RFC5654] and serve as
 normative references for the definition of all MPLS-TP functionality,
 including survivability.  Survivability is presented in [RFC5654] as
 playing a critical role in the delivery of reliable services, and the
 requirements for survivability are set out using the recovery
 terminology defined in [RFC4427].

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
 section.

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.

Sprecher & Farrel Informational [Page 10] RFC 6372 MPLS-TP Survivability Framework September 2011

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
    versa.
 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].

Sprecher & Farrel Informational [Page 11] RFC 6372 MPLS-TP Survivability Framework September 2011

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
 actions.
 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].

Sprecher & Farrel Informational [Page 12] RFC 6372 MPLS-TP Survivability Framework September 2011

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.

Sprecher & Farrel Informational [Page 13] RFC 6372 MPLS-TP Survivability Framework September 2011

 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
 path.
 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.
  1. 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.
  1. 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.

Sprecher & Farrel Informational [Page 14] RFC 6372 MPLS-TP Survivability Framework September 2011

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
 connectivity.
 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
 services.
 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
 supported.
 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.

Sprecher & Farrel Informational [Page 15] RFC 6372 MPLS-TP Survivability Framework September 2011

 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
 common.
 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.

Sprecher & Farrel Informational [Page 16] RFC 6372 MPLS-TP Survivability Framework September 2011

 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
 configured.

4.3.3. Extra Traffic

 Section 2.5.1.1 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:

Sprecher & Farrel Informational [Page 17] RFC 6372 MPLS-TP Survivability Framework September 2011

  1. 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.
  1. 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
 restored.
 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

Sprecher & Farrel Informational [Page 18] RFC 6372 MPLS-TP Survivability Framework September 2011

 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
 services.
 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.

Sprecher & Farrel Informational [Page 19] RFC 6372 MPLS-TP Survivability Framework September 2011

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.

Sprecher & Farrel Informational [Page 20] RFC 6372 MPLS-TP Survivability Framework September 2011

 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

Sprecher & Farrel Informational [Page 21] RFC 6372 MPLS-TP Survivability Framework September 2011

    (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
    attempted.

Sprecher & Farrel Informational [Page 22] RFC 6372 MPLS-TP Survivability Framework September 2011

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

Sprecher & Farrel Informational [Page 23] RFC 6372 MPLS-TP Survivability Framework September 2011

 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
 topology.
 These mechanisms are required (R91 of [RFC5654]) to interoperate with
 the mechanisms defined for arbitrary topologies, in order to allow

Sprecher & Farrel Informational [Page 24] RFC 6372 MPLS-TP Survivability Framework September 2011

 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.

Sprecher & Farrel Informational [Page 25] RFC 6372 MPLS-TP Survivability Framework September 2011

 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
 domain.
 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

Sprecher & Farrel Informational [Page 26] RFC 6372 MPLS-TP Survivability Framework September 2011

 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.

Sprecher & Farrel Informational [Page 27] RFC 6372 MPLS-TP Survivability Framework September 2011

 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
 allocated.
 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.

Sprecher & Farrel Informational [Page 28] RFC 6372 MPLS-TP Survivability Framework September 2011

 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.

Sprecher & Farrel Informational [Page 29] RFC 6372 MPLS-TP Survivability Framework September 2011

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.

Sprecher & Farrel Informational [Page 30] RFC 6372 MPLS-TP Survivability Framework September 2011

 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
 [RFC3031].
 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.).

Sprecher & Farrel Informational [Page 31] RFC 6372 MPLS-TP Survivability Framework September 2011

 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
 failure.
 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.
           A----B----C----D----E
            \                 /
             \               /
              \             /
               P-----Q-----R
              /             \
             /               \
            /                 \
           V----W----X----Y----Z
     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)

Sprecher & Farrel Informational [Page 32] RFC 6372 MPLS-TP Survivability Framework September 2011

 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.
           A----B----C----D----E
            \                 /
             \               /
              \             /
         J-----P-----Q-----R-----K
              /             \
             /               \
            /                 \
           V----W----X----Y----Z
     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.

Sprecher & Farrel Informational [Page 33] RFC 6372 MPLS-TP Survivability Framework September 2011

 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.

Sprecher & Farrel Informational [Page 34] RFC 6372 MPLS-TP Survivability Framework September 2011

 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
 protection.
 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
 failure.

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.

Sprecher & Farrel Informational [Page 35] RFC 6372 MPLS-TP Survivability Framework September 2011

 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

Sprecher & Farrel Informational [Page 36] RFC 6372 MPLS-TP Survivability Framework September 2011

 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.

5. Applicability and Scope of Survivability in MPLS-TP

 The MPLS-TP network can be viewed as two layers (the MPLS LSP layer
 and the PW layer).  The MPLS-TP network operates over data-link
 connections and data-link networks whereby the MPLS-TP links are
 provided by individual data links or by connections in a lower-layer
 network.  The MPLS LSP layer is a mandatory part of the MPLS-TP
 network, while the PW layer is an optional addition for supporting
 specific services.
 MPLS-TP survivability provides recovery from failure of the links and
 nodes in the MPLS-TP network.  The link defects and failures are
 typically caused by defects or failures in the underlying data-link
 connections and networks, but this section is only concerned with
 recovery actions performed in the MPLS-TP network, which must recover
 from the manifestation of any problem as a defect failure in the
 MPLS-TP network.
 This section lists the recovery elements (see Section 1) supported in
 each of the two layers that can recover from defects or failures of
 nodes or links in the MPLS-TP network.

Sprecher & Farrel Informational [Page 37] RFC 6372 MPLS-TP Survivability Framework September 2011

 +--------------+---------------------+------------------------------+
 | Recovery     | MPLS LSP Layer      | PW Layer                     |
 | Element      |                     |                              |
 +--------------+---------------------+------------------------------+
 | Link         | MPLS LSP recovery   | The PW layer is not aware of |
 | Recovery     | can be used to      | the underlying network.      |
 |              | survive the failure | This function is not         |
 |              | of an MPLS-TP link. | supported.                   |
 +--------------+---------------------+------------------------------+
 | Segment/Span | An individual LSP   | For an SS-PW, segment        |
 | Recovery     | segment can be      | recovery is the same as      |
 |              | recovered to        | end-to-end recovery.         |
 |              | survive the failure | Segment recovery for an MS-PW|
 |              | of an MPLS-TP link. | is for future study, and     |
 |              |                     | this function is now         |
 |              |                     | provided using end-to-end    |
 |              |                     | recovery.                    |
 +--------------+---------------------+------------------------------+
 | Concatenated | A concatenated LSP  | Concatenated segment         |
 | Segment      | segment can be      | recovery (in an MS-PW) is for|
 | Recovery     | recovered to        | future study, and this       |
 |              | survive the failure | function is now provided     |
 |              | of an MPLS-TP link  | using end-to-end recovery.   |
 |              | or node.            |                              |
 +--------------+---------------------+------------------------------+
 | End-to-End   | An end-to-end LSP   | End-to-end PW recovery can   |
 | Recovery     | can be recovered to | be applied to survive any    |
 |              | survive any node or | node (including S-PE) or     |
 |              | link failure,       | link failure, except for     |
 |              | except for the      | failure of the ingress or    |
 |              | failure of the      | egress T-PE.                 |
 |              | ingress or egress   |                              |
 |              | node.               |                              |
 +--------------+---------------------+------------------------------+
 | Service      | The MPLS LSP layer  | PW-layer service recovery    |
 | Recovery     | is service-         | requires surviving faults in |
 |              | agnostic.  This     | T-PEs or on Attachment       |
 |              | function is not     | Circuits (ACs).  This is     |
 |              | supported.          | currently out of scope for   |
 |              |                     | MPLS-TP.                     |
 +--------------+---------------------+------------------------------+
               Table 1: Recovery Elements Supported
                by the MPLS LSP Layer and PW Layer
 Section 6 provides a description of mechanisms for MPLS-TP-LSP
 survivability.  Section 7 provides a brief overview of mechanisms for
 MPLS-TP-PW survivability.

Sprecher & Farrel Informational [Page 38] RFC 6372 MPLS-TP Survivability Framework September 2011

6. Mechanisms for Providing Survivability for MPLS-TP LSPs

 This section describes the existing mechanisms that provide LSP
 protection within MPLS-TP networks and highlights areas where new
 work is required.

6.1. Management Plane

 As described above, a fundamental requirement of MPLS-TP is that
 recovery mechanisms should be capable of functioning in the absence
 of a control plane.  Recovery may be triggered by MPLS-TP OAM fault
 management functions or by external requests (e.g., an operator's
 request for manual control of protection switching).  Recovery LSPs
 (and in particular Restoration LSPs) may be provisioned through the
 management plane.
 The management plane may be used to configure the recovery domain by
 setting the reference end-point points (which control the recovery
 actions), the working and the recovery entities, and the recovery
 type (e.g., 1:1 bidirectional linear protection, ring protection,
 etc.).
 Additional parameters associated with the recovery process (such as
 WTR and hold-off timers, revertive/non-revertive operation, etc.) may
 also be configured.
 In addition, the management plane may initiate manual control of the
 recovery function.  A priority should be set for the fault conditions
 and the operator's requests.
 Since provisioning the recovery domain involves the selection of a
 number of options, mismatches may occur at the different reference
 points.  The MPLS-TP protocol to coordinate protection state, which
 is specified in [MPLS-TP-LP], may be used as an in-band (i.e., data-
 plane-based) control protocol to coordinate the protection states
 between the end points of the recovery domain, and to check the
 consistency of configured parameters (such as timers, revertive/non-
 revertive behavior, etc.) with discovered inconsistencies that are
 reported to the operator.
 It should also be possible for the management plane to track the
 recovery status by receiving reports or by issuing polls.

Sprecher & Farrel Informational [Page 39] RFC 6372 MPLS-TP Survivability Framework September 2011

6.1.1. Configuration of Protection Operation

 To implement the protection-switching mechanisms, the following
 entities and information should be configured and provisioned:
 o  The end points of a recovery domain.  As described above, these
    end points border on the element of recovery to which recovery is
    applied.
 o  The protection group, which, depending on the required protection
    scheme, consists of a recovery entity and one or more working
    entities.  In 1:1 or 1+1 P2P protection, the paths of the working
    entity and the recovery entities must be physically diverse in
    every respect (i.e., not share any resources or physical
    locations), in order to guarantee protection.
 o  As defined in Section 4.8, the SPME must be supported in order to
    implement data-plane-based LSP segment recovery, since related
    control messages (e.g., for OAM, Protection Path Coordination,
    etc.) can be initiated and terminated at the edges of a path where
    push and pop operations are enabled.  The SPME is an end-to-end
    LSP that in this context corresponds to the recovery entities
    (working and protection) and makes use of the MPLS construct of
    hierarchical nested LSP, as defined in [RFC3031].  OAM messages
    and messages to coordinate protection state can be initiated at
    the edge of the SPME and sent over G-ACH to the peer edge of the
    SPME.  It is necessary to configure the related SPMEs and map
    between the LSP segments being protected and the SPME.  Mapping
    can be 1:1 or 1:N to allow 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 QoS, terms of protection, etc.).
 o  The protection type that should be defined (e.g., unidirectional
    1:1, bidirectional 1+1, etc.)
 o  Revertive/non-revertive behavior should be configured.
 o  Timers (such as WTR, hold-off timer, etc.) should be set.

Sprecher & Farrel Informational [Page 40] RFC 6372 MPLS-TP Survivability Framework September 2011

6.1.2. External Manual Commands

 The following external, manual commands may be provided for manual
 control of the protection-switching operation.  These commands apply
 to a protection group; they are listed in descending order of
 priority:
 o  Blocked protection action - a manual command to prevent data
    traffic from switching to the recovery entity.  This command
    actually disables the protection group.
 o  Force protection action - a manual command that forces a switch of
    normal data traffic to the recovery entity.
 o Manual protection action - a manual command that forces a switch of
    data traffic to the recovery entity only when there is no defect
    in the recovery entity.
 o Clear switching command - the operator may request that a previous
    administrative switch command (manual or force switch) be cleared.

6.2. Fault Detection

 Fault detection is a fundamental part of recovery and survivability.
 In all schemes, with the exception of some types of 1+1 protection,
 the actions required for the recovery of traffic delivery depend on
 the discovery of some kind of fault.  In 1+1 protection, the selector
 (at the receiving end) may simply be configured to choose the better
 signal; thus, it does not detect a fault or degradation of itself,
 but simply identifies the path that is better for data delivery.
 Faults may be detected in a number of ways depending on the traffic
 pattern and the underlying hardware.  End-to-end faults may be
 reported by the application or by knowledge of the application's data
 pattern, but this is an unusual approach.  There are two more common
 mechanisms for detecting faults in the MPLS-TP layer:
 o  Faults reported by the lower layers.
 o  Faults detected by protocols within the MPLS-TP layer.
 In an IP/MPLS network, the second mechanism may utilize control-plane
 protocols (such as the routing protocols) to detect a failure of
 adjacency between neighboring nodes.  In an MPLS-TP network, it is
 possible that no control plane will be present.  Even if a control
 plane is present, it will be a GMPLS control plane [RFC3945], which
 logically separates control channels from data channels; thus, no
 conclusion about the health of a data channel can be drawn from the

Sprecher & Farrel Informational [Page 41] RFC 6372 MPLS-TP Survivability Framework September 2011

 failure of an associated control channel.  MPLS-TP-layer faults are,
 therefore, only detected through the use of OAM protocols, as
 described in Section 6.4.1.
 Faults may, however, be reported by a lower layer.  These generally
 show up as interface failures or data-link failures (sometimes known
 as connectivity failures) within the MPLS-TP network, for example, an
 underlying optical link may detect loss of light and report a failure
 of the MPLS-TP link that uses it.  Alternatively, an interface card
 failure may be reported to the MPLS-TP layer.
 Faults reported by lower layers are only visible in specific nodes
 within the MPLS-TP network (i.e., at the adjacent end points of the
 MPLS-TP link).  This would only allow recovery to be performed
 locally, so, to enable recovery to be performed by nodes that are not
 immediately local to the fault, the fault must be reported (Sections
 6.4.3 and 6.5.4).

6.3. Fault Localization

 If an MPLS-TP node detects that there is a fault in an LSP (that is,
 not a network fault reported from a lower layer, but a fault detected
 by examining the LSP), it can immediately perform a recovery action.
 However, unless the location of the fault is known, the only
 practical options are:
 o  Perform end-to-end recovery.
 o  Perform some other recovery as a speculative act.
 Since the speculative acts are not guaranteed to achieve the desired
 results and could consume resources unnecessarily, and since end-to-
 end recovery can require a lot of network resources, it is important
 to be able to localize the fault.
 Fault localization may be achieved by dividing the network into
 protection domains.  End-to-end protection is thereby operated on LSP
 segments, depending on the domain in which the fault is discovered.
 This necessitates monitoring of the LSP at the domain edges.
 Alternatively, a proactive mechanism of fault localization through
 OAM (Section 6.4.3) or through the control plane (Section 6.5.3) is
 required.
 Fault localization is particularly important for restoration because
 a new path must be selected that avoids the fault.  It may not be
 practical or desirable to select a path that avoids the entire failed

Sprecher & Farrel Informational [Page 42] RFC 6372 MPLS-TP Survivability Framework September 2011

 working path, and it is therefore necessary to isolate the fault's
 location.

6.4. OAM Signaling

 MPLS-TP provides a comprehensive set of OAM tools for fault
 management and performance monitoring at different nested levels
 (end-to-end, a portion of a path (LSP or PW), and at the link level)
 [RFC6371].
 These tools support proactive and on-demand fault management (for
 fault detection and fault localization) as well as performance
 monitoring (to measure the quality of the signals and detect
 degradation).
 To support fast recovery, it is useful to use some of the proactive
 tools to detect fault conditions (e.g., link/node failure or
 degradation) and to trigger the recovery action.
 The MPLS-TP OAM messages run in-band with the traffic and support
 unidirectional and bidirectional P2P paths as well as P2MP paths.
 As described in [RFC6371], MPLS-TP OAM operates in the context of a
 Maintenance Entity that borders on the OAM responsibilities and
 represents the portion of a path between two points that is monitored
 and maintained, and along which OAM messages are exchanged.
 [RFC6371] refers also to a Maintenance Entity Group (MEG), which is a
 collection of one or more Maintenance Entities (MEs) that belong to
 the same transport path (e.g., P2MP transport path) and which are
 maintained and monitored as a group.
 An ME includes two MEPs (Maintenance Entity Group End Points) that
 reside at the boundaries of an ME, and a set of zero or more MIPs
 (Maintenance Entity Group Intermediate Points) that reside within the
 Maintenance Entity along the path.  A MEP is capable of initiating
 and terminating OAM messages, and as such can only be located at the
 edges of a path where push and pop operations are supported.  In
 order to define an ME over a portion of path, it is necessary to
 support SPMEs.
 The SPME is an end-to-end LSP that in this context corresponds to the
 ME; it uses the MPLS construct of hierarchical nested LSPs, which is
 defined in [RFC3031].  OAM messages can be initiated at the edge of
 the SPME and sent over G-ACH to the peer edge of the SPME.
 The related SPMEs must be configured, and mapping must be performed
 between the LSP segments being monitored and the SPME.  Mapping can
 be 1:1 or 1:N to allow scalable operation.  Note that each of these

Sprecher & Farrel Informational [Page 43] RFC 6372 MPLS-TP Survivability Framework September 2011

 LSPs can be initiated or terminated at different end points in the
 network and can share similar constraints (such as requirements for
 QoS, terms of protection, etc.).
 With regard to recovery, where MPLS-TP OAM is supported, an OAM
 Maintenance Entity Group is defined for each of the working and
 protection entities.

6.4.1. Fault Detection

 MPLS-TP OAM tools may be used proactively to detect the following
 fault conditions between MEPs:
 o  Loss of continuity and misconnectivity - the proactive Continuity
    Check (CC) function is used to detect loss of continuity between
    two MEPs in an MEG.  The proactive Connectivity Verification (CV)
    allows a sink MEP to detect a misconnectivity defect (e.g.,
    mismerge or misconnection) with its peer source MEP when the
    received packet carries an incorrect ME identifier.  For
    protection switching, it is common to run a CC-V (Continuity Check
    and Connectivity Verification) message every 3.33 ms.  In the
    absence of three consecutive CC-V messages, loss of continuity is
    declared and is notified locally to the edge of the recovery
    domain in order to trigger a recovery action.  In some cases, when
    a slower recovery time is acceptable, it is also possible to
    lengthen the transmission rate.
 o  Signal degradation - notification from OAM performance monitoring
    indicating degradation in the working entity may also be used as a
    trigger for protection switching.  In the event of degradation,
    switching to the recovery entity is necessary only if the recovery
    entity can guarantee better conditions.  Degradation can be
    measured by proactively activating MPLS-TP OAM packet loss
    measurement or delay measurement.
 o  A MEP can receive an indication from its sink MEP of a Remote
    Defect Indication and locally notify the end point of the recovery
    domain regarding the fault condition, in order to trigger the
    recovery action.

6.4.2. Testing for Faults

 The management plane may be used to initiate the testing of links,
 LSP segments, or entire LSPs.
 MPLS-TP provides OAM tools that may be manually invoked on-demand for
 a limited period, in order to troubleshoot links, LSP segments, or
 entire LSPs (e.g., diagnostics, connectivity verification, packet

Sprecher & Farrel Informational [Page 44] RFC 6372 MPLS-TP Survivability Framework September 2011

 loss measurements, etc.).  On-demand monitoring covers a combination
 of "in-service" and "out-of-service" monitoring functions.  Out-of-
 service testing is supported by the OAM on-demand lock operation.
 The lock operation temporarily disables the transport entity (LSP,
 LSP segment, or link), preventing the transmission of all types of
 traffic, with the exceptions of test traffic and OAM (dedicated to
 the locked entity).
 [RFC6371] describes the operations of the OAM functions that may be
 initiated on-demand and provides some considerations.
 MPLS-TP also supports in-service and out-of-service testing of the
 recovery (protection and restoration) mechanism, the integrity of the
 protection/recovery transport paths, and the coordination protocol
 between the end points of the recovery domain.  The testing operation
 emulates a protection-switching request but does not perform the
 actual switching action.

6.4.3. Fault Localization

 MPLS-TP provides OAM tools to locate a fault and determine its
 precise location.  Fault detection often only takes place at key
 points in the network (such as at LSP end points or at MEPs).  This
 means that a fault may be located anywhere within a segment of the
 relevant LSP.  Finer information granularity is needed to implement
 optimal recovery actions or to diagnose the fault.  On-demand tools
 like trace-route, loopback, and on-demand CC-V can be used to
 localize a fault.
 The information may be notified locally to the end point of the
 recovery domain to allow implementation of optimal recovery action.
 This may be useful for the re-calculation of a recovery path.
 The information should also be reported to network management for
 diagnostic purposes.

6.4.4. Fault Reporting

 The end points of a recovery domain should be able to detect fault
 conditions in the recovery domain and to notify the management plane.
 In addition, a node within a recovery domain that detects a fault
 condition should also be able to report this to network management.
 Network management should be capable of correlating the fault reports
 and identifying the source of the fault.
 MPLS-TP OAM tools support a function where an intermediate node along
 a path is able to send an alarm report message to the MEP, indicating

Sprecher & Farrel Informational [Page 45] RFC 6372 MPLS-TP Survivability Framework September 2011

 the presence of a fault condition in the server layer that connects
 it to its adjacent node.  This capability allows a MEP to suppress
 alarms that may be generated as a result of a failure condition in
 the server layer.

6.4.5. Coordination of Recovery Actions

 As described above, in some cases (such as in bidirectional
 protection switching, etc.) it is necessary to coordinate the
 protection states between the edges of the recovery domain.
 [MPLS-TP-LP] defines procedures, protocol messages, and elements for
 this purpose.
 The protocol is also used to signal administrative requests (e.g.,
 manual switch, etc.), but only when these are provisioned at the edge
 of the recovery domain.
 The protocol also enables mismatches to be detected between the
 configurations at the ends of the protection domain (such as timers,
 revertive/non-revertive behavior); these mismatches can subsequently
 be reported to the management plane.
 In the absence of suitable coordination (owing to failures in the
 delivery or processing of the coordination protocol messages),
 protection switching will fail.  This means that the operation of the
 protocol that coordinates the protection state is a fundamental part
 of protection switching.

6.5. Control Plane

 The GMPLS control plane has been proposed as the control plane for
 MPLS-TP [RFC5317].  Since GMPLS was designed for use in transport
 networks, and since it has been implemented and deployed in many
 networks, it is not surprising that it contains many features that
 support a high degree of survivability.
 The signaling elements of the GMPLS control plane utilize extensions
 to the Resource Reservation Protocol (RSVP) (as described in a series
 of documents commencing with [RFC3471] and [RFC3473]), although it is
 based on [RFC3209] and [RFC2205].  The architecture for GMPLS is
 provided in [RFC3945], while [RFC4426] gives a functional description
 of the protocol extensions needed to support GMPLS-based recovery
 (i.e., protection and restoration).
 A further control-plane protocol called the Link Management Protocol
 (LMP) [RFC4204] is part of the GMPLS protocol family and can be used
 to coordinate fault localization and reporting.

Sprecher & Farrel Informational [Page 46] RFC 6372 MPLS-TP Survivability Framework September 2011

 Clearly, the control-plane techniques described here only apply where
 an MPLS-TP control plane is deployed and operated.  All mandatory
 MPLS-TP survivability features must be enabled, even in the absence
 of the control plane.  However, when present, the control plane may
 be used to provide alternative mechanisms that may be desirable,
 since they offer simple automation or a richer feature set.

6.5.1. Fault Detection

 The control plane is unable to detect data-plane faults.  However, it
 does provide mechanisms that detect control-plane faults, and these
 can be used to recognize data-plane faults when it is evident that
 the control and data planes are fate-sharing.  Although [RFC5654]
 specifies that MPLS-TP must support an out-of-band control channel,
 it does not insist that it be used exclusively.  This means that
 there may be deployments where an in-band (or at least an in-fiber)
 control channel is used.  In this scenario, failure of the control
 channel can be used to infer that there is a failure of the data
 channel, or, at least, it can be used to trigger an investigation of
 the health of the data channel.
 Both RSVP and LMP provide a control channel "keep-alive" mechanism
 (called the Hello message in both cases).  Failure to receive a
 message in the configured/negotiated time period indicates a control-
 plane failure.  GMPLS routing protocols ([RFC4203] and [RFC5307])
 also include keep-alive mechanisms designed to detect routing
 adjacency failures.  Although these keep-alive mechanisms tend to
 operate at a relatively low frequency (on the order of seconds), it
 is still possible that the first indication of a control-plane fault
 will be received through the routing protocol.
 Note, however, that care must be taken to ascertain that a specific
 failure is not caused by a problem in the control-plane software or
 in a processor component at the far end of a link.
 Because of the various issues involved, it is not recommended that
 the control plane be used as the primary mechanism for fault
 detection in an MPLS-TP network.

6.5.2. Testing for Faults

 The control plane may be used to initiate and coordinate the testing
 of links, LSP segments, or entire LSPs.  This is important in some
 technologies where it is necessary to halt data transmission while
 testing, but it may also be useful where testing needs to be
 specifically enabled or configured.

Sprecher & Farrel Informational [Page 47] RFC 6372 MPLS-TP Survivability Framework September 2011

 LMP provides a control-plane mechanism to test the continuity and
 connectivity (and naming) of individual links.  A single management
 operation is required to initiate the test at one end of the link,
 while the LMP handles the coordination with the other end of the
 link.  The test mechanism for an MPLS packet link relies on the LMP
 Test message inserted into the data stream at one end of the link and
 extracted at the other end of the link.  This mechanism need not
 disrupt data flowing over the link.
 Note that a link in the LMP may, in fact, be an LSP tunnel used to
 form a link in the MPLS-TP network.
 GMPLS signaling (RSVP) offers two mechanisms that may also assist
 with fault testing.  The first mechanism [RFC3473] defines the
 Admin_Status object that allows an LSP to be set into "testing mode".
 The interpretation of this mode is implementation-specific and could
 be documented more precisely for MPLS-TP.  The mode sets the whole
 LSP into a state where it can be tested; this need not be disruptive
 to data traffic.
 The second mechanism provided by GMPLS to support testing is
 described in [GMPLS-OAM].  This protocol extension supports the
 configuration (including enabling and disabling) of OAM mechanisms
 for a specific LSP.

6.5.3. Fault Localization

 Fault localization is the process whereby the exact location of a
 fault is determined.  Fault detection often only takes place at key
 points in the network (such as at LSP end points or at MEPs).  This
 means that a fault may be located anywhere within a segment of the
 relevant LSP.
 If segment or end-to-end protection is in use, this level of
 information is often sufficient to repair the LSP.  However, if finer
 information granularity is required (either to implement optimal
 recovery actions or to diagnose a fault), it is necessary to localize
 the specific fault.
 LMP provides a cascaded test-and-propagate mechanism that is designed
 specifically for this purpose.

6.5.4. Fault Status Reporting

 GMPLS signaling uses the Notify message to report fault status
 [RFC3473].  The Notify message can apply to a single LSP or can carry
 fault information for a set of LSPs, in order to improve the
 scalability of fault notification.

Sprecher & Farrel Informational [Page 48] RFC 6372 MPLS-TP Survivability Framework September 2011

 Since the Notify message is targeted at a specific node, it can be
 delivered rapidly without requiring hop-by-hop processing.  It can be
 targeted at LSP end points or at segment end points (such as MEPs).
 The target points for Notify messages can be manually configured
 within the network, or they may be signaled when the LSP is set up.
 This enables the process to be made consistent with segment
 protection as well as with the concept of Maintenance Entities.
 GMPLS signaling also provides a slower, hop-by-hop mechanism for
 reporting individual LSP faults on a hop-by-hop basis using PathErr
 and ResvErr messages.
 [RFC4783] provides a mechanism to coordinate alarms and other event
 or fault information through GMPLS signaling.  This mechanism is
 useful for understanding the status of the resources used by an LSP
 and for providing information as to why an LSP is not functioning;
 however, it is not intended to replace other fault-reporting
 mechanisms.
 GMPLS routing protocols [RFC4203] and [RFC5307] are used to advertise
 link availability and capabilities within a GMPLS-enabled network.
 Thus, the routing protocols can also provide indirect information
 about network faults; that is, the protocol may stop advertising or
 may withdraw the advertisement for a failed link, or it may advertise
 that the link is about to be shut down gracefully [RFC5817].  This
 mechanisms is, however, not normally considered to be fast enough for
 use as a trigger for protection switching.

6.5.5. Coordination of Recovery Actions

 Fault coordination is an important feature for certain protection
 mechanisms (such as bidirectional 1:1 protection).  The use of the
 GMPLS Notify message for this purpose is described in [RFC4426];
 however, specific message field values have not yet been defined for
 this operation.
 Further work is needed in GMPLS for control and configuration of
 reversion behavior for end-to-end and segment protection, and the
 coordination of timer values.

6.5.6. Establishment of Protection and Restoration LSPs

 The management plane may be used to set up protection and recovery
 LSPs, but, when present, the control plane may be used.

Sprecher & Farrel Informational [Page 49] RFC 6372 MPLS-TP Survivability Framework September 2011

 Several protocol extensions exist that simplify this process:
 o  [RFC4872] provides features that support end-to-end protection
    switching.
 o  [RFC4873] describes the establishment of a single, segment-
    protected LSP.  Note that end-to-end protection is a special case
    of segment protection, and [RFC4872] can also be used to provide
    end-to-end protection.
 o  [RFC4874] allows an LSP to be signaled with a request that its
    path exclude specified resources such as links, nodes, and shared
    risk link groups (SRLGs).  This allows a disjoint protection path
    to be requested or a recovery path to be set up to avoid failed
    resources.
 o  Lastly, it should be noted that [RFC5298] provides an overview of
    the GMPLS techniques available to achieve protection in multi-
    domain environments.

7. Pseudowire Recovery Considerations

 Pseudowires provide end-to-end connectivity over the MPLS-TP network
 and may comprise a single pseudowire segment, or multiple segments
 "stitched" together to provide end-to-end connectivity.
 The pseudowire may, itself, require protection, in order to meet the
 service-level guarantees of its SLA.  This protection could be
 provided by the MPLS-TP LSPs that support the pseudowire, or could be
 a feature of the pseudowire layer itself.
 As indicated above, the functional architecture described in this
 document applies to both LSPs and pseudowires.  However, the recovery
 mechanisms for pseudowires are for further study and will be defined
 in a separate document by the PWE3 working group.

7.1. Utilization of Underlying MPLS-TP Recovery

 MPLS-TP PWs are carried across the network inside MPLS-TP LSPs.
 Therefore, an obvious way to provide protection for a PW is to
 protect the LSP that carries it.  Such protection can take any of the
 forms described in this document.  The choice of recovery scheme will
 depend on the required speed of recovery and the traffic loss that is
 acceptable for the SLA that the PW is providing.
 If the PW is a Multi-Segment PW, then LSP recovery can only protect
 the PW in individual segments.  This means that a single LSP recovery
 action cannot protect against a failure of a PW switching point (an

Sprecher & Farrel Informational [Page 50] RFC 6372 MPLS-TP Survivability Framework September 2011

 S-PE), nor can it protect more than one segment at a time, since the
 LSP tunnel is terminated at each S-PE.  In this respect, LSP
 protection of a PW is very similar to link-level protection offered
 to the MPLS-TP LSP layer by an underlying network layer (see Section
 4.9).

7.2. Recovery in the Pseudowire Layer

 Recovery in the PW layer can be provided by simply running separate
 PWs end-to-end.  Other recovery mechanisms in the PW layer, such as
 segment or concatenated segment recovery, or service-level recovery
 involving survivability of T-PE or AC faults will be described in a
 separate document.
 As with any recovery mechanism, it is important to coordinate between
 layers.  This coordination is necessary to ensure that actions
 associated with recovery mechanisms are only performed in one layer
 at a time (that is, the recovery of an underlying LSP needs to be
 coordinated with the recovery of the PW itself).  It also makes sure
 that the working and protection PWs do not both use the same MPLS
 resources within the network (for example, by running over the same
 LSP tunnel; see also Section 4.9).

8. Manageability Considerations

 Manageability of MPLS-TP networks and their functions is discussed in
 [RFC5950].  OAM features are discussed in [RFC6371].
 Survivability has some key interactions with management, as described
 in this document.  In particular:
 o  Recovery domains may be configured in a way that prevents one-to-
    one correspondence between the MPLS-TP network and the recovery
    domains.
 o  Survivability policies may be configured per network, per recovery
    domain, or per LSP.
 o  Configuration of OAM may involve the selection of MEPs; enabling
    OAM on network segments, spans, and links; and the operation of
    OAM on LSPs, concatenated LSP segments, and LSP segments.
 o  Manual commands may be used to control recovery functions,
    including forcing recovery and locking recovery actions.
 See also the considerations regarding security for management and OAM
 in Section 9 of this document.

Sprecher & Farrel Informational [Page 51] RFC 6372 MPLS-TP Survivability Framework September 2011

9. Security Considerations

 This framework does not introduce any new security considerations;
 general issues relating to MPLS security can be found in [RFC5920].
 However, several points about MPLS-TP survivability should be noted
 here.
 o  If an attacker is able to force a protection switch-over, this may
    result in a small perturbation to user traffic and could result in
    extra traffic being preempted or displaced from the protection
    resources.  In the case of 1:n protection or shared mesh
    protection, this may result in other traffic becoming unprotected.
    Therefore, it is important that OAM protocols for detecting or
    notifying faults use adequate security to prevent them from being
    used (through the insertion of bogus messages or through the
    capture of legitimate messages) to falsely trigger a recovery
    event.
 o  If manual commands are modified, captured, or simulated (including
    replay), it might be possible for an attacker to perform forced
    recovery actions or to impose lock-out.  These actions could
    impact the capability to provide the recovery function and could
    also affect the normal operation of the network for other traffic.
    Therefore, management protocols used to perform manual commands
    must allow the operator to use appropriate security mechanisms.
    This includes verification that the user who performs the commands
    has appropriate authorization.
 o  If the control plane is used to configure or operate recovery
    mechanisms, the control-plane protocols must also be capable of
    providing adequate security.

10. Acknowledgments

 Thanks to the following people for useful comments and discussions:
 Italo Busi, David McWalter, Lou Berger, Yaacov Weingarten, Stewart
 Bryant, Dan Frost, Lievren Levrau, Xuehui Dai, Liu Guoman, Xiao Min,
 Daniele Ceccarelli, Scott Bradner, Francesco Fondelli, Curtis
 Villamizar, Maarten Vissers, and Greg Mirsky.
 The Editors would like to thank the participants in ITU-T Study Group
 15 for their detailed review.
 Some figures and text on shared mesh protection were borrowed from
 [MPLS-TP-MESH] with thanks to Tae-sik Cheung and Jeong-dong Ryoo.

Sprecher & Farrel Informational [Page 52] RFC 6372 MPLS-TP Survivability Framework September 2011

11. References

11.1. Normative References

 [G.806]        ITU-T, "Characteristics of transport equipment -
                Description methodology and generic functionality",
                Recommendation G.806, January 2009.
 [G.808.1]      ITU-T, "Generic Protection Switching - Linear trail
                and subnetwork protection", Recommendation G.808.1,
                December 2003.
 [G.841]        ITU-T, "Types and Characteristics of SDH Network
                Protection Architectures", Recommendation G.841,
                October 1998.
 [RFC2205]      Braden, R., Ed., Zhang, L., Berson, S., Herzog, S.,
                and S. Jamin, "Resource ReSerVation Protocol (RSVP) --
                Version 1 Functional Specification", RFC 2205,
                September 1997.
 [RFC3209]      Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
                V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
                LSP Tunnels", RFC 3209, December 2001.
 [RFC3471]      Berger, L., Ed., "Generalized Multi-Protocol Label
                Switching (GMPLS) Signaling Functional Description",
                RFC 3471, January 2003.
 [RFC3473]      Berger, L., Ed., "Generalized Multi-Protocol Label
                Switching (GMPLS) Signaling Resource ReserVation
                Protocol-Traffic Engineering (RSVP-TE) Extensions",
                RFC 3473, January 2003.
 [RFC3945]      Mannie, E., Ed., "Generalized Multi-Protocol Label
                Switching (GMPLS) Architecture", RFC 3945, October
                2004.
 [RFC4203]      Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF
                Extensions in Support of Generalized Multi-Protocol
                Label Switching (GMPLS)", RFC 4203, October 2005.
 [RFC4204]      Lang, J., Ed., "Link Management Protocol (LMP)", RFC
                4204, October 2005.

Sprecher & Farrel Informational [Page 53] RFC 6372 MPLS-TP Survivability Framework September 2011

 [RFC4427]      Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery
                (Protection and Restoration) Terminology for
                Generalized Multi-Protocol Label Switching (GMPLS)",
                RFC 4427, March 2006.
 [RFC4428]      Papadimitriou, D., Ed., and E. Mannie, Ed., "Analysis
                of Generalized Multi-Protocol Label Switching
                (GMPLS)-based Recovery Mechanisms (including
                Protection and Restoration)", RFC 4428, March 2006.
 [RFC4873]      Berger, L., Bryskin, I., Papadimitriou, D., and A.
                Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
 [RFC5307]      Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS
                Extensions in Support of Generalized Multi-Protocol
                Label Switching (GMPLS)", RFC 5307, October 2008.
 [RFC5317]      Bryant, S., Ed., and L. Andersson, Ed., "Joint Working
                Team (JWT) Report on MPLS Architectural Considerations
                for a Transport Profile", RFC 5317, February 2009.
 [RFC5586]      Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant,
                Ed., "MPLS Generic Associated Channel", RFC 5586, June
                2009.
 [RFC5654]      Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M.,
                Ed., Sprecher, N., and S. Ueno, "Requirements of an
                MPLS Transport Profile", RFC 5654, September 2009.
 [RFC5921]      Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed.,
                Levrau, L., and L. Berger, "A Framework for MPLS in
                Transport Networks", RFC 5921, July 2010.
 [RFC5950]      Mansfield, S., Ed., Gray, E., Ed., and K. Lam, Ed.,
                "Network Management Framework for MPLS-based Transport
                Networks", RFC 5950, September 2010.
 [RFC6371]      Buci, I., Ed. and B. Niven-Jenkins, Ed., "A Framework
                for MPLS in Transport Networks", RFC 6371, September
                2011.

11.2. Informative References

 [GMPLS-OAM]    Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE
                extensions for OAM Configuration", Work in Progress,
                July 2011.

Sprecher & Farrel Informational [Page 54] RFC 6372 MPLS-TP Survivability Framework September 2011

 [MPLS-TP-LP]   Weingarten, Y., Osborne, E., Sprecher, N., Fulignoli,
                A., Ed., and Y. Weingarten, Ed., "MPLS-TP Linear
                Protection", Work in Progress, August 2011.
 [MPLS-TP-MESH] Cheung, T. and J. Ryoo, "MPLS-TP Shared Mesh
                Protection", Work in Progress, April 2011.
 [RFC3031]      Rosen, E., Viswanathan, A., and R. Callon,
                "Multiprotocol Label Switching Architecture", RFC
                3031, January 2001.
 [RFC3386]      Lai, W., Ed., and D. McDysan, Ed., "Network Hierarchy
                and Multilayer Survivability", RFC 3386, November
                2002.
 [RFC3469]      Sharma, V., Ed., and F. Hellstrand, Ed., "Framework
                for Multi-Protocol Label Switching (MPLS)-based
                Recovery", RFC 3469, February 2003.
 [RFC4397]      Bryskin, I. and A. Farrel, "A Lexicography for the
                Interpretation of Generalized Multiprotocol Label
                Switching (GMPLS) Terminology within the Context of
                the ITU-T's Automatically Switched Optical Network
                (ASON) Architecture", RFC 4397, February 2006.
 [RFC4426]      Lang, J., Ed., Rajagopalan, B., Ed., and D.
                Papadimitriou, Ed., "Generalized Multi-Protocol Label
                Switching (GMPLS) Recovery Functional Specification",
                RFC 4426, March 2006.
 [RFC4726]      Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A
                Framework for Inter-Domain Multiprotocol Label
                Switching Traffic Engineering", RFC 4726, November
                2006.
 [RFC4783]      Berger, L., Ed., "GMPLS - Communication of Alarm
                Information", RFC 4783, December 2006.
 [RFC4872]      Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
                Ed., "RSVP-TE Extensions in Support of End-to-End
                Generalized Multi-Protocol Label Switching (GMPLS)
                Recovery", RFC 4872, May 2007.
 [RFC4874]      Lee, CY., Farrel, A., and S. De Cnodder, "Exclude
                Routes - Extension to Resource ReserVation Protocol-
                Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.

Sprecher & Farrel Informational [Page 55] RFC 6372 MPLS-TP Survivability Framework September 2011

 [RFC5212]      Shiomoto, K., Papadimitriou, D., Le Roux, JL.,
                Vigoureux, M., and D. Brungard, "Requirements for
                GMPLS-Based Multi-Region and Multi-Layer Networks
                (MRN/MLN)", RFC 5212, July 2008.
 [RFC5298]      Takeda, T., Ed., Farrel, A., Ed., Ikejiri, Y., and JP.
                Vasseur, "Analysis of Inter-Domain Label Switched Path
                (LSP) Recovery", RFC 5298, August 2008.
 [RFC5817]      Ali, Z., Vasseur, JP., Zamfir, A., and J. Newton,
                "Graceful Shutdown in MPLS and Generalized MPLS
                Traffic Engineering Networks", RFC 5817, April 2010.
 [RFC5920]      Fang, L., Ed., "Security Framework for MPLS and GMPLS
                Networks", RFC 5920, July 2010.
 [RFC6373]      Andersson, L., Ed., Berger, L., Ed., Fang, L., Ed.,
                and Bitar, N., Ed, and E. Gray, Ed., "MPLS-TP Control
                Plane Framework", RFC 6373, September 2011.
 [RFC6291]      Andersson, L., van Helvoort, H., Bonica, R.,
                Romascanu, D., and S. Mansfield, "Guidelines for the
                Use of the "OAM" Acronym in the IETF", BCP 161, RFC
                6291, June 2011.
 [ROSETTA]      Van Helvoort, H., Ed., Andersson, L., Ed., and N.
                Sprecher, Ed., "A Thesaurus for the Terminology used
                in Multiprotocol Label Switching Transport Profile
                (MPLS-TP) drafts/RFCs and ITU-T's Transport Network
                Recommendations", Work in Progress, June 2011.

Authors' Addresses

 Nurit Sprecher (editor)
 Nokia Siemens Networks
 3 Hanagar St.
 Neve Ne'eman B Hod
 Hasharon, 45241 Israel
 EMail: nurit.sprecher@nsn.com
 Adrian Farrel (editor)
 Juniper Networks
 EMail: adrian@olddog.co.uk

Sprecher & Farrel Informational [Page 56]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6372.txt · Last modified: 2011/09/21 17:34 (external edit)