Network Working Group                                     S. Bryant, Ed.
Internet-Draft                                                     Cisco                                                E. Osborne
Intended status: Standards Track                                   Cisco
Expires: January 27, 2011                               N. Sprecher, Ed.
Expires: September 8, 2010
                                                  Nokia Siemens Networks
                                                    H. van Helvoort, Ed.
                                                                  Huawei
                                                       A. Fulignoli, Ed.
                                                                Ericsson
                                                           Y. Weingarten
                                                  Nokia Siemens Networks
                                                           March 7,
                                                           July 26, 2010

                       MPLS-TP Linear Protection
              draft-ietf-mpls-tp-linear-protection-01.txt
              draft-ietf-mpls-tp-linear-protection-02.txt

Abstract

   The MPLS Transport Profile for Multiprotocol Label Switching (MPLS-TP) is
   being specified jointly by IETF and ITU-T includes requirements documents and framework documents.
   The framework documents define the basic architecture that is needed
   in order to support various aspects of the required behavior. ITU-T.  This document addresses
   the functionality described in the MPLS-TP Survivability Framework
   document [SurvivFwk] and defines a protocol that may be used to
   fulfill the function of the Protection State Coordination for linear
   protection, as described in that document.

   This document is a product of a joint Internet Engineering Task Force
   (IETF) / International Telecommunications Union Telecommunications
   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 transport network as
   defined by the ITU-T.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts.
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 8, 2010. January 27, 2011.

Copyright Notice

   Copyright (c) 2010 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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Contributing authors  Protection architectures . . . . . . . . . . . . . . . . .  4
     1.2.  Scope of the document  . .  5
   2.  Conventions used in this document . . . . . . . . . . . . . .  5
     2.1.  Acronyms . .  5
     1.3.  Contributing authors . . . . . . . . . . . . . . . . . . .  6
   2.  Conventions used in this document  . . . .  6
     2.2.  Definitions and Terminology . . . . . . . . . .  6
     2.1.  Acronyms . . . . .  6
   3.  Protection switching logic . . . . . . . . . . . . . . . . . .  6
     3.1.  Protection switching trigger mechanisms . .  7
     2.2.  Definitions and Terminology  . . . . . . .  6
     3.2.  Protection switching control logical architecture . . . .  7
       3.2.1.  PSC Status Module . . . .  7
   3.  Protection switching control logic . . . . . . . . . . . . . .  8
   4.  7
     3.1.  Protection state coordination (PSC) protocol switching control logical architecture  . . . .  7
       3.1.1.  Local Request Logic  . . . . .  8
     4.1.  Transmission and acceptance of PSC control packets . . . .  9
     4.2.  Protocol format . . . . . . . .  8
       3.1.2.  Remote Requests  . . . . . . . . . . . . . 10
       4.2.1.  PSC Requests . . . . . . 10
       3.1.3.  PSC Process Logic  . . . . . . . . . . . . . . . 11
       4.2.2.  Protection Type (PT) . . . 11
       3.1.4.  PSC Message Generator  . . . . . . . . . . . . . . 12
       4.2.3.  Path fault identifier (FPath) . . 11
       3.1.5.  Wait-to-Restore (WTR) timer  . . . . . . . . . . 12
       4.2.4.  Active path indicator (Path) . . . 12
       3.1.6.  PSC Control States . . . . . . . . . . 12
     4.3.  Principles of Operation . . . . . . . . 12
   4.  Protection state coordination (PSC) protocol . . . . . . . . . 13
       4.3.1.
     4.1.  Transmission and acceptance of PSC States control packets . . . . 13
     4.2.  Protocol format  . . . . . . . . . . . . . . . . . . 13
       4.3.2.  Failure or Degraded condition (Working path) . . . 14
       4.2.1.  PSC Ver field  . . . . 14
       4.3.3.  Lockout of Protection . . . . . . . . . . . . . . . . 15
       4.3.4.  Failure or Degraded condition (Recovery path)
       4.2.2.  PSC Request field  . . . . 16
       4.3.5.  Operator Controlled Switching . . . . . . . . . . . . 16
       4.3.6.  Recovery from switching . . 15
       4.2.3.  Protection Type (PT) . . . . . . . . . . . . . . . . . 16
       4.2.4.  Revertive (R) field  . . . . . . . . . . . . . . . . . 16
       4.2.5.  Fault path (FPath) field . . . . . . . . . . . . . . . 16
       4.2.6.  Data path (Path) field . . . . . . . . . . . . . . . . 17
     4.3.  Principles of Operation  . . . . . . . . . . . . . . . . . 17
       4.3.1.  Basic operation  . . . . . . . . . . . . . . . . . . . 17
       4.3.2.  Priority of inputs . . . . . . . . . . . . . . . . . . 18
       4.3.3.  Operation of PSC States  . . . . . . . . . . . . . . . 19
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18 28
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18 28
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 28
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 28
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 19 28
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 19 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 29

1.  Introduction

   As noted in the architecture for Multi-Protocol Label Switching

   The MPLS Transport Profile (MPLS-TP) [TPFwk], the overall architecture [TPFwk] is a framework for MPLS-TP is the
   construction and operation of packet-switched transport networks
   based on a profile of the architectures for MPLS ([RFC3031] and [RFC3032]) and
   Pseudowire (PW) procedures as specified for the MPLS
   Pseudowires (PWs) ([RFC3985] and (MS-)PW
   architectures defined in [RFC3031], [RFC3985] [RFC5659]) and [RFC5085].  One of the basic requirements of
   [RFC5654].

   Network survivability functions, pointed out by is the ability of a network to recover traffic
   delivery following failure, or degradation of network resources.  The
   MPLS-TP Survivability Framework document [SurvivFwk], [SurvivFwk] is that of simple a framework for
   survivability in MPLS-TP networks, and rapid
   protection switching describes recovery elements,
   types, methods, and topological considerations, focusing on
   mechanisms for recovering MPLS-TP Label Switched Paths (LSP) and
   Pseudo-wires (PW).

   Protection switching is a fully allocated survivability (LSPs).

   Linear protection in mesh networks - networks with arbitrary
   interconnectivity between nodes - is described in Section 4.7 of
   [SurvivFwk].  Linear protection 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 an
   intermediate node, a span, a transport path segment, or an end-to-end
   transport path.

1.1.  Protection architectures

   Protection switching is a fully allocated survivability mechanism.
   It is fully allocated in the sense that the route and bandwidth of
   the recovery path is reserved for a selected working path or set of
   working paths.  It provides a fast and simple survivability
   mechanism, that allows the network operator to easily grasp the
   active state of the network, compared to other survivability
   mechanisms.

   As specified in the Survivability Framework document [SurvivFwk],
   protection switching is applied to a protected protection domain.  For the
   purposes of this document, we define the protected protection domain of a P2P
   LSP as consisting of two Label Switching Routers (LSR) (LER) and the
   transport paths that connect them.  For a P2MP LSP the protection
   domain includes the root (or source) LSR, LER, the destination (or sink)
   LSRs, and the transport paths that connect them.

   In 1+1 unidirectional architecture as presented in [SurvivFwk], a
   recovery transport path is dedicated to each working transport path.
   Normal traffic is bridged (as defined in [RFC4427])and fed to both
   the working and the recovery transport entities by a permanent bridge
   at the source of the protection domain.  The sink of the protection
   domain selects which of the working or recovery entities to receive
   the traffic from, based on a predetermined criteria, e.g. server
   defect indication.  When used for bidirectional switching the 1+1
   protection architecture must also support a Protection State
   Coordination (PSC) protocol.  This protocol is used to help
   synchronize the decisions of both ends of the protection domain in
   selecting the proper traffic flow.

   In the 1:1 architecture, a recovery transport path is dedicated to
   the working transport path of a single service.  However, the normal
   traffic is transmitted only once, on either the working or the
   recovery path, by using a selector bridge at the source of the
   protection domain.  A selector at the sink of the protection domain
   then selects the path that carries the normal traffic.  Since the
   source and sink need to be coordinated to ensure that the selector
   bridge at both ends select the same path, this architecture must
   support a PSC protocol.

   The 1:n protection architecture extends this last architecture by
   sharing the recovery path amongst n services.  Again, the recovery
   path is fully allocated and disjoint from any of the n working
   transport paths that it is being used to protect.  The normal data
   traffic for each service is transmitted only once, similar to the 1:1
   case by using a selector bridge at the source, either on the normal
   working path for that service or, in cases that trigger protection
   switching (as defined in [SurvivFwk]), may be sent on the recovery
   path.  It should be noted that in cases where multiple working path
   services have triggered protection switching that some services,
   dependent upon their Service Level Agreement (SLA), may not be
   transmitted as a result of limited resources on the recovery path.
   In this architecture there is may be a need for coordination of the
   protection switching, and in addition there is need for resource
   allocation negotiation.  Due to the added complexity of this
   architecture, the procedures for this will be delayed to a different
   document and further study.

1.2.  Scope of the document

   As was pointed out in the Survivability Framework [SurvivFwk] and
   highlighted above, there is a need for coordination between the end-
   points of the protection domain when employing bidirectional
   protection schemes.  This is especially true when there is a need to
   maintain traffic over a co-routed bidirectional LSP.  This document
   presents

   The scope of this draft is to present a protocol for the Protection
   State Coordination of Linear Protection.  The protocol addresses the
   protection of LSPs in an MPLS-TP network as required by [RFC5654] (in
   particular requirements 63-67 and 74-79) and described in
   [SurvivFwk].  The basic protocol is designed for use in conjunction
   with the 1:1 protection architecture (for both unidirectional and
   bidirectional protection) and for 1+1 protection of a set bidirectional
   path (for both unidirectional and bidirectional protection
   switching).  Applicability of procedures the protocol for activating 1:n protection schemes
   may be documented in a future document.  The applicability of this
   coordination within
   protocol to additional MPLS-TP constructs and topologies may be
   documented in future documents.

   While the unidirectional 1+1 protection domain.

1.1. architecture does not require
   the use of a coordination protocol, the protocol may be used by the
   ingress node of the path to notify the far-side end point that a
   switching condition has occurred and verify the consistency of the
   end-point configuration.  This use may be especially useful for
   point-to-multipoint transport paths, that are unidirectional by
   definition of [RFC5654].

1.3.  Contributing authors

   Hao Long (Huawei) (Huawei), Dan Frost (Cisco), Davide Chiara (Ericsson),
   Francesco Fondelli (Ericsson),

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.1.  Acronyms

   This draft uses the following acronyms:

   DNR     Do not revert
   FS      Forced Switch
   GACH
   G-ACh   Generic Associated Channel Header
   LSR
   LER     Label Switching Router
   MPLS-TP Transport Profile for MPLS
   MS      Manual Switch
   P2P     Point-to-point
   P2MP    Point-to-multipoint
   PDU     Packet Data Unit
   PSC     Protection State Coordination Protocol
   PST     Path Segment Tunnel
   SD      Signal Degrade
   SF      Signal Fail
   SLA     Service Level Agreement
   WTR     Wait-to-Restore

2.2.  Definitions and Terminology

   The terminology used in this document is based on the terminology
   defined in [RFC4427] and further adapted for MPLS-TP in [SurvivFwk].
   In addition, we use the term LSR LER to refer to a MPLS-TP Network
   Element, whether it is a LSR, LER, LER, T-PE, or S-PE.

3.  Protection switching control logic

3.1.  Protection switching trigger mechanisms

   The protection control logical architecture

   Protection switching should be initiated processes the local triggers described in reaction to any of
   the following triggers:

   o  Server layer indication - if the MPLS-TP server layer detects a
      failure within its own layer, or due to a failure of its server
      layer (e.g. the physical layer) notifies the MPLS-TP layer that a
      failure has been detected.  It should be noted that this trigger
      will be controlled by a holdoff-timer that should be configured to
      allow the server layer to apply any protection procedures that may
      be relevant.

   o  OAM signalling - if, for example, OAM continuity and connectivity
      verification tools detect that there is a loss of continuity or
      mis-connectivity or performance monitoring indicates a degradation
      of the utility of the working path for the current transport path.
      In cases of signal degradation, switching to the recovery path
      SHOULD only be activated if the recovery path can guarantee better
      conditions than the degraded working path.

   o  Control plane - if there is a control plane active in the network
      (either signaling or routing), it MAY trigger protection switching
      based on conditions detected by the control plane.  If the
      control-plane is based on GMPLS [RFC3945] then the recovery
      process should comply with the process described in [RFC4872].

   o  Operator command - the network operator may issue commands that
      trigger protection switching.  The commands that are supported
      include - Forced Switch, Manual Switch, Clear, Lockout of
      Protection, (see definitions in [RFC4427]).

3.2.  Protection switching control logical architecture

   Protection switching processes the triggers described above together
   with the inputs received from
   [RFC5654] requirements 74-79 together with inputs received from the
   far-end LSR.  These LER.  Based on these inputs cause the LSR to LER will take certain
   protection switching actions, e.g. switching the Selector Bridge to
   select the working or recovery protection path, and to transmit different
   protocol messages.

   +-------------+

   The following figure shows the logical decomposition of the PSC
   Control Logic into different logical processing units.  These
   processing units are presented in subsequent sub-sections of this
   document.

                  Server Indication     Control Plane Indication
                  -----------------+  +-------------
                Operator Command       Local PSC      +-----------+   |  External   |-----------------+   +-----------------| PSC Status|  |  Interface   OAM Indication
                ----------------+  |  |  +---------------
                                |   request   +---|   Module  |
   +-------------+  |  |             |   +-----------+
                                V  V  V Prot. Stat. ^
   +----------+ Local OAM  +---------------+Highest +------------+ |  V
                             +---------------+         +-------+
                             |   OAM    |----------->| Local Request |------->|  PSC Mess. | |
   |  Module |<--------|  WTR  |  request
                             |    logic      |local R.| Generator  | |
   +----------+   +------->+---------------+        +------------+ |
   +----------+   |      |WTR Exps | Timer |
                             +---------------+         +-------+
                                    |
   | Svr/CP   |---+                      ^
                       Highest local|request               |       |
   +----------+                          V
                                    V                      |
   +-------------+ Start/Stop
                            +-----------------+    PSC Message  |
   | Remote Req.            |
                Remote PSC  |  global Request |                 |
   |  Receiver   |------------>|  PSC  Process   |------------+
               ------------>|      logic      |                 |
   +-------------+
                  Request   +-----------------+
                                    |
          ^                             |                          |
          |       Highest global request|                          |
                                    |                             V  Action         +------------+
                                    +---------------->|  Message   |
                                                      |                    +-----------------+   PSC status Generator  |
   Remote PSC message
                                                      +------------+
                                                            |
                                                 Output PSC Process  |-----------------+
                               |       logic     |--------> Action |                 |
                               +-----------------+ Message
                                                            V

               Figure 1: Protection switching control logic

   Figure 1 describes the logical architecture of the protection
   switching control.  The Local Request logic unit accepts the triggers
   from the OAM, external operator commands, and from the local control
   plane (when present) present), and the Wait-to-Restore timer.  By considering
   all of these local request sources it determines the highest priority
   local request.  This high-priority request is passed to both the PSC Message
   generator, that will generate the appropriate protocol message to be
   sent to the far-end LSR, and the Global Request
   Process logic, that will cross-check this local request with the
   information received from the
   far-LSR.  The Global Request logic then processes these two PSC
   requests that determines the highest priority request that is passed
   to the PSC Process logic. far-end LER.  The PSC Process logic
   uses this input to determine what actions need to be taken, e.g. switching
   local actions at the Selector
   Bridge, LER, or what message should be sent to the far-
   end LER, and the current status of the protection domain.

3.2.1.  PSC Status Module

   The PSC Control

3.1.1.  Local Request Logic must retain the status of

   The protection switching logic processes input triggers from five
   sources:

   o  Operator command - the network operator may issue commands that
      trigger protection
   domain. switching.  The possible different states indicate the current status commands that are supported
      include - Forced Switch, Manual Switch, Clear, Lockout of
   the protection environment, and can be
      Protection, (see definitions in one of three states: [RFC4427]).

   o  Normal (Idle) state  Server layer alarm indication - When both the recovery and underlying server layer of the working paths
      are fully allocated and active, data traffic is being transmitted
      over
      network detects failure conditions at the working path, underlying layer and there are no trigger events reported
      within the domain.

   o  Protecting state - When either may
      issue an indication to the working path has reported a
      signal failure (SF) or degradation of signal (SD), or the operator
      has issued an operator command MPLS-TP layer.  The server layer may
      employ its own protection switching mechanism, and therefore this
      input MAY be controlled by a holdoff-timer that SHOULD be
      configurable by the data traffic has been
      redirected to the recovery path. network operator.

   o  Unavailable state  Control plane - When the recovery path if there is unavailable, either
      as a result of reporting a SF or SD condition, or as a result of
      an administrative Lockout command.

   This state may affect control plane active in the actions taken network
      (either signaling or routing), it MAY trigger protection switching
      based on conditions detected by the control logic, and
   therefore, plane.  If the PSC Status Module transfers
      control-plane is based on GMPLS [RFC3945] then the current status recovery
      process SHALL comply with the process described in [RFC4872].

   o  OAM indication - OAM fault management or performance measurement
      tools may detect a failure or degrade condition on the MPLS-TP
      transport path and this SHOULD input an indication to the Local
      Request Logic.

   See section 4.3.1 for details on what actions are affected by the PSC
   state.

4.  Protection state coordination (PSC) protocol

   Bidirectional protection switching, as well as unidirectional 1:1
   protection, requires coordination between the two end-points

   o  WTR expires - The Wait-to-Restore timer is used in
   determining which of the two possible paths, the working or conjunction
      with recovery
   path, is transmitting from failure conditions on the data traffic in any given situation.  When
   protection switching is triggered as described working path in section 3.1,
      revertive mode.  The timer SHALL signal the
   end-points must inform each other of PSC control process
      when it expires and the switch-over from one path end-point SHOULD revert to the other in a coordinated fashion.

   There are different possibilities for the type normal
      transmission of coordinating
   protocol.  One possibility is a two-phased coordination in which the
   MEP that is initiating user data traffic.

   The Local request logic SHALL process these different input sources
   and, based on the protection switching sends priorities between them, SHOULD produce a protocol
   message indicating current
   local request.  The different local requests that may be output from
   the switch but Local Request Logic are:

   o  Clear - if the actual switch-over is performed
   only after receiving opeartor cancels an 'Ack' from the far-end MEP.  The other
   possibility is a single-phased coordination, in which active local administrative
      command, i.e.  LO/FS/MS.

   o  Lockout of Protection (LO) - if the initiating
   MEP switches over operator requested to disable
      the alternate protection path.

   o  Signal Fail (SF) - if any of the Server Layer, Control plane, or
      OAM indications signaled a failure condition on either the
      protection path and informs or one of the far-end MEP working paths.

   o  Signal Degrade (SD) - if any of the switch, and Server Layer, Control plane,
      or OAM indications signaled a degraded transmission condition on
      either the far-end MEP must complete protection path or one of the switch-over.

   In working paths

   o  Clear Signal Fail - if all of the following sub-sections we describe Server Layer, Control plane, or
      OAM indications are no longer indicating a failure condition on a
      path that was peviously indicating a failure condition.

   o  Forced Switch (FS) - if the protocol messages operator requested that
   should traffic be used between the two end-points
      switched from one of the working paths to the protection domain.

   For path.

   o  Manual Switch (MS) - if the sake of simplicity of operator requested that traffic be
      switched from its current path to the protocol, this protocol other path.  This is based on
   the single-phase approach described above.

4.1.  Transmission and acceptance only
      relevant if there is no currently active Fault condition or
      Operator command.

   o  WTR Expires - generated by the WTR timer completing its period.

   If none of PSC control packets

   The PSC control packets should be transmitted over the recovery path
   only.  This allows input sources have generated any input then the transmission
   current local request SHALL be a No Request (NR) request.

3.1.2.  Remote Requests

   In addition to the local requests generated as a result of the local
   triggers indicated in the previous sub-section, the PSC Control Logic
   SHALL accept PSC messages without affecting from the normal traffic in far-end LER of the most prevalent case, i.e. transport path.
   These remote messages indicate the idle state.
   In addition, limiting status of the transmission to a single transport path avoids
   possible conflicts from
   the viewpoint of the far-end LER, and race conditions that could develop may indicate if the PSC
   messages were sent on both paths.

   Any new PSC control packet must be transmitted immediately when local MEP
   SHOULD initiate a
   change in the transmitted status occurs.

   When protection switch operation.

   The following remote requests may be received by the PSC information is changed, three PSC packets should be
   transmitted as quickly as possible, so process:

   o  Remote LO - indicates that fast protection switching
   would be possible.  Transmission the remote end-point is in Unavailable
      state due to a Lockout of three rapid packets allows for
   fast protection switching even if Protection operator command.

   o  Remote SF - indicates that the remote end-point has detected a
      Signal Fail condition on one or two PSC packets are lost or
   corrupted.  The frequency of the first three packets and transport paths in the separate
   frequency
      protection domain.  This remote message SHALL include an
      indication of the continual transmission which transport path is configurable affected by the
   operator.  For protection switching within 50ms, the default interval
   of the first three PSC signals SF
      condition.  In addition, it should be no larger than 3.3ms.  PSC
   packets after noted that the first three should SF condition
      may be transmitted with an interval
   of 5 seconds.

   If no valid PSC specific information is received, either unidirectional or bidirectional failure, even if the last valid
   received information remains applicable.  In
      transport path is bidirectional.

   o  Remote SD - indicates that the event remote end-point has detected a signal fail
      Signal Degrade condition is detected on one of the recovery path, transport paths in the received PSC specific
   information
      protection domain.  This remote message SHALL include an
      indication of which transport path is affected by the SD
      condition.  In addition, it should be evaluated.

4.2.  Protocol format

   The protocol messages SHALL noted that the SD condition
      may be sent over either unidirectional or bidirectional failure, even if the GACH as described in
   [RFC5586].  There
      transport path is a single channel type for bidirectional.

   o  Remote FS - indicates that the set of PSC
   messages, each message will be identified by remote end point is operating under
      an operator command to switch the first field of traffic to the
   ACH payload as described below.  PSC messages SHOULD support
   addressing by use of protection path.

   o  Remote MS - indicates that the method described in [RFC5586].  The
   following figure shows remote end point is operating under
      an operator command to switch the format traffic to the path that was not
      being used previously.

   o  Remote WTR - indicates that the remote end-point has determined
      that the failure condition has recovered and has started its WTR
      timer in preparation for reverting to the full PSC message.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0|   MPLS-TP Normal state.

   o  Remote DNR - indicates that the remote end-point has determined
      that the failure condition has recovered and will continue
      transporting traffic on the protection path due to operator
      configuration that prevents automatic reversion to the Normal
      state.

   o  Remote NR - indicates that the remote end-point has no abnormal
      condition to report.

3.1.3.  PSC Channel Code    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    ACH TLV Header                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                    Addressing TLV                             +
      :                              ...                              :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~ Process Logic

   The PSC Process Logic SHALL accept as input - a. the Local request
   output from the Local Request Logic, b. the remote request message
   from the remote end-point of the transport path, and c. the current
   state of the PSC Control Packet                         ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 2: Format Logic (maintained internally by the PSC
   Control Logic).  Based on the priorities between the different
   inputs, the PSC Process Logic SHALL determine the new state of the
   PSC packet with a GACH header

   Where:

   o  MPLS-TP Control Logic and what actions need to be taken.

   The new state information SHALL be sent for retention by the State
   Manager, while the requested action SHALL be sent to the PSC Channel Code is Message
   Generator (see subsection 3.1.4) to generate and transmit the GACH channel number assigned proper
   PSC message to be transmitted to the remote end-point of the
   protection domain.

3.1.4.  PSC = TBD

   o  The ACH TLV Header Message Generator

   Based on the action output from the Process Logic this unit formats
   the PSC protocol message that is described transmitted to the remote end-point
   of the protection domain.  When the PSC information has changed three
   PSC messages SHOULD be transmitted in [RFC5586]

   o quick succession, and
   subsequent messages should be transmitted continually at a slower
   rate.

   The use transmission of an Addressing TLV is for further study three rapid packets allows for fast protection
   switching even if one or two PSC messages are lost or corrupted.  For
   protection switching within 50ms, it is RECOMMENDED that the default
   interval of the first three PSC messages SHOULD be no larger than
   3.3ms.  The subsequent messages SHOULD be transmitted with an
   interval of 5 sec, to avoid traffic congestion.

3.1.5.  Wait-to-Restore (WTR) timer

   The WTR timer is used to delay reversion to Normal state when
   recovering from a failure condition on the working path and the
   protection domain is configured for revertive behavior.  The WTR
   timer MAY be started, stopped, or expire.  If the WTR timer is
   running, sending a Stop command SHALL reset the timer but SHALL NOT
   generate a WTR Expires local signal.  If the WTR timer is not
   running, a Stop command SHALL be ignored.

3.1.6.  PSC Control States

   The PSC Control Logic SHOULD maintain information on the current
   state of the protection domain.  The state information SHALL include
   information of the current state and an indication of the cause for
   the current state (e.g. unavailable due to local LO command,
   protecting due to remote FS).  In particular, the state information
   SHOULD include an indication if the state is related to a remote or
   local condition.

   The states that are supported by the PSC Control Logic include:

   o  Normal state - Both the protection and working paths are fully
      allocated and active, data traffic is being transmitted over the
      working path, and no trigger events are reported within the
      domain.

   o  Unavailable state - The protection path is unavailable - either as
      a result of an operator Lockout command or a failure/degrade
      condition detected on the protection path.

   o  Protecting failure state - The working path has reported a
      failure/degrade condition and the user traffic is being
      transmitted on the protection path.

   o  Protecting administrative state - The operator has issued a
      command switching the user traffic to the protection path.

   o  Wait-to-restore state - The protection domain is recovering from a
      SF/SD condition on the working path that is being controlled by
      the Wait-to-Restore (WTR) timer.

   o  Do-not-revert state - The protection domain is recovering from a
      Protecting state, but the operator has configured the protection
      domain to not automatically revert to the Normal state upon
      recovery.  The protection domain SHALL remain in this state until
      the operator issues a command to revert to the Normal state or
      there is a new trigger to switch to a different state.

   See section 4.3.1 for details on what actions are taken by the PSC
   Process Logic for each state and the relevant input.

4.  Protection state coordination (PSC) protocol

   Bidirectional protection switching, as well as unidirectional 1:1
   protection, requires coordination between the two end-points in
   determining which of the two possible paths, the working or recovery
   path, is transmitting the data traffic in any given situation.  When
   protection switching is triggered as described in section 3.1, the
   end-points must inform each other of the switch-over from one path to
   the other in a coordinated fashion.

   There are different possibilities for the type of coordinating
   protocol.  One possibility is a two-phased coordination in which the
   LER that is initiating the protection switching sends a protocol
   message indicating the switch but the actual switch-over is performed
   only after receiving an 'Ack' from the far-end LER.  The other
   possibility is a single-phased coordination, in which the initiating
   LER performs the protection switchover to the alternate path and
   informs the far-end LER of the switch, and the far-end LER must
   complete the switchover.

   For the sake of simplicity of the protocol, this protocol is based on
   the single-phase approach described above.  In the following sub-
   sections we describe the protocol messages that SHALL be used between
   the two end-points of the protection domain.

4.1.  Transmission and acceptance of PSC control packets

   The PSC control packets SHALL be transmitted over the protection path
   only.  This allows the transmission of the messages without affecting
   the normal data traffic in the most prevalent case, i.e. the Normal
   state.  In addition, limiting the transmission to a single path
   avoids possible conflicts and race conditions that could develop if
   the PSC messages were sent on both paths.

   When the PSC information is changed due to a local input, three PSC
   messages SHOULD be transmitted as quickly as possible, to allow for
   rapid protection switching.  This set of three rapid messages allows
   for fast protection switching even if one or two of these packets are
   lost or corrupted.  When the PSC information changes due to a remote
   message there is no need for the rapid transmission of three messages
   with the following exception - When going from Wait-to-Restore state
   to Normal state as a result of a remote NR message.

   The frequency of the three rapid messages and the separate frequency
   of the continual transmission SHOULD be configurable by the operator.
   For protection switching within 50ms, the default interval of the
   first three PSC messages is RECOMMENDED to be no larger than 3.3ms.
   The continuous transmission interval is RECOMMENDED to be 5 seconds.

   If no valid PSC specific information is received, the last valid
   received information remains applicable.  In the event a signal fail
   condition is detected on the protection path, the received PSC
   specific information should be evaluated.

4.2.  Protocol format

   The protocol messages SHALL be sent over the G-ACh as described in
   [RFC5586].  There is a single channel type for the set of PSC
   messages [to be assigned by IANA].  The actual message function SHALL
   be identified by the Request field of the ACH payload as described
   below.  The following figure shows the format for the complete PSC
   message:.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0 0 0 1|Version|  Reserved     |   Channel Type = MPLS-TP PSC  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          ACH TLV Header                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                         Optional TLVs                         ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Ver|Request|PT |R|  Reserved   |     FPath     |     Path      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 2: Format of PSC packet with a G-ACh header

   Where:

   o  MPLS-TP PSC Channel Code is the G-ACh channel number assigned to
      the PSC = TBD

   o  The ACH TLV Header is described in [RFC5586]

   o  The following subsections will describe the fields of the PSC
      payload.

4.2.1.  PSC Ver field

   The Ver field identifies the version of the protocol.  For this
   version the value SHALL be 0.

4.2.2.  PSC Request field

   The PSC protocol SHALL support transmission of the following requests
   between the two end-points of the protection domain:

   o  (1110) Lockout of protection - indicates that the endpoint has
      disabled the protection path as a result of an administrative
      command.  Both the FPath and Path fields SHOULD be set to 0.

   o  (1101) Forced switch - indicates that the transmitting end-point
      has switched traffic to the protection path as a result of an
      administrative command.  The Fpath field SHOULD indicate that the
      working path is being blocked, and the Path field SHOULD indicate
      that user data traffic is being transmitted on the protection
      path.

   o  (0110) Signal Fail - indicates that the transmitting end-point has
      identified a signal fail condition on either the working or
      protection path.  The Fpath field SHALL identify the path that is
      reporting the failure condition, and the Path field SHALL indicate
      where the data traffic is being transmitted.

   o  (0100) Manual switch - indicates that the transmitting end-point
      has switched traffic as a result of an administrative Manual
      Switch command.  The Fpath field SHALL indicate the path that is
      the manual switch is being applied to and the Path field SHALL
      indicate the path being utilized by the endpoint to transmit user
      data traffic.

   o  (0011) Wait to restore - indicates that the transmitting endpoint
      is recovering from a failure condition of the working path and has
      started the Wait-to-Restore timer.  Fpath SHOULD be set to 0 and
      ignored upon receipt.  Path SHOULD indicate the working path that
      is currently being protected.

   o  (0010) Do not revert - indicates that the transmitting endpoint is
      recovering from a failure/blocked condition, but due to the local
      settings is requesting that the protection domain continues to
      transmit data over the protection path, rather than revert to the
      Normal state.  Fpath SHOULD be set to 0 and ignored upon receipt.
      Path SHOULD indicate the working path that is currently being
      protected.

   o  (0000) No request - indicates that the transmitting end-point has
      nothing to report, Fpath and Path fields SHOULD be set to
      according to the state of the end-point.

4.2.3.  Protection Type (PT)

   The PT field indicates the currently configured protection
   architecture type, this SHOULD be validated to be consistent for both
   ends of the protection domain.  If an inconsistency is detected then
   an alarm SHALL be sent to the management system.  The following are
   the possible values:

   o  11: bidirectional switching using a permanent bridge

   o  10: bidirectional switching using a selector bridge

   o  01: unidirectional switching using a permanent bridge

   o  00: unidirectional switching using a selector bridge

   As described in the introduction (section 1.1) a 1+1 protection
   architecture is characterized by the use of a permanent bridge at the
   source node, whereas the 1:1 and 1:n protection architectures are
   characterized by the use of a selector bridge at the source node.

4.2.4.  Revertive (R) field

   This field indicates that the transmitting endpoint is configured to
   work in revertive mode.  If there is an inconsistency between the two
   endpoints, i.e. one end-point is configured for revertive action and
   the second end-point is in non-revertive mode, then the management
   system SHOULD be notified.  Possible values are:

   o  0 - non-revertive mode

   o  1 - revertive mode

4.2.5.  Fault path (FPath) field

   The Fpath field indicates which path (i.e. working or protection) is
   identified to be in a fault condition or affected by an
   administrative command.  The following are the possible values:

   o  0: indicates that the anomaly condition is on the protection path

   o  1: indicates that the anomaly condition is on the working path
   o  2-255: for future extensions

4.2.6.  Data path (Path) field

   The Path field indicates which data is being transmitted on the
   protection path.  Under normal conditions, the protection path
   (especially in 1:1 or 1:n architecture) does not need to carry any
   user data traffic.  If there is a failure/degrade condition on one of
   the working paths, then that working path's data traffic will be
   transmitted over the protection path.  The following are the possible
   values:

   o  0: indicates that the protection path is not transporting user
      data traffic (in 1:n architecture) or transporting redundant user
      data traffic (in 1+1 architecture).

   o  1: indicates that the protection path is transmitting user traffic
      replacing the use of the working path.

   o  2-255: for future extensions

4.3.  Principles of Operation

   In all of the following sub-sections, assume a protection domain
   between LER-A and LER-Z, using paths W (working) and P (protection)
   as shown in figure 3.

                 +-----+ //=======================\\ +-----+
                 |LER-A|//     Working Path        \\|LER-Z|
                 |    /|                             |\    |
                 |  ?< |                             | >?  |
                 |    \|\\    Protection Path      //|/    |
                 +-----+ \\=======================// +-----+

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

                        Figure 3: Protection domain

4.3.1.  Basic operation

   The basic operation of the coordination protocol is to allow the end-
   points to notify their peer of the status that is known to that end-
   point.  The parameters that are notified between the end-points - the
   local condition of the protection domain, the blocked path (if there
   is a blockage within the protection domain), and the current usage of
   the protection path.  It should be noted that the messages exchanged
   between the two end-points may not be the same at a given point in
   time, although the states of the end-points are coordinated.  In
   particular it should be noted that a remote message MAY not cause the
   end-point to change the Request field that is being transmitted while
   it does affect the Path field (see details in the following
   subsections).

   The protocol is a single-phase protocol, although it includes a
   possibility to extend the protocol for multiple-phased operation.
   Single-phase implies that each end-point notifies its peer of a
   change in the operation (switching to or from the protection path)
   and makes the switch without waiting for acknowledgement.

   The following subsections will identify the messages that are
   transmitted by the end-point in different scenarios.  The messages
   are described as REQ(FP, P) - where REQ is the value of the Request
   field, FP is the value of the Fpath field, and P is the value of the
   Path field.  All examples assume a protection domain between LER-A
   and LER-Z with a single working path and single protection path (as
   shown in figure 3).

4.3.2.  Priority of inputs

   As noted above (in section 3.1.1) the PSC Control Process accepts
   input from five local input sources.  There is a definition of
   priority between the different inputs that may be triggered locally.
   The list of local requests in order of priority are (from highest to
   lowest priority):

   1.  Clear (Operator command)

   2.  Lockout of protection (Operator command)

   3.  Signal Fail on protection (OAM/Control Plane/Server Indication)

   4.  Forced switch (Operator command)

   5.  Signal Fail on working (OAM/Control Plane/Server Indication)

   6.  Clear Signal Fail (OAM/Control Plane/Server Indication)

   7.  Manual switch (Operator command)

   8.  WTR expires (WTR Timer)

   The determination of whether a remote message is accepted or ignored
   is a function of the current state of the local LER and the current
   local request (see section 3.1.3).  Part of this consideration will
   be included in the following subsections describing the operation in
   the different states.

4.3.3.  Operation of PSC States

4.3.3.1.  Normal State

   When the protection domain has no special condition in effect, the
   ingress LER SHOULD forward the user data along the working path, and,
   in the case of 1+1 protection, the Permanent Bridge will bridge the
   data to the recovery path as well.  The receiving LER SHOULD read the
   data from the working path.

   When the end-point is in Normal State it SHOULD transmit a NR(0,0)
   message - indicating - Nothing to report and data traffic is being
   transmitted on the working path.

   When the LER (assume LER-A) is in Normal State the following
   transitions are relevant in reaction to a local input (new state
   SHOULD be marked as local):

   o  A local Lockout of protection input SHALL cause the LER to go into
      Unavailable State and begin transmission of a LO(0,0) message to
      the far-end LER (LER-Z).

   o  A local Forced switch input SHALL cause the LER to go into
      Protecting administrative state and begin transmission of a
      FS(1,1) message to the far-end LER (LER-Z).

   o  A local Signal Fail indication on the protection path SHALL cause
      the LER to go into Unavailable state and begin transmission of a
      SF(0,0) message to the far-end LER (LER-Z).

   o  A local Signal Fail indication on the working path SHALL cause the
      LER to go into Protecting failure state and begin transmission of
      a SF(1,1) message to the far-end LER (LER-Z).

   o  A local Manual switch input SHALL cause the LER to go into
      Protecting administrative state and begin transmission of a
      MS(1,1) message to the far-end LER (LER-Z).

   o  All other local inputs SHOULD be ignored.

   In Normal state, remote messages would cause the following reaction
   from the LER (new state SHOULD be marked as remote):

   o  A remote Lockout of protection message SHALL cause the LER (LER-A)
      to go into Unavailable state, while continuing to transmit the
      NR(0,0) message.

   o  A remote Forced switch message SHALL cause the LER (LER-A) to go
      into Protecting administrative state, and transmit a NR(0,1)
      message.

   o  A remote Signal Fail message that indicates that the failure is on
      the protection path SHALL cause the LER (LER-A) to go into
      Unavailable state, while continuing to transmit the NR(0,0)
      message.

   o  A remote Signal Fail message that indicates that the failure is on
      the working path SHALL cause the LER (LER-A) to go into Protecting
      failure state, and transmit a NR(0,1) message.

   o  A remote Manual switch message SHALL cause the LER (LER-A) to go
      into Protecting administrative state, and transmit a NR(0,1)
      message.

   o  All other remote messages SHOULD be ignored.

4.3.3.2.  Unavailable State

   When the protection path is unavailable - either as a result of a
   Lockout operator command, or as a result of a SF or SD detected on
   the protection path - then the protection domain is in the
   unavailable state.  In this state, the data traffic is transmitted
   and received on the working path.

   The protection domain will exit the unavailable state and revert to
   the normal state when, either the operator clears the Lockout command
   or the protection path recovers from the signal fail or degraded
   situation.  Both ends will resume sending the PSC packets over the
   protection path, as a result of this recovery.

   When in unavailable state the data traffic is being transmitted on
   the working path and is not protected.  In many cases the remote
   messages will not be received (since the protection path is blocked)
   and the main effect will be as a result of local inputs.

   When the LER (assume LER-A) is in Unavailable State the following
   transitions are relevant in reaction to a local input (new state
   SHOULD be marked as local):

   o  Figure 3 shows  A local Clear input SHOULD be ignored if the LER is in remote
      Unavailable state.  If in local Unavailable state due to a Lockout
      command, then the input SHALL cause the LER to go to Normal state
      and begin transmitting a NR(0,0) message.

   o  A local Lockout of protection input SHALL cause the LER to remain
      in Unavailable State and begin transmission of a LO(0,0) message
      to the far-end LER (LER-Z).

   o  A local Clear SF indication SHOULD be ignored if the LER is in
      remote Unavailable state.  If in local Unavailable state due to a
      Signal Fail on the format of protection path and the PSC Control message Clear SF indicates that
      the protection path is now cleared, then the
      payload for input SHALL cause the PSC packet.

   Editor's note: There is
      LER to go to Normal state and begin transmitting a suggestion that NR(0,0)
      message.

   o  A local Forced switch input when in Unavailable state due to a
      local or remote failure condition on the protection path SHALL
      cause the LER to go into Protecting administrative state and begin
      transmission of a FS(1,1) message.  When in Unavailable state due
      to local Lockout input - this format should message SHOULD be
   aligned with the format used filtered out by G.8031/G.8131/Y.1731 in ITU.  The
   argument being that
      the Local Request Logic.  If Unavailable due to remote Lockout
      input, then this would make it easier message SHOULD be ignored by the PSC Process
      Logic.

   o  A local Signal Fail indication on the protection path SHALL cause
      the LER to pass review from ITU remain in Unavailable state and allow easier transfer begin transmission of technology.

   The counter-argument is that the ITU format is based upon an attempt
   to find a common format for different functionality and therefore
   involves different fields that
      SF(0,0) message.

   o  All other local inputs SHOULD be ignored.

   If remote messages are not necessary for being received over the protection
   switching.  Defining a new dedicated format path then
   they would make for a simpler
   and more intuitive protocol.  End of editor's note.

      0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Ver|Request| PT|   FPath       |     Path      |    Reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 3: Format of have the PSC control packet

   Where: following affect:

   o  Ver: is the version  A remote Lockout of protection message SHALL cause the protocol, for this version LER to
      remain in Unavailable state, and continue transmission of the value
      SHOULD be 0.
      current message (either NR(0,0) or LO(0,0))

   o  Request: this field  A remote Signal Fail message that indicates the specific PSC request that is
      being transmitted, the details are described in section 4.2.1

   o  PT: indicates failure is on
      the type of protection scheme currently supported,
      more details are given path SHALL cause the LER to remain in section 4.2.2 Unavailable
      state and continue transmission of the current message (either
      NR(0,0) or SF(0,0)).

   o  FPath: used to indicate  A remote No Report, when the path that LER is reporting a failure
      condition, remote Unavailable state SHALL
      cause the possible values are described in section 4.2.3

   o  Path: used LER to indicate the currently active path, possible values
      are described go into Normal state and begin transmission of a
      NR(0,0) message.  When in section 4.2.4 local Unavailable state, the message
      SHALL be ignored.

   o  Reserved: field is reserved for possible future use.  These bits
      MUST  All other remote messages SHOULD be set to zero ignored.

4.3.3.3.  Protecting administrative state

   In the protecting state the user data traffic is being transported on transmission, and ignored upon reception.

4.2.1.  PSC Requests

   The Protection State Coordination (PSC) protocol SHALL support
   the
   following request types, in order of priority from highest to lowest:

   o  (1111) Clear

   o  (1110) Lockout protection

   o  (1101) path, while the working path is blocked due to an
   operator command, i.e.  Forced switch

   o  (0110) Signal fault

   o  (0101) Signal degrade

   o  (0100) Switch or Manual switch

   o  (0011) Wait to restore
   o  (0010) Do not revert (DNR)

   o  (0000) No request

   See section 4.3 for a description of the operation of the different
   requests.

4.2.2.  Protection Type (PT) Switch.

   The PT field indicates following describe the currently configured protection
   architecture type, this should be validated reaction to local input:

   o  A local Clear SHOULD be consistent for both
   ends of the protected domain.  If an inconsistency is detected ignored if in remote Protecting state.  If
      in local Protecting administrative state then
   an alarm should be raised.  The following are this input SHALL
      cause the possible values:

   o  11: 1+1 bidirectional switching

   o  10: 1:1 bidirectional switching

   o  01: 1+1 unidirectional switching LER to go into Normal state and begin transmitting a
      NR(0,0) message.

   o  00: 1:1 unidirectional switching

4.2.3.  Path fault identifier (FPath)

   The Fpath field  A local Lockout of protection input SHALL cause the PSC control LER to go into
      Unavailable state and begin transmission of a LO(0,0) message.

   o  A local Forced switch input SHALL be used only cause the LER to remain in
      Protecting administrative state and begin transmission of a
      FS(1,1) message.

   o  A local Signal
   fault (0110) or Signal degrade (0101) control packet.  Its value
   indicates Fail indication on which path the signal anomaly was detected.  The
   following are protection path SHALL cause
      the possible values: LER to go into Unavailable state and begin transmission of a
      SF(0,0) message.

   o  0: indicates that the fault condition is  A local Signal Fail indication on the Recovery working path

   o  1: indicates that the fault condition is on SHOULD be
      filtered by the Working path

   o  2-255: for future extensions

4.2.4.  Active path indicator (Path)

   The Path field of Local Request Logic if the PSC control SHALL be used protecting state was
      entered due to indicate which
   path an active local Forced switch operator command.  If
      the source MEP protecting state is currently using for data transmission.  The
   MEP should compare the value of due to a remote Forced switch message,
      then this bit with local indication SHOULD be filtered by the path that PSC Process
      Logic.  If the current state is
   locally selected for data transmission due to verify that a (local or remote) Manual
      switch operator command, it shall cause the LER to go into
      Protecting failure state and begin transmitting a SF(1,1) message.

   o  A local Manual switch input SHALL be filtered by the Local Request
      Logic if there is no
   inconsistency between the two end-points of the protected domain.  If an inconsistency active local Forced switch.  If the
      protecting state is detected due to a remote Forced switch command, then an alarm should
      this local indication SHOULD be raised.  The
   following are the possible values:

   o  0: indicates that normal traffic is being transmitted on filtered by the
      Working path.

   o  1: indicates PSC Process Logic.
      If the Recovery path current state is being used due to transmit the
      normal traffic from the Working path.

   o  2-255: for future extensions

4.3.  Principles of Operation

   In all of the following sub-sections, assume a protected domain
   between LSR-A and LSR-Z, using paths W (working) and R (recovery) as
   shown in figure 4.

                 +-----+ //=======================\\ +-----+
                 |LSR-A|//     Working Path        \\|LSR-Z|
                 |    /|                             |\    |
                 |  ?< |                             | >?  |
                 |    \|\\     Recovery Path       //|/    |
                 +-----+ \\=======================// +-----+

                     |--------Protected Domain---------|

                        Figure 4: Protected domain

4.3.1.  PSC States

4.3.1.1.  Normal State

   When (local or remote) Manual switch
      operator command, it shall cause the protected domain has no special condition LER to remain in effect, the
   ingress LSR Protecting
      administrative state and begin transmission of a MS(1,1) message.

   o  All other local inputs SHOULD forward the user data along the working path, and, be ignored.

   While in Protecting administrative state the case of 1+1 protection, the Permanent Bridge will bridge the
   data to the recovery path LER may receive and
   react as well.  The receiving LSR SHOULD read the
   data from the working path.

   The ingress LSR MAY transmit a No Request follows to remote PSC packet with messages:

   o  A remote Lockout of protection message SHALL cause the Path
   field set LER to 0 indicating go
      into Unavailable state and begin transmitting a NR(0,0) message.

      It should be noted that this automatically cancels the normal current
      Forced switch or Manual switch command and data traffic should be read
   from is
      reverted to the working path.

4.3.1.2.  Protecting State

   When

   o  A remote Forced switch message SHOULD be ignored by the protection mechanism has been triggered and PSC
      Process Logic if there is an active local Forced switch operator
      command.  If the protected
   domain has performed Protecting state is due to a protection switch, remote Forced switch
      message then the domain is LER SHALL remain in the
   protecting state.  In this Protecting administrative
      state the normal data traffic is
   transmitted and received on continue transmission of the recovery path. last message.  If the protection domain
      Protecting state is currently in due to either a protecting state, local or remote Manual switch
      then the
   LSRs SHOULD NOT accept LER SHALL remain in Protecting administrative state
      (updating the state information with the proper relevant
      information) and begin transmitting a Manual Switch request.

   If NR(0,1) message.

   o  A remote Signal Fail message indicating a failure on the
      protection domain is currently in a protecting state, path SHALL cause the LER to go into Unavailable state
      and begin transmitting a
   Forced Switch is requested then NR(0,0) message.  It should be noted that
      this automatically cancels the normal current Forced switch or Manual
      switch command and data traffic SHALL continue is reverted to
   be transmitted the working path.

   o  A remote Signal Fail message indicating a failure on the recovery working
      path even SHALL be ignored if the original protection
   trigger there is cleared, and the an active local Forced Switch condition will be signalled
   by the PSC messages.

4.3.1.3.  Unavailable State

   When switch
      command.  If the recovery path Protecting state is unavailable - either as a result of due to a
   Lockout operator command (see section 4.3.3), local or as remote
      Manual switch then the LER SHALL go to Protecting failure state
      and begin transmitting a result of NR(0,1) message.

   o  A remote Manual switch message SHALL be ignored by the PSC Process
      Logic if in Protecting state due to a SF local or SD detected on the recovery path (see section 4.3.4) - remote Forced
      switch.  If in Protecting state due to a remote Manual switch then
      the
   protection domain is LER SHALL remain in Protecting administrative state and
      continue transmitting the unavailable state.  In this state, current message.  If in Protecting state
      due to an active local Manual switch then the
   normal traffic is transmitted LER SHALL remain in
      Protecting administrative state and received on continue transmission of the working path.

   While
      MS(1,1) message.

   o  A remote DNR(0,0) message SHALL be ignored if in unavailable Protecting state any event that would trigger
      due to a protection
   switching SHOULD be ignored with the following exception - local input.  If in Protecting state due to a
   Signal Degrade request is received, remote
      message then protection switching will be
   activated only if the recovery path can guarantee a better signal
   than the working path.

   The protection domain will exit the unavailable LER SHALL go to Do-not-revert state and revert to
   the normal begin
      transmitting a NR(0,0) message.

   o  A remote NR(0,0) message SHALL be ignored if in Protecting state when, either the operator clears the Lockout command
   or the recovery path recovers from the signal fault or degraded
   situation.  Both ends will resume sending the PCS packets over the
   recovery path, as
      due to a result of this recovery.

4.3.2.  Failure or Degraded condition (Working path) local input.  If one of the LSRs (for example, LSR-A) detects a failure condition
   or in Protecting state due to a serious degradation condition on the working path that warrants
   invoking protection switching, remote
      message then it SHOULD take the following
   actions:

   o  (For 1:1 protection) Switch all traffic for LSR-Z LER SHALL go to the recovery
      path only.

   o  Transmit Normal state and begin
      transmitting a PCS control packet, using GACH, with NR(0,0) message.

   o  All other remote messages SHALL be ignored.

4.3.3.4.  Protecting failure state

   When the appropriate
      Request code (either Signal fault or Signal degrade), protection mechanism has been triggered and the Fpath
      set to 1, to indicate that protection
   domain has performed a protection switch, the fault/degrade was detected on domain is in the
      working path, and
   protecting failure state.  In this state the Path set to 1, indicating that normal data traffic is now being
   transmitted and received on the recovery protection path.

   The following describe the reaction to local input:

   o  Verify that LSR-Z replies with a PCS control packet indicating  A local Clear SF SHOULD be ignored if in remote Protecting state.
      If the Clear SF indicates that it has switched to the recovery path. protection path is now cleared
      (but working is still in SF condition) then the indicateion SHOULD
      be ignored.  If this in local Protecting failure state and the LER is not
      received after 2 PSC cycles
      configured for revertive behavior then send an alarm this input SHALL cause the
      LER to go into Wait-to-restore state, start the management
      system.

   When WTR timer, and
      begin transmitting a WTR(0,1) message.  If in local Protecting
      failure state and the far-end LSR (in LER is configured for non-revertive behavior
      then this example LSR-Z) receives the PCS packet
   informing it that other LSR (LSR-A) has switched, it SHOULD perform input SHALL cause the following actions: LER to go into Do-not-revert state
      and begin transmitting a DNR(0,1) message.

   o  Check priority  A local Lockout of protection input SHALL cause the request

   o  Switch all traffic addressed LER to LSR-A to the recovery path only
      (for 1:1 protection).

   o  Begin go into
      Unavailable state and begin transmission of a PCS control packet, using GACH, with the
      appropriate Request code (either Signal fault or Signal degrade),
      the Fpath set to 1, to indicate that the fault/degrade was
      detected on the working path, and LO(0,0) message.

   o  A local Forced switch input SHALL cause the Path set LER to 1, indicating
      that traffic is now being transmitted on the recovery path.

4.3.3.  Lockout of Protection

   If one go into
      Protecting administrative state and begin transmission of the LSRs (for example, LSR-A) receives a management command
   indicating that
      FS(1,1) message.

   o  A local Signal Fail indication on the protection is disabled, then it SHOULD indicate
   this to path SHALL cause
      the far-end LSR (LSR-Z in this example) that it is not
   possible LER to use the recovery path.  The following actions MUST be
   taken: go into Unavailable state and begin transmission of a
      SF(0,0) message.

   o  Transmit  A local Signal Fail indication on the working path SHALL cause the
      LER to remain in Protecting failure state and begin transmitting a PCS control packet, using GACH, with
      SF(1,1) message.

   o  All other local inputs SHOULD be ignored.

   While in Protecting failure state the Request code
      set LER may receive and react as
   follows to remote PSC messages:

   o  A remote Lockout of protection (1110), message SHALL cause the Fpath may be set LER to 0, go
      into Unavailable state and the Path set if in protecting failure state due to 0.

   o  All normal traffic packets a
      local SF condition begin transmitting a SF(1,0) message, otherwise
      transmit a NR(0,0) message.  It should be transmitted on the working
      path only.

   o  Verify noted that the far-end LSR (for example LSR-Z) is forwarding the this may
      cause loss of user data packets on since the working path.  Raise alarm path is still in case of
      mismatch. a
      failure condition.

   o  The PSC control logic should  A remote Forced switch message SHALL cause the LER go into Unavailable state.

   When
      Protecting administrative state and if in protecting failure state
      due to a local SF condition begin transmitting the far-end LSR (in this example LSR-Z) receives SF(1,1)
      message, otherwise begin transmitting NR(0,0).

   o  A remote Signal Fail message indicating a failure on the PCS packet
   informing it that other LSR (LSR-A) has switched, it SHOULD perform
      protection path SHALL cause the following actions:

   o  Check priority of request

   o  Switch all normal traffic addressed LER to LSR-A go into Unavailable state
      and if in protecting failure state due to a local SF condition
      begin transmitting a SF(1,0) message, otherwise begin transmitting
      NR(0,0) message.  It should be noted that this may cause loss of
      user data since the working path
      only. is still in a failure condition.

   o  The PSC control logic should  If in Protecting state due to a remote message, a remote Wait-to-
      Restore message SHOULD cause the LER to go into Unavailable status.

   o  Begin Wait-to-Restore
      state and continue transmission of a PCS control packet, using GACH, with the
      appropriate Request code (Lockout of protection), current message.

   o  If in Protecting state due to a remote message, a remote Do-not-
      revert message SHOULD cause the Fpath set LER to
      0, go into Do-not-revert state
      and continue transmission of the Path set to 0, indicating that traffic current message.

   o  All other remote messages SHALL be ignored.

4.3.3.5.  Wait-to-restore state

   The Wait-to-Restore state is now being
      transmitted on used by the working path only.

4.3.4.  Failure or Degraded condition (Recovery path)

   If one of PSC protocol to delay
   reverting to the LSRs (for example, LSR-A) detects normal state, when recovering from a failure
   condition
   or a serious degradation condition on the recovery working path, then it
   SHOULD take for the following actions:

   o  Begin transmission period of a PCS control packet with the appropriate
      Request code (either Signal fault or Signal degrade), the Fpath
      set to 0, WTR timer to indicate that
   allow the fault/degrade was detected on recovering failure to stabilize.  While in the
      recovery path, and Wait-to-
   Restore state the Path set to 0, indicating that data traffic is
      now being forwarded SHALL continue to be transmitted on
   the working protection path.  Note that this  The natural transition from the Wait-to-Restore
   state to Normal state will
      actually reach occur when the far-end if this is a unidirectional fault or
      recovery path is possibly WTR timer expires.

   When in a degraded situation. Wait-to-Restore state the following describe the reaction to
   local inputs:

   o  The PSC control logic should  A local Lockout of protection command SHALL cause the LER to Stop
      the WTR timer, go into Unavailable state. state, and begin transmitting a
      LO(0,0) message.

   o  All traffic MUST be transmitted  A local Forced switch command SHALL cause the LER to Stop the WTR
      timer, go into Protecting administrative state, and begin
      transmission of a FS(1,1) message.

   o  A local Signal Fail indication on the working protection path for the
      duration of the SF/SD condition.

   When the far-end LSR (in this example LSR-Z) receives SHALL cause
      the PCS packet
   informing it that other LSR (LSR-A) has become Unavailable, it SHOULD
   perform LER to Stop the following actions: WTR timer, go into Unavailable state, and
      begin transmission of a SF(0,0) message.

   o  Transmit all traffic  A local Signal Fail indication on the working path for SHALL cause the duration of
      LER to Stop the
      SF/SD condition

   o  The PSC Control logic should WTR timer, go into Unavailable state.

4.3.5.  Operator Controlled Switching

   If the management system indicated to one Protecting failure state, and
      begin transmission of the LSRs (for example
   LSR-A) that a switch is necessary, e.g. either a Forced Switch or a SF(1,1) message.

   o  A local Manual Switch, then the LSR SHOULD switch input SHALL cause the traffic LER to Stop the recovery
   path WTR
      timer, go into Protecting administrative state and perform the following actions: begin
      transmission of a MS(1,1) message.

   o  Switch all data traffic to  A local WTR expires input SHALL cause the recovery path only.

   o  Transmit LER to remain in Wait-
      to-Restore state and begin transmitting a PCS control packet, using GACH, with NR(0,1) message.

   o  All other local inputs SHOULD be ignored.

   When in Wait-to-Restore state the appropriate
      Request code (either Manual switch or Forced switch), following describe the Fpath
      may be set to 1, reaction to indicate that there is an event that affects
      the working path, and
   remote messages:

   o  A remote Lockout of protection message SHALL cause the Path set LER to 1, indicating that traffic
      is now being forwarded on Stop
      the recovery path.

   o  Verify that LSR-Z replies with WTR timer, go into Unavailable state, and begin transmitting a PCS control packet indicating
      that it has switched to
      NR(0,0) message.

   o  A remote Forced switch message SHALL cause the recovery path.  If this is not
      received after 2 PSC cycles then send an alarm LER to Stop the management
      system.

   When WTR
      timer, go into Protecting administrative state, and begin
      transmission of a NR(0,1) message.

   o  A remote Signal Fail message for the far-end LSR (in this example LSR-Z) receives protection path SHALL cause
      the PCS packet
   informing it that other LSR (LSR-A) has switched, it SHOULD perform LER to Stop the following actions:

   o  Check priority WTR timer, go into Unavailable state, and
      begin transmission of the request a NR(0,0) message.

   o  Switch all normal traffic addressed to LSR-A to  A remote Signal Fail message for the recovery working path
      only.

   o  Begin SHALL cause the
      LER to Stop the WTR timer, go into Protecting failure state, and
      begin transmission of a PCS control packet, using GACH, with the
      appropriate Request code (either NR(0,1) message.

   o  A remote Manual switch of Forced switch), message SHALL cause the Fpath may be set to 1, LER to indicate that there is an event that
      affects Stop the working path, WTR
      timer, go into Protecting administrative state and begin
      transmission of a NR(0,1) message.

   o  If the Path set to 1, indicating that
      traffic WTR timer is now being forwarded on the recovery path.

4.3.5.1.  Clearing operator commands

   The operator may clear running then a remote NR message SHALL be
      ignored.  If the switching condition by issuing WTR timer is no longer running then a Clear
   request.  This command will remote NR
      message SHALL cause immediate recovery from the switch
   that was initiated by any of the previous operator commands, i.e.
   Forced Switch or Manual Switch.  In addition, LER to go into Normal state and begin
      transmitting a Clear command after NR(0,0) message.

   o  All other remote messages SHOULD be ignored.

4.3.3.6.  Do-not-revert state

   Do-not-revert state is a
   Lockout Protection command should clear continuation of the Unavailable protecting state and
   return when
   the protection domain is configured for non-revertive behavior.
   While in Do-not-revert state data traffic continues to be transmitted
   on the normal state.

   If protection path until the Clear request is issued in administrator sends a command to
   revert to the absence of Normal state.  It should be noted that there is a Manual Switch,
   fundemental difference between this state and Normal - whereas Forced Switch, or Lockout protection, then it SHALL be ignored.  In
   the presence of any of these commands, the Clear request SHALL clear
   Switch in Normal state actually causes a switch in the transport path
   used, in Do-not-revert state affected by the operator command.

4.3.6.  Recovery from switching

   When Forced switch just switches the condition that triggered
   state but the protection switching clears,
   e.g. traffic would continue to be transmitted on the cause
   protection path!  The command to revert back to Normal state could
   either be a Lockout of the failure condition has been corrected, protection (followed be a Clear command), a
   Clear command, or the
   operator clears a new form of the Manual Switch, then switch command [note: This
   would also require some kind of agreement, although it seems to have
   been adopted by ITU-T in G.8031 for Ethernet].  The following
   description of operation is based on the protection domain SHOULD
   follow Lockout/Clear option
   mentioned!

   When in Do-not-revert state the following procedures:

   o  If the network is configured for non-revertive behaviour, then describe the
      two LSRs SHOULD transmit DNR (Request code 0010) messages. reaction to
   local input:

   o  If the network is recovering from an operator switching  A local Lockout of protection command
      (in revertive mode), then both LSRs SHOULD return to using SHALL cause the
      working transport path LER to go
      into Unavailable state and transmit No request (Request code 0000)
      messages. begin transmitting a LO(0,0) message.

   o  If  A local Forced switch command SHALL cause the network is recovering from LER to go into
      Protecting administrative state and begin transmission of a failure or degraded condition
      (in revertive mode), then
      FS(1,1) message.

   o  A local Signal Fail indication on the LSR that detects this recovery protection path SHALL
      activate cause
      the LER to go into Unavailable state and begin transmission of a
      SF(0,0) message.

   o  A local Wait-to-restore (WTR) timer (see section 4.3.6.1)
      to verify that there is not an intermittent failure.  After Signal Fail indication on the
      WTR expires, working path SHALL cause the LSR SHOULD return
      LER to using go into Protecting failure state and begin transmission of
      a SF(1,1) message.

   o  A local Manual switch input SHALL cause the working transport
      path LER to go into
      Protecting administrative state and transmit No request (Request code 0000) messages.

4.3.6.1.  Wait-to-restore timer

   In revertive mode, begin transmission of a
      MS(1,1) message.

   o  All other local inputs SHOULD be ignored.

   When in order Do-not-revert state the following describe the reaction to prevent frequent activation
   remote messages:

   o  A remote Lockout of protection switching due to an intermittent defect, message SHALL cause the working
   transport path must become stable and fault-free before reverting LER to go
      into Unavailable state and begin transmitting a NR(0,0) message.

   o  A remote Forced switch message SHALL cause the normal condition.  In order LER to verify that this is the case a
   fixed period go into
      Protecting administrative state and begin transmission of time must elapse before the normal traffic uses the
   working transport path.  This period, called the Wait-to-restore
   (WTR) period, should be configurable by a
      NR(0,1) message.

   o  A remote Signal Fail message for the operator in 1-minute
   intervals within protection path SHALL cause
      the range 1-12 minutes.  The default value is 5
   minutes.

   During this period, if LER to go into Unavailable state and begin transmission of a failure condition is detected on
      NR(0,0) message.

   o  A remote Signal Fail message for the working
   transport path, then path SHALL cause the WTR timer is cleared
      LER to go into Protecting failure state, and the normal traffic begin transmission of
      a NR(0,1) message.

   o  A remote Manual switch message SHALL continue to be transported over the recovery transport path.
   If cause the WTR timer expires without being pre-empted by LER to go into
      Protecting administrative state and begin transmission of a failure, then
   the traffic
      NR(0,1) message.

   o  All other remote messages SHOULD be returned to use the working transport path (as
   above). ignored.

5.  IANA Considerations

   To be added in future version.

6.  Security Considerations

   To be added in future version.

7.  Acknowledgements

   The authors would like to thank all members of the teams (the Joint
   Working Team, the MPLS Interoperability Design Team in IETF and the
   T-MPLS Ad Hoc Group in ITU-T) involved in the definition and
   specification of MPLS Transport Profile.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5654]  Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
              and S. Ueno, "Requirements of an MPLS Transport Profile",
              RFC 5654, September 2009.

8.2.  Informative References

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, Jan 2001.

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, Jan 2001.

   [RFC5659]  Bocci, M. and S. Bryant, "An Architecture for Multi-
              Segment Pseudowire Emulation  Edge-to-Edge", RFC 5659,
              October 2009.

   [RFC3985]  Bryant, S. and P. Pate, "Pseudowire Emulation Edge-to-Edge
              (PWE3) Architecture", RFC 3985, March 2005.

   [RFC5085]  Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
              Connectivity Verification (VCCV): A Control Channel for
              Pseudowires", RFC 5085, December 2007.

   [TPFwk]    Bocci, M., Bryant, S., and L. Levrau, "A Framework for
              MPLS in Transport Networks",
              ID draft-ietf-mpls-tp-framework-06.txt, July 2009.

   [RFC5586]  Vigoureux,, M., Bocci, M., Swallow, G., Aggarwal, R., and
              D. Ward, "MPLS Generic Associated Channel", RFC 5586,
              May 2009.

   [RFC4427]  Mannie, E. and D. Papadimitriou, "Recovery Terminology for
              Generalized Multi-Protocol Label Switching", RFC 4427,
              Mar 2006.

   [SurvivFwk]
              Sprecher, N., Farrel, A., and H. Shah, "Multi-protocol
              Label Switching Transport Profile Survivability
              Framework", ID draft-ietf-mpls-tp-survive-fwk-02.txt,
              Feb 2009.

   [RFC4872]  Lang, J., Papadimitriou, D., and Y. Rekhter, "RSVP-TE
              Extensions in Support of End-to-End Generalized Multi-
              Protocol Label Switching (GMPLS) Recovery", RFC 4872,
              May 2007.

   [RFC3945]  Mannie, E., "Generalized Multi-Protocol Label Switching
              (GMPLS) Architecture", RFC 3945, Oct 2004.

Authors' Addresses

   Stewart Bryant (editor)
   Cisco
   United Kingdom

   Email: stbryant@cisco.com

   Eric Osborne
   Cisco
   United States

   Email: eosborne@cisco.com

   Nurit Sprecher (editor)
   Nokia Siemens Networks
   3 Hanagar St. Neve Ne'eman B
   Hod Hasharon,   45241
   Israel

   Email: nurit.sprecher@nsn.com

   Huub van Helvoort (editor)
   Huawei
   Kolkgriend 38, 1356 BC Almere
   Netherlands

   Phone: +31 36 5316076
   Email: hhelvoort@huawei.com

   Annamaria Fulignoli (editor)
   Ericsson
   Italy

   Phone:
   Email: annamaria.fulignoli@ericsson.com

   Yaacov Weingarten
   Nokia Siemens Networks
   3 Hanagar St. Neve Ne'eman B
   Hod Hasharon,   45241
   Israel

   Phone: +972-9-775 1827
   Email: yaacov.weingarten@nsn.com