MPLS Working Group                                          J. Ryoo, Ed.
Internet-Draft                                                      ETRI
Updates: 6378 (if approved)                                 E. Gray, Ed.
Intended status: Standards Track                                Ericsson
Expires: May 31, July 23, 2014                                   H. van Helvoort
                                                     Huawei Technologies
                                                         A. D'Alessandro
                                                          Telecom Italia
                                                               T. Cheung
                                                                    ETRI
                                                              E. Osborne
                                                     Cisco Systems, Inc.
                                                       November 27, 2013
                                                        January 19, 2014

    MPLS Transport Profile (MPLS-TP) Linear Protection in Support to Match the
  Operational Expectations of ITU-T's
                              Requirements
                   draft-ietf-mpls-tp-psc-itu-00.txt SDH, OTN and Ethernet Transport Network
                               Operators
                   draft-ietf-mpls-tp-psc-itu-01.txt

Abstract

   This document introduces describes alternate ways mechanisms to perform certain operations
   defined in RFC6378, "MPLS some of the
   sub-functions of MPLS Transport Profile (MPLS-TP) Linear
   Protection", linear protection
   defined in RFC 6378, and also defines additional behaviors.  This set mechanisms.  The
   purpose of
   modified these alternate and additional behaviors together with the protocol defined
   in RFC6378 meets mechanisms is to provide
   operator control and experience that more closely models the ITU-T's behavior
   of linear protection switching requirements. seen in other transport networks.

   This document also introduces capabilities and modes. modes for linear
   protection.  A capability is an individual behavior.  The capabilities of behavior, and a node are advertised using
   the method given in this document.  A mode is a
   particular combination of capabilities.  Two modes are defined in
   this document: Protection State Coordination (PSC) mode and Automatic
   Protection Switching (APS) mode.

   This document describes the behavior of the PSC protocol including
   priority logic and state machine when all the capabilities associated
   with the APS mode are enabled.

   This document updates RFC6378 RFC 6378 in that the capability advertisement
   method defined here is an addition to that document.

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   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."

   This Internet-Draft will expire on May 31, July 23, 2014.

Copyright Notice

   Copyright (c) 2013 2014 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   4   5
   3.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Capability 1: Priority Modification modification . . . . . . . . . . . . .   5   6
     4.1.  Motivations for swapping priorities of FS and SF-P  . . .   5   6
     4.2.  Motivation for raising the priority of Clear SF SFc  . . . . .   6 . .   7
     4.3.  Motivation for introducing Freeze command . . . . . . . .   6   7
     4.4.  Updates  Modifications to the PSC RFC 6378 . . . . . . . . . . . . . . . . .   6   7
   5.  Capability 2: Modification of Non-revertive Operation non-revertive operation . . . .   7   8
   6.  Capability 3: Support of Manual Switch to Working Command MS-W command . .   7 . . . . . . . . . .   8
     6.1.  Motivation for adding Manual Switch to Working MS-W  . . . . .   7 . . . . . . . . . .   8
     6.2.  Terms modified to support MS-W  . . . . . . . . . . . . .   8   9
     6.3.  Behavior of MS-P and MS-W . . . . . . . . . . . . . . . .   8   9
     6.4.  Equal priority resolution for MS  . . . . . . . . . . . .   8   9
   7.  Capability 4: Support of protection against Signal Degrade  .   9
     7.1.  Motivation for supporting protection against Signal
           Degrade . . . . . . . . . . . . . SD  . . . . . . .  10
     7.1.  Motivation for supporting protection against SD . . . . .   9  10
     7.2.  Terms modified to support SD  . . . . . . . . . . . . . .   9  10
     7.3.  Behavior of protection against SD . . . . . . . . . . . .   9  10
     7.4.  Equal priority resolution . . . . . . . . . . . . . . . .  11

   8.  Capability 5: Support of Exercise Command EXER command . . . . . . . . . . .  12 .  13
   9.  Capabilities and Modes modes  . . . . . . . . . . . . . . . . . . .  13  14
     9.1.  Capabilities  . . . . . . . . . . . . . . . . . . . . . .  13  14
       9.1.1.  Sending the Capabilities TLV  . . . . . . . . . . . .  14  15
       9.1.2.  Receiving the Capabilities TLV  . . . . . . . . . . .  14  15
       9.1.3.  Handling Capabilities TLV errors  . . . . . . . . . .  15
     9.2.  Modes . . . . . . . . . . . . . . . . . . . . . . . . . .  16
       9.2.1.  PSC Mode  . . . . . . . . . . . . . . . . . . . . . .  16
       9.2.2.  APS Mode  . . . . . . . . . . . . . . . . . . . . . .  16
     9.3.  Backward compatibility  . . . . . . . . . . . . . . . . .  16  17
   10. PSC Protocol in APS Mode  . . . . . . . . . . . . . . . . . .  17
     10.1.  Request field in PSC protocol message  . . . . . . . . .  17
     10.2.  Priorities of local inputs and remote requests . . . . .  17  18
     10.3.  Acceptance and retention of local inputs . . . . . . . .  20
   11. State Transition Tables in APS Mode . . . . . . . . . . . . .  19  21
     11.1.  State transition by local inputs . . . . . . . . . . . .  21  23
     11.2.  State transition by remote messages  . . . . . . . . . .  22
   12. Security considerations  25
     11.3.  State transition for 1+1 unidirectional
            protection . . . . . . . . . . . . . . . . . . .  24
   13. IANA considerations . . . .  27
   12. Provisioning mismatch and protocol failure
       in the APS mode . . . . . . . . . . . . . . . . .  24
     13.1.  PSC Request Field . . . . . .  28
   13. Security considerations . . . . . . . . . . . . .  24
     13.2. . . . . . .  28
   14. IANA considerations . . . . . . . . . . . . . . . . . . . . .  28
     14.1.  MPLS PSC Request Registry  . . . . . . . . . . . . . . .  29
     14.2.  MPLS PSC TLV Registry  . . . . . . . . . . . . . . . . .  29
     14.3.  MPLS PSC Capability Flag Registry  . . . . . . . . . . .  25
   14.  29
   15. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  25
   15.  30
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     15.1.  30
     16.1.  Normative References . . . . . . . . . . . . . . . . . .  25
     15.2.  30
     16.2.  Informative References . . . . . . . . . . . . . . . . .  25  30
   Appendix A.  An example of out-of-service scenarios . . . . . . .  26  31
   Appendix B.  An example of sequence diagram showing
                the problem with the priority level of Clear SF SFc . .  27 . . .  32
   Appendix C.  Freeze Command . . . . . . . . . . . . . . . . . . .  28  33
   Appendix D.  Operation examples of the APS mode . . . . . . . . .  34
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29  38

1.  Introduction

   Linear protection mechanisms for the MPLS Transport Profile (MPLS-TP)
   are described in RFC 6378 [RFC6378] to meet the requirements
   described in RFC 5654 [RFC5654].

   This document introduces describes alternate ways mechanisms to perform certain operations
   defined in [RFC6378], "MPLS Transport Profile (MPLS-TP) Linear
   Protection", some of the
   sub-functions of linear protection, and also defines additional behaviors.  This set
   mechanisms.  The purpose of
   modified these alternate and additional behaviors together with mechanisms
   is to provide operator control and experience that more closely
   models the protocol defined behavior of linear protection seen in [RFC6378] meets the ITU-T's other transport
   networks, such as Synchronous Digital Hierarchy (SDH), Optical
   Transport Network (OTN) and Ethernet transport networks.  Linear
   protection switching requirements.

   Alternative behaviors for SDH, OTN, and Ethernet transport networks are defined
   in ITU-T Recommendations G.841 [G841], G.873.1 [G873.1] and G.8031
   [G8031], respectively.

   The reader of this document is assumed to be familiar with RFC 6378.

   The alternative mechanisms described in this document are for the
   following capabilities:

   1.  Priority modification,

   2.  non-revertive behavior modification,

   and the following capabilities have been added to define additional
   behaviors:
   mechanisms:

   3.  support of Manual Switch to Working path (MS-W) command,

   4.  support of protection against Signal Degrade (SD), and

   5.  support of Exercise (EXER) command.

   Priority modification includes priority swapping between Signal Fail
   on the Protection path (SF-P) and Forced Switch (FS), and raising the
   priority level of Clear SF. Signal Fail (SFc).

   Non-revertive behavior is modified to align with the behavior defined
   in RFC 4427 [RFC4427] as well as to meet follow the ITU-T's behavior of linear
   protection switching
   requirements. seen in other transport networks.

   Support of Manual Switch to Working (MS-W) MS-W command to revert traffic to the working path in non-revertive non-
   revertive operation is covered in this document.

   Support of protection switching protocol against Signal Degrade (SD) SD is covered in
   this document.  The specifics for the method of identifying SD is out
   of the scope of this document similarly to SF Signal Fail (SF) for [RFC6378]. RFC
   6378.

   Support of Exercise EXER command to test if the Protection State Coordination
   (PSC) communication is operating correctly is also covered in this
   document.  More specifically, the Exercise EXER command tests and validates the
   linear protection mechanism and PSC protocol including the aliveness
   of the Local Request priority logic, the PSC state machine and the PSC message
   generation and reception, and the integrity of the protection path,
   without triggering the actual traffic switching.

   This document introduces capabilities and modes.  A capability is an
   individual behavior, behavior.  The capabilities of a node are advertised using
   the method given in this document.  A mode is a particular
   combination of capabilities.  Two modes are defined in this document:
   PSC mode and Automatic Protection Switching (APS) mode.

   This document describes the behavior of the PSC protocol including
   the priority logic and the state machine when all the capabilities
   associated with the APS mode are enabled.

   This document updates [RFC6378] RFC 6378 in that the capability advertisement
   method defined here is an addition to that document.  For an existing
   implementation of [RFC6378], RFC 6378, it is recommended to be updated with the
   bug-fixes in [I-D.ietf-mpls-psc-updates] and the capability
   adevertisement
   advertisement in this document.

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

3.  Acronyms
   This document uses the following acronyms:

   APS     Automatic Protection Switching
   DNR     Do-not-Revert
   EXER    Exercise
   FS      Forced Switch
   LER     Label Edge Router
   LO      Lockout of protection
   MS      Manual Switch
   MS-P    Manual Switch to Protection path
   MS-W    Manual Switch to Working path
   MPLS-TP MPLS Transport Profile
   NR      No Request
   OC      Operator Clear
   OTN     Optical Transport Network
   PSC     Protection State Coordination
   RR      Reverse Request
   SD      Signal Degrade
   SDH     Synchronous Digital Hierarchy
   SD-P    Signal Degrade on the Protection path
   SD-W    Signal Degrade on the Working path
   SF      Signal Fail
   SFc     Clear Signal Fail
   SFDc    Clear Signal Fail or Degrade
   SF-P    Signal Fail on the Protection path
   SF-W    Signal Fail on the Working path
   WTR     Wait to Restore

4.  Capability 1: Priority Modification modification

   In this document, the priorities of Forced Switch (FS) FS and Signal
   Fail on the Protection path (SF-P) SF-P are swapped and the
   priority of Clear SF (SFc) is raised.  In addition to the priority
   modification, this document introduces the use of a Freeze command in
   Appendix C.  The reasons for these changes are explained in the
   following sub-
   sections sub-sections from technical and network operational
   aspects.

4.1.  Motivations for swapping priorities of FS and SF-P

   Defining the priority of FS higher than that of Signal Fail on the
   Protection path (SF-P) SF-P can result in a
   situation where the protected traffic is taken out-of-service.
   Setting the priority of any input that is supposed to be signalled signaled to
   the other end to be higher than that of SF-P can result in
   unpredictable protection switching state, when the protection path
   has failed and consequently the PSC communication stopped.  An
   example of the out-of-service scenarios is shown in Appendix A A.

   According to Section 2.4 of RFC 5654 [RFC5654] it MUST be possible to
   operate an MPLS-TP network without using a control plane.  This means
   that external switch commands, e.g., FS, can be transferred to the far end
   remote Label Edge Router (LER) only by using the PSC communication
   channel and should not rely on the presence of a control plane.

   As the priority of SF-P has been higher than FS in optical other transport
   networks
   networks, such as SDH, OTN and Ethernet transport networks, for
   network operators it is important that the MPLS-TP protection
   switching preserves the network operation behavior to which network
   operators have become accustomed.  Typically, the FS command is issued
   before network maintenance jobs, (e.g., replacing optical cables or
   other network components).  When an operator pulls out a cable on the
   protection path by mistake, the traffic should be protected and the
   operator expects this behavior based on his/her experience on the
   traditional transport network operations.

4.2.  Motivation for raising the priority of Clear SF SFc

   The priority level of SFc defined in RFC 6378 [RFC6378] can cause
   traffic disruption when a node that has experienced local signal
   fails on both the working and the protection paths is recovering from
   these failures.

   An example of sequence diagram showing the problem with the priority
   level of SFc as defined in [RFC6378] RFC 6378 is shown in Appendix B.

4.3.  Motivation for introducing Freeze command

   With the priority swapping between FS and SF-P, the traffic is always
   moved back to the working path when SF-P occurs in Protecting
   Administrative
   administrative state.  In the case that network operators need an
   option to control their networks so that the traffic can remain on
   the protection path even when the PSC communication channel is
   broken, the Freeze command, which is a local command (i.e., not
   signalled
   signaled to the other end) can be used.  The use of the Freeze
   command is described in Appendix C.

4.4.  Updates  Modifications to the PSC RFC 6378

   The list of local requests in order of priority should SHALL be modified as
   follows:

      (from higher to lower)

   o  Clear Signal Fail/Degrade Fail

   o  Signal Fail on the Protection path
   o  Forced Switch

   o  Signal Fail on the Working path

   The change of the PSC control Control logic including the state machine due
   to this priority modification is incorporated in the PSC control Control
   logic description when all the capabilities are enabled in Section 10 and Section 11. 11 when all the
   capabilities are enabled.

5.  Capability 2: Modification of Non-revertive Operation non-revertive operation

   Non-revertive mode of protection switching is defined in RFC 4427
   [RFC4427].  In this mode, the traffic does not return to the working
   path when switch-over requests are terminated.

   However, PSC protocol defined in RFC 6378 [RFC6378] supports this
   operation only when recovering from a defect condition, but does not
   operate as non-revertive when an operator's switch-over command such
   as Forced
   Switch FS or Manual Switch (MS) is cleared.  To be aligned with legacy
   transport network behavior and [RFC4427], RFC 4427, a node should go into the
   Do-not-Revert (DNR) state not only when a failure condition on a the
   working path is cleared but also when an operator command requesting
   switch-over is cleared.

   The change of the PSC control Control logic including the state machine due
   to the modification of non-revertive operation is incorporated into
   the PSC control Control logic description when all the capabilities are enabled in Section 10 and Section 11. 11 when
   all the capabilities are enabled.

6.  Capability 3: Support of Manual Switch to Working Command MS-W command

6.1.  Motivation for adding Manual Switch to Working MS-W

   Changing the non-revertive operation introduces necessity of a new
   operator command to revert traffic to the working path when in Do-
   not-Revert (DNR) the
   DNR state.  When the traffic is on the protection path in the DNR
   state, a Manual Switch to Working (MS-W) command is issued to switch
   the normal traffic back to the working path.  According to
   Section 4.3.3.6 (Do-not-Revert State) in RFC 6378 [RFC6378], "to
   revert back to Normal state, the administrator SHALL issue a Lockout
   of protection (LO) command followed by a Clear command."  However,
   using LO command introduces the potential risk of an unprotected
   situation while the Lockout of protection LO is in effect.

   Manual Switch-over for recovery LSP/span command, defined in RFC 4427
   [RFC4427] and also defined in RFC 5654 [RFC5654], Requirement 83, as
   one of the mandatory external commands, should be used for this
   purpose, but is not included in [RFC6378]. RFC 6378.  Note that the "Manual
   Switch-over for recovery LSP/span" command is the same as MS-W
   command.

6.2.  Terms modified to support MS-W

   The term "Manual Switch" and its acronym "MS" used in [RFC6378] RFC 6378 are
   replaced respectively by "Manual Switch to Protection" Protection path" and
   "MS-P" by this document to avoid confusion with "Manual Switch to Working"
   Working path" and its acronym "MS-W".

   Also, the term "Protecting administrative state" used in [RFC6378] RFC 6378 is
   replaced by "Switching administrative state" by this document to
   include the case where traffic is switched back to the working path
   by administrative Manual Switch to Working MS-W command.

6.3.  Behavior of MS-P and MS-W

   The MS-P and MS-W commands SHALL have the same priority.  If one of
   these commands is already issued and accepted, and then the other command
   that is issued afterwards SHALL be ignored.  If two LERs are
   requesting opposite operations simultaneously, i.e. one LER is
   sending MS-P while the other LER is sending MS-W, the MS-W SHALL be
   considered to have a higher priority than MS-P, and MS-P SHALL be
   ignored.
   ignored and cancelled.

   Two commands, MS-P and MS-W are represented by the same Request Field
   value, but differentiated by the FPath value.  When traffic is
   switched to the protection path, the FPath field SHALL indicate that
   the working path is being blocked (i.e., FPath set to 1), and the
   Path field SHALL indicate that user data traffic is being transported
   on the protection path (i.e., Path set to 1).  When traffic is
   switched to the working path, the FPath field SHALL indicate that the
   protection path is being blocked (i.e., FPath set to 0), and the Path
   field SHALL indicate that user data traffic is being transported on
   the working path (i.e., Path set to 0).

6.4.  Equal priority resolution for MS

   [RFC6378]

   RFC 6378 defines only one rule for equal priority condition in
   Section 4.3.2 as "The remote message from the far-end remote LER is assigned
   a priority just below the similar local input."  In order to support
   the manual switch behavior described in Section 6.3, additional rules
   for equal priority resolution are required.  Since the support of
   protection against signal degrades degrade also requires a similar equal
   priority resolution, the rules are described in Section 7.4.

   The change of the PSC control Control logic including the state machine due
   to the support of MS-W command is incorporated into the PSC control Control
   logic description in Section 10 and Section 11 when all the
   capabilities are enabled in Section 10
   and Section 11.

7.  Capability 4: Support of protection against Signal Degrade SD

7.1.  Motivation for supporting protection against Signal Degrade SD

   In MPLS-TP survivability framework [RFC6372], fault conditions
   include both Signal Fail (SF) SF and Signal Degrade (SD) SD that can be used to trigger protection
   switching.

   RFC 6378 [RFC6378], which defines the Protection State Coordination (PSC)
   protocol, protection switching protocol
   for MPLS-TP does not specify how the SF and SD are declared detected, and
   specifies the protection switching protocol associated with SF only.

   The protection switching PSC protocol associated with SD is covered in this document, and
   the specifics for the method of identifying SD is out of the scope of PSC
   the protection protocol similarly similar to the facts that how to detect SF is detect
   and how MS and FS commands are initiated in a management system and
   signalled
   signaled to PSC. protection switching are out of its scope.

7.2.  Terms modified to support SD

   Instead of SFc, Clear Signal Fail (SFc) includes or Degrade (SFDc) is used to
   indicate the clearance of either a degraded condition in addition to the clearance of or a failure condition
   condition.

   The second paragraph of Section 4.3.3.2 Unavailable State state in
   [RFC6378] RFC 6378
   shows the intention of including Signal Degrade on the Protection path
   (SD-P) in the Unavailable state.  Even though the protection path can
   be partially available under the condition of the
   Signal Degrade on the Protection path, SD-P, this document
   follows the same state grouping as [RFC6378] RFC 6378 for SD on the protection path. SD-P.

   The bullet item "Protecting failure state" in Section 3.6.  PSC
   Control States 3.6 in [RFC6378] RFC 6378
   includes the degraded condition in
   Protection Failure Protecting failure state.  This
   document follows the same state grouping as [RFC6378] RFC 6378 for Signal
   Degrade on the Working path (SD-W).

7.3.  Behavior of protection against SD

   In order to maintain the network operation behavior to which
   transport network operators have become accustomed, the priorities of
   SD-P and SD-W are defined to be equal as in other transport networks,
   such as SDH, OTN and Ethernet. Ethernet transport networks.  Once a switch has
   been completed due to
   Signal Degrade SD on one path, it will not be overridden by Signal
   Degrade SD
   on the other path (first come, first served behavior), to avoid
   protection switching that cannot improve signal quality and
   flapping.

   Signal Degrade (SD) quality.

   SD indicates that the transmitting end point has identified a
   degradation of the signal, or integrity of the packet transmission on
   either the working path or the protection path.  The FPath field
   SHALL identify the path that is reporting the degrade condition
   (i.e., if the protection path, then FPath is set to 0; if the working
   path, then FPath is set to 1), and the Path field SHALL indicate
   where the data traffic is being transported (i.e., if the working
   path is selected, then Path is set to 0; if the protection path is
   selected, then Path is set to 1).

   The Wait to Restore (WTR) timer is used when the protected domain is
   configured for revertive behavior and started at the node that
   recovers from a local degraded condition on the working path.

   If the detection of a

   Protection switching against SD depends on the presence of user data
   packets, such a condition declared on the working path is cleared
   following protection switching to the protection path if always provided by a selector
   bridge is used, possibly resulting in flapping.  To avoid flapping,
   the selector bridge should duplicate the duplicating user data traffic and feed feeding it to both working and protection paths under SD condition.  In
   revertive mode, when WTR timer expires the packet duplication will be
   stopped and the user data traffic will be transported on the
   working path only.  In non-revertive mode, when SD is cleared the packet
   duplication will be stopped and the user data traffic will be
   transported on the protection path only. under SD condition.  When multiple SDs are detected simultaneously, either as a
   local or remote requests on both working and protection paths, the SD on the
   standby path (the path from which the selector does not select the
   user data traffic) is considered as having higher priority than the SD occurs on either the active path (the working path from which the selector selects or the
   user data traffic).  Therefore, no unnecessary
   protection switching
   is performed and path, the LER SHALL duplicate user data traffic continues to be selected from
   the active path.

   In the preceding paragraph, "simultaneously" relates and SHALL
   feed to the
   occurrence of SD on both the active working path and standby paths at input to the
   Protection State Control Logic in Figure 1 of [RFC6378] at the same
   time, or protection path.  The packet
   duplication SHALL continue as long as a any SD request has not been acknowledged by the
   remote end condition exists in bidirectional protection switching.  In other words, the
   protected domain, and SHALL stop when a local node that has transmitted a SD message receives a there is no SD
   message that indicates a different value of data path (Path) field
   than condition.
   Additionally, the value of packet duplication SHALL continue in the Path field WTR state
   in revertive mode.  In non-revertive mode, the transmitted packet duplication
   SHALL stop when there is no SD message, both
   the local and condition.

   The selector bridge with the remote packet duplication under SD requests are condition,
   which is a non-permanent bridge, is considered to occur
   simultaneously. be a 1:1 protection
   architecture.

7.4.  Equal priority resolution

   In order to support the manual switch behavior described in
   Section 6.3 and the protection against Signal Degrade described in
   Section 7.3, the rules to resolve the equal priority requests are
   required.

   For the equal priority local inputs with same priority, inputs, such as MS and SD, first-come,
   first-served rule is applied.  Once a local input is determined as
   the highest priority local input, then a subsequent equal priority
   local input requesting a different action, i.e., the action results
   in the same PSC Request Field but different FPath value, to the PSC control logic will not be
   presented to the PSC control Control logic as the highest local request.
   Furthermore, in the case of MS, MS command, the subsequent MS local input MS
   command requesting a different action will be cancelled.

   The remote message from the far-end LER is assigned a priority just
   below the similar local input.  For example, a remote Forced Switch
   would have a priority just below a local Forced Switch but above a
   local Signal Fail on working input assuming that the priority
   modification is in place as in Section 4.4

   However, if

   If the LER is in a remote state due to a remote SD (or MS) message, a
   subsequent local input having the same priority but requesting
   different action to the control PSC Control logic, will be considered as
   having lower priority than the remote message, and will be ignored.  For
   example, if
   If the LER is in remote Unavailable Switching administrative state due to a
   remote
   SD-P, MS-P, then subsequent local SD-W input will MS-W SHALL be ignored.  Likewise, if ignored and
   automatically cancelled.  If the LER is in remote Switching administrative Unavailable state
   due to a remote
   MS-P, SD-P, then subsequent local MS-W SD-W input will be ignored and automatically
   cancelled.

   It should
   ignored.  However, the local SD-W SHALL appear in the Local Request
   logic as long as the SD condition exists, but SHALL NOT be noted that there the top
   priority global request, which determines the state transition at the
   PSC Control logic.

   There is a reverse case where one LER receives a local input and the other
   LER receives, simultaneously, an a local input with the same priority
   but requesting different action.  In this case, each of the two LERs
   receives a subsequent remote message having the same priority but
   requesting different action, while the LER is in a local state due to
   the local input.  In  When this case, case happens, a priority must be set for
   the inputs with the same priority regardless of its origin (local
   input or remote message).  For example, one LER
   receives SD-P as a local input and the other LER receives SP-W as a
   local input, simultaneously.  Likewise, one LER receives MS-P as a
   local input and the other LER receives MS-W as a local input,
   simultaneously.

   When MS-W

   When MS-W and MS-P occur simultaneously at both LERs, MS-W SHALL be
   considered as having higher priority than MS-P at both LERs.

   When SD-W and SD-P occur simultaneously at both LERs, In this case, the SD on the
   standby path (the path from which the selector does not select the
   user data traffic) is considered as having higher priority than the
   SD on the active path (the path from which the selector selects the
   user data traffic) regardless of its origin (local or remote
   message).  Therefore, no unnecessary protection switching is
   performed and the user data traffic continues to be selected from the
   active path.  Giving

   In the higher priority preceding paragraphs, the "simultaneously" refers to the case
   a sent SD on (or MS) request has not been confirmed by the standby remote end in
   bidirectional protection switching.  When a local node that has
   transmitted a SD message receives a SD (or MS) message that indicates
   a different value of data path SHALL also be applied to (Path) field than the Local Request logic when two SDs
   for different paths happen to be presented to value of the Local Request logic
   exactly at
   Path field in the same time. transmitted SD (or MS) message, both the local and
   the remote SD requests are considered to occur simultaneously.

   The change of the PSC control Control logic including the state machine due
   to the support of protection against SD is incorporated into the PSC
   control
   Control logic description when all the capabilities are enabled in Section 10 and Section 11. 11 when all the
   capabilities are enabled.

8.  Capability 5: Support of Exercise Command

   Exercise EXER command

   EXER is a command to test if the PSC communication is operating
   correctly.  More specifically, the Exercise EXER is to test and validate the
   linear protection mechanism and PSC protocol including the aliveness
   of the Local Request logic, the PSC state machine and the PSC message
   generation and reception, and the integrity of the protection path,
   without triggering the actual traffic switching.  It is used while
   the working path is either carrying the traffic or not.  It is has lower
   priority than any "real" switch request.  It is only valid in
   bidirectional switching, since this is the only place where one can
   get a meaningful test by looking for a response.

   This command is documented in R84 of [RFC5654] and it has been
   identified as a requirement from ITU-T. RFC 5654 [RFC5654].

   A received EXER message indicates that the remote end point is
   operating under an operator command to validate the protection
   mechanism and PSC protocol including the aliveness of the Local
   Request logic, the PSC state machine and the PSC message generation
   and reception, and the integrity of the protection path, without
   triggering the actual traffic switching.  The valid response to EXER
   message will be is an Reverse Request (RR) with the corresponding FPath and
   Path numbers.  The near end will local LER SHALL signal a Reverse Request (RR) RR only in response to an
   EXER command from the far end. remote LER.

   When Exercise commands are input at both ends, an EXER, instead of
   RR, is SHALL be transmitted from both ends.

   The following PSC Requests should SHALL be added to PSC Request field to
   support Exercise:

      (TBD2)

      (3) Exercise - indicates that the transmitting end point is
      exercising the protection channel and mechanism.  FPath and Path
      are set to the same value of the NR, No Request (NR), RR or DNR
      request that EXER replaces.

      (TBD1)

      (2) Reverse Request - indicates that the transmitting end point is
      responding to an EXER command from the far end. remote LER.  FPath and Path
      are set to the same value of the NR, RR NR or DNR request that EXER RR
      replaces.

   The priority of Exercise should SHALL be inserted between the priorities of
   WTR Expires and No Request.

9.  Capabilities and Modes modes

9.1.  Capabilities

   A Capability is an individual behavior whose use is signalled signaled in a
   Capabilities TLV, which is placed in Optional TLVs field inside the
   PSC
   messages message shown in Figure 2 of RFC 6378 [RFC6378].  The format of
   the Capabilities TLV is:

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = Capabilities          |    Length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Value = Options Flags                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 1: Format of Capabilities TLV

   The value of the Type field is TBD3 TBD pending IANA allocation.

   The value of the Length field is the length of the Options Value, and
   is Flags field in
   octets.  The Value length of the Capabilities TLV can Flags field MUST be any length, as long as it is a multiple of 4 octets.  The length of the Value field octets
   and MUST be the minimum required to signal all the required
   capabilities.

   Section 4 to Section 8 discuss five capabilities that are signalled signaled
   using the 5 five most significant bits; if a node wishes to signal
   these five capabilities, it MUST send an Options Value a Flags field of 4 octets.  A
   node would send an Options Value a Flags field greater than 4 octets only if it had
   more than 32 Capabilities to indicate.  All unused bits MUST be set
   to zero.

   If the bit assigned for an individual capability is set to 1, it
   indicates the sending node's intent to use that capability in the
   protected domain.  If a bit is set to 0, the sending node does not
   intend to use the indicated capability in the protected domain.  Note
   that it is not possible to distinguish between the intent not to use
   a capability and a node's complete non-support (i.e. (i.e., lack of
   implementation) of a given capability.

   This document defines five specific capabilities that are described
   from Section 4 to Section 8.  Each capability is assigned bit as
   follows:

      0x80000000: priority modification

      0x40000000: modification of non-revertive behavior modification
      0x20000000: support of Manual Switch to Working (MS-W) MS-W command

      0x10000000: support of protection against Signal Degrade (SD) SD

      0x08000000: support of Exercise EXER command

9.1.1.

   If all the five capabilities should be used, an LER SHALL set
   0xF8000000 in the Flags field.

9.1.1.  Sending the Capabilities TLV

   PSC sends messages in response to external events and in periodic
   retransmission of current status.  It may be expensive to send and to
   parse an Capabilities TLV attached to a packet intended to trigger a
   protection switch or other real- time real-time behavior.  However, if a node
   does not periodically send its Capabilities TLV, the receiving node
   cannot discriminate a deliberate omission of the Capabilities TLV for
   performance reasons from an accidental omission due to an
   implementation issue.  To guard against this, a node MUST include its
   Capabilities TLV in every PSC message that it sends.

9.1.2.  Receiving the Capabilities TLV

   A node MUST establish a receive timer for the Capabilities TLV.  By
   default this MUST be 3.5 times the periodic retransmission timer of
   five seconds - i.e., 17.5 seconds.  Both the periodic retransmission
   time and the timeout SHOULD be configurable by the operator.  When a
   node receives a Capabilities TLV it resets the timer to 17.5 seconds.
   If the timer expires, the node behaves as in Section 9.1.3.

   [Editor's note: In other packet transport protection technologies,
   Failure of Protocol defect (dFOP) is declared when no protocol
   message is received on the protection path during at least 3.5 times
   the periodic message transmission interval (i.e., at least 17.5
   seconds) and there is no defect on the protection transport entity.
   As the "Capabilities TLV" is included in the PSC message, this error
   of not receiving the Capabilities TLV can be covered by dFOP.  To be
   discussed.]

   When a node receives a Capabilities TLV it MUST compare it to its
   most recent transmitted Capabilities TLV.  If the two are equal, the
   protected domain is said to be running in the mode indicated by that
   set of capabilities (see Section 9.2).  If the sent and received
   Capabilities TLVs are not equal, this indicates a capabilities
   mismatch.  When this happens, the node MUST alert the operator and
   MUST behave as in Section 9.1.3.

9.1.3.  Handling Capabilities TLV errors

   This section covers the two possible errors - a TLV timeout and a TLV
   mismatch - and the error handling procedures in both cases.

9.1.3.1.  Capabilities TLV Timeout

   If the Capabilities TLV receive timer expires, a node expires and there is said to have
   timed out.  When this happens, no defect
   on the protection path, the node MUST alert the operator and MUST
   behave as in Section 9.1.3.3.

9.1.3.2.  Capabilities TLV Mismatch

   If the sent and received Capabilities TLVs are not equal, this
   indicates a capabilities mismatch.  When this happens, the node MUST
   alert the operator and MUST behave as in Section 9.1.3.3.  A node MAY
   retain the received TLV for logging, alert or debug purposes.

9.1.3.3.  Handling Capabilities TLV error conditions

   When a node enters in Capabilities protocol error conditions, the
   following actions MUST be taken:

   1.  Indicate the error condition (e.g., either mismatch or timeout)
       to the operator by the usual alert mechanisms (e.g., syslog).

   2.  Not make any state transitions based on the contents of any PSC
       Messages
       messages

   To expand on point 2 - assume node A is receiving NR(0,0) from its
   PSC peer node Z and is also receiving a mismatched set of
   capabilities (e.g., received 0x4, 0x20000000, transmitted 0x5). 0xA0000000).  If
   node Z detects a local SF-W and wants to initiate a protection switch
   (that is, by sending SF(1,1)), node A MUST NOT react to this input by
   changing its state.  A node MAY increase the severity or urgency of
   its alarms to the operator, but until the operator resolves the
   mismatch in the Capabilities TLV the protected domain will likely
   operate in an inconsistent state.

9.2.  Modes

   A Mode is a given set of Capabilities.  Modes are shorthand;
   referring to a set of capabilities by their individual values or by
   the name of their mode does not change the protocol behavior.  This
   document defines two modes - PSC and APS.

9.2.1.  PSC Mode

   PSC Mode is defined as the lack of any Capabilities - that is, a
   Capabilities set of 0x0.  It is the behavior specified in RFC6378. RFC 6378.
   There are two ways to declare PSC Mode.  A node can send a
   Capabilities TLV of 0x0, or it can send no Capabilities TLV at all.
   This is further explored in Section 9.3.

9.2.2.  APS Mode

   APS Mode is defined as the use of all of the five specific capabilities,
   which are described from Section 4 to Section 8 in this document.
   APS Mode is indicated with a Value the Flags value of 0xF8000000.

9.3.  Backward compatibility

   As defined in Section 9.2.1, PSC Mode is indicated either with a
   Capabilities TLV of 0x0 or the lack of Capabilities TLV.  This is to
   allow backward compatibility between two nodes - one which can send
   the Capabilities TLV, and one which cannot.

   [RFC6378]

   RFC 6378 does not define how to handle an unrecognized TLV.  There
   may be some implementations that silently discard an unrecognized
   TLV, and some that take more drastic steps like refusing to allow PSC
   to operate.  Thus, a node which has the ability to send and receive
   the PSC Mode Capabilities TLV MUST be able to both send the PSC Mode
   Capabilities TLV and send no Capabilities TLV at all.  An
   implementation MUST be configurable between these two choices.

   One question that arises from this dual definition of PSC Mode is,
   what happens if a node which was sending a non-null Capabilities TLV
   (e.g., APS Mode) sends PSC packets without any Capabilities TLV?
   This case is handled as follows:

   If a node has never, during the life of a PSC session, received a
   Capabilities TLV from a neighbour, its peer, the lack of a Capabilities TLV is
   treated as receipt of a PSC Capabilities TLV.  This allows for
   interop
   interoperability between nodes which support the PSC Mode TLV and
   nodes which do not, and are thus implicitly operating in PSC Mode.

   If a node has received a non-null Capabilities TLV (e.g., APS Mode)
   during the life of a PSC session and then receives a PSC packet with
   no Capabilities TLV, the receiving node MUST treat the lack of
   Capabilities TLV as simply a lack of refresh.  That is, the receipt
   of a PSC packet with no Capabilities TLV simply does not reset the
   receive timer defined in Section 9.1.2.

10.  PSC Protocol in APS Mode

   This section and Section 11 defines define the behavior of PSC protocol when
   all of the aforementioned capabilities are enabled, i.e., APS mode.

10.1.  Request field in PSC protocol message

   The values of "Request" field in the PSC protocol message, which is shown
   in Figure 2 of RFC 6378 [RFC6378], are defined redefined as follows:

      (14) Lockout of protection

      (12) Forced Switch

      (10) Signal Fail
      (7) Signal Degrade

      (5) Manual Switch

      (4) Wait-to-Restore

      (TBD2)

      (3) Exercise

      (TBD1)

      (2) Reverse Request

      (1) Do-not-Revert

      (0) No Request

10.2.  Priorities of local inputs and remote requests

   Based on the description in Section 3 and Section 4.3.2 in [RFC6378], RFC 6378,
   the priorities of multiple outstanding local inputs are evaluated in
   the Local Request logic unit, logic, where the highest priority local request input
   (highest local request) is determined.  This high-priority highest local request is
   passed to the PSC Control logic, that will determine the higher
   priority input (top priority global request) between the highest priority
   local input request and the last received remote message.  When a remote
   message comes to the PSC Control logic, the top priority global
   request is determined between this remote message and the highest priority
   local input request which is present.  The top priority global request is
   used to determine the state transition, which is described in
   Section 11.

   The priorities for both local and remote requests are defined as
   follows from highest to lowest:

   o  Operator Clear (Local only)

   o  Lockout of protection (Local and Remote)

   o  Clear Signal Fail/Degrade Fail or Degrade (Local only)

   o  Signal Fail on Protection path (Local and Remote)

   o  Forced Switch (Local and Remote)

   o  Signal Fail on Working path (Local and Remote)

   o  Signal Degrade on either Protection path or Working path (Local
      and Remote)

   o  Manual Switch to either Protection path or Working path (Local and
      Remote)

   o  WTR Expires (Local only)

   o  WTR (Remote only)

   o  Exercise (Local and Remote)

   o  Reverse Request (Remote only)

   o  Do-Not-Revert (Remote only)

   o  No Request (Remote and Local)

   Note that the "Local only" requests are not signaled to the remote
   LER.  Likewise, the "Remote only" requests do not exist in the Local
   Request logic as local inputs.  For example, the priority of WTR only
   applies to the received WTR message, which is generated from the
   remote LER.  The remote LER that is running the WTR timer in the WTR
   state has no local request.

   The remote request from the far-end remote LER is assigned a priority just
   below the same local request.  However, for the equal priority
   requests, such as Signal Degrade on either Working or protection SD and
   Manual Switch to either Protection or Working path, MS, the following equal priority resolution
   rules are defined:

   o  If two local inputs having the same priority but requesting
      different action come to the Local Request logic, then the input
      coming first SHALL be considered to have a higher priority than
      the other coming later (first-come, first-served).

   o  If the LER receives PSC Control logic has both a the highest local input request and a
      remote message with the same priority and requesting the same
      action, i.e., the same PSC Request Field and the same FPath value,
      then the local input SHALL be considered to have a higher priority
      than the remote message.

   o  If the LER receives PSC Control logic has both a the highest local input request and a
      remote message with the same priority but requesting different actions, i.e.,
      action and the same
      PSC Request Field but different FPath value, then remote message exists when the first-come,
      first-served rule highest local
      request comes to the PSC Control logic, the highest local request
      is ignored and the remote Request SHALL be applied. the top priority global
      request.

   o  If the remote message comes
      first, then PSC Control logic has both the state SHALL be highest local request and a
      remote state message with the same priority but requesting different
      action and subsequent local
      input is ignored.  However, if the highest local input comes first, the
      first-come, first-served rule cannot be applied and must be viewed
      as simultaneous condition.  This is because request exists when the subsequent remote
      message will not be an acknowledge of the local input by comes to the far-
      end node.  In this case, PSC Control logic, the top priority global
      request SHALL be determined by the following rules for each
      simultaneous condition. condition:

   o  If the LER receives both MS-P and MS-W requests as both local
      input and remote message and the LER is in a local Switching
      administrative state, then  For simultaneous MS requests, the MS-W request SHALL be considered
      to have a higher priority than the MS-P request.

   o  If the  The LER receives both SD-P and SD-W requests as both that has
      local
      input and remote message and MS-W request SHALL maintain the local MS-W request as the
      top priority global request, but the other LER is in a that has local state, then MS-P
      request SHALL clear the MS-P command and internally generate
      "Operator Clear" request.

   o  For simultaneous SD requests, the SD on the standby path (the path
      from which the selector does not select the user data traffic)
      SHALL be considered as having higher priority than the SD on the
      active path (the path from which the selector selects the user
      data traffic) regardless of its origin (local or remote message).  This rule of giving the higher
      priority to
      The LER that has the SD on the standby path SHALL also be applied to
      the Local Request logic when two SDs for different paths happen to
      be presented to the Local Request logic exactly at the same time.

11.  State Transition Tables in APS Mode

   When there is a change in maintain the highest-priority
      local SD on the standby path request or in
   remote PSC messages, as the top priority global request is evaluated and
   the state transition tables are looked up in PSC control logic.
      request.  The
   following rules are applied to other LER that has local SD on the operation related active path SHALL
      use the remote SD on the standby path as the top priority global
      request to lookup the state transition table lookup.

   o  If table.  The differentiation
      of the active and standby paths is based upon which path had been
      used for the user data traffic at the time just before an LER
      selected its local SD as the top priority global request, which determines the state
      transition, request.

   No Request is another exception to the highest rule of assigning a remote
   request a priority local input, just below the same local request.  Since a
   received NR message needs to be used in the state transition table
   lookup when there is no outstanding local request, the received
   remote NR request SHALL be used to decide the next state of top priority global request when there
   is no request in the local LER.  Otherwise, remote messages state transition table

10.3.  Acceptance and retention of local inputs

   A local input indicating a defect, such as SF-P, SF-W, SD-P and SD-W,
   SHALL be
      used.

   o  If accepted and retained persistently in remote state, the Local Request
   logic as long as the defect condition exists.  If there is any higher
   priority local input than the local defect input, the higher priority
   local input is passed to the PSC Control logic as the highest local
   request, but the local defect condition (SF-P,
      SF-W, SD-P or SD-W) SHALL always input cannot be reflected removed but remains in
   the Local Request Field
      and Fpath.

   o logic.  When the higher priority local input
   disappears, the local defect will become the highest local request if
   the defect condition still exists.

   Operator Clear command, Clear SF/SD (SFc) SFDc and WTR Expires are not persistent.
   Once they appear to the local priority Local Request logic and complete the
   operation, they will SHALL be disappeared.

   Operator LO, FS, MS, and EXER commands SHALL be rejected if there is
   any higher priority local input in the Local Request logic.  If a new
   operator command is accepted, any previous lower-priority local
   operator command SHALL be cancelled.  When any higher priority remote
   request is received, a lower-priority local operator command SHALL be
   cancelled.  The cancelled operator command is forgotten and will
   never return, unless the operator reissues the command.

11.  State Transition Tables in APS Mode

   When there is a change in the highest local request or in remote PSC
   messages, the top priority global request SHALL be evaluated and the
   state transition tables SHALL be looked up in the PSC Control logic.
   The following rules are applied to the operation related to the state
   transition table lookup.

   o  If the top priority global request, which determines the state
      transition, is the highest local request, the local state
      transition table in Section 11.1 SHALL be used to decide the next
      state of the LER.  Otherwise, remote messages state transition
      table in Section 11.2 SHALL be used.

   o  If in remote state, the highest local defect condition (SF-P,
      SF-W, SD-P or SD-W) SHALL always be reflected in the Request Field
      and Fpath.

   o  For the LER currently in the local state, if the top priority
      global request is changed to OC or SFc SFDc causing the next state to
      be Normal, WTR or DNR, then all the local and remote requests
      should be re-evaluated as if the LER is in the state specified in
      the footnotes to the state transition tables, before deciding the
      final state.  This re-evaluation is an internal operation confined
      within the local LER, and PSC messages are generated according to
      the final state.

   o  The WTR timer is started only when the LER which has recovered
      from a local failure/degradation enters the WTR state.  An LER
      which is entering into the WTR state due to a remote WTR message
      does not start the WTR timer.  The WTR timer is stopped when any
      local or remote request triggers the state change out of the WTR
      state.

   The extended states, as they appear in the table, are as follows:

   N        Normal state
   UA:LO:L  Unavailable state due to local LO command
   UA:P:L   Unavailable state due to local SF-P
   UA:DP:L  Unavailable state due to local SD-P
   UA:LO:R  Unavailable state due to remote LO message
   UA:P:R   Unavailable state due to remote SF-P message
   UA:DP:L
   UA:DP:R  Unavailable state due to local remote SD-P message
   PF:W:L   Protecting failure state due to local SF-W
   PF:DW:L  Protecting failure state due to local SD-W
   PF:W:R   Protecting failure state due to remote SF-W message
   PF:DW:R  Protecting failure state due to remote SD-W message
   SA:F:L   Switching administrative state due to local FS command
   SA:MW:L  Switching administrative state due to local MS-W command
   SA:MP:L  Switching administrative state due to local MS-P command
   SA:F:R   Switching administrative state due to remote FS message
   SA:MW:R  Switching administrative state due to remote MS-W message
   SA:MP:R  Switching administrative state due to remote MS-P message
   E::L     Exercise state due to local EXER command
   E::R     Exercise state due to remote EXER message
   WTR      Wait-to-Restore state
   DNR      Do-not-Revert state

   Each state corresponds to the transmission of a particular set of
   Request, FPath and Path bits.  The table below lists the message that
   is generally sent in each particular state.  If the message to be
   sent in a particular state deviates from the table below, it is noted
   in the footnotes to the state transition tables.

   State    REQ(FP,P)
   -------  ---------
   N        NR(0,0)
   UA:LO:L  LO(0,0)
   UA:P:L   SF(0,0)
   UA:DP:L  SD(0,0)
   UA:LO:R  highest local request(local FPath,0)
   UA:P:R   highest local request(local FPath,0)
   UA:DP:R  highest local request(local FPath,0)
   PF:W:L   SF(1,1)
   PF:DW:L  SD(1,1)
   PF:W:R   highest local request(local FPath,1)
   PF:DW:R  highest local request(local FPath,1)
   SA:F:L   FS(1,1)
   SA:MW:L  MS(0,0)
   SA:MP:L  MS(1,1)
   SA:F:R   highest local request(local FPath,1)
   SA:MW:R  highest local request(local FPath,0)  NR(0,0)
   SA:MP:R  highest local request(local FPath,1)  NR(0,1)
   WTR      WTR(0,1)
   DNR      DNR(0,1)
   E::L     EXER(0,x), where x is the existing Path value
                       when Exercise command is issued.
   E::R     RR(0,x), where x is the existing Path value
                     when RR message is generated.

   Some operation examples of the APS mode are shown in Appendix D.

11.1.  State transition by local inputs
           | OC  | LO      | SFc SFDc | SF-P   | FS     | SF-W   |
   --------+-----+---------+-----+--------+--------+--------+
   --------+-----+---------+------+--------+--------+--------+
   N       | i   | UA:LO:L | i    | UA:P:L | SA:F:L | PF:W:L |
   UA:LO:L | (1) | i       | i    | i      | i      | i      |
   UA:P:L  | i   | UA:LO:L | (1)  | i      | i      | i      |
   UA:DP:L | i   | UA:LO:L | (1)  | UA:P:L | SA:F:L | PF:W:L |
   UA:LO:R | i   | UA:LO:L | i    | UA:P:L | i      | PF:W:L |
   UA:P:R  | i   | UA:LO:L | i    | UA:P:L | PF:W:L i      | PF:W:L |
   UA:DP:R | i   | UA:LO:L | i    | UA:P:L | SA:F:L | PF:W:L |
   PF:W:L  | i   | UA:LO:L | (2)  | UA:P:L | SA:F:L | i      |
   PF:DW:L | i   | UA:LO:L | (2)  | UA:P:L | SA:F:L | PF:W:L |
   PF:W:R  | i   | UA:LO:L | i    | UA:P:L | SA:F:L | PF:W:L |
   PF:DW:R | i   | UA:LO:L | i    | UA:P:L | SA:F:L | PF:W:L |
   SA:F:L  | (3) | UA:LO:L | i    | UA:P:L | i      | i      |
   SA:MW:L | (1) | UA:LO:L | i    | UA:P:L | SA:F:L | PF:W:L |
   SA:MP:L | (3) | UA:LO:L | i    | UA:P:L | SA:F:L | PF:W:L |
   SA:F:R  | i   | UA:LO:L | i    | UA:P:L | SA:F:L | PF:W:L |
   SA:MW:R | i   | UA:LO:L | i    | UA:P:L | SA:F:L | PF:W:L |
   SA:MP:R | i   | UA:LO:L | i    | UA:P:L | SA:F:L | PF:W:L |
   WTR     | i (4) | UA:LO:L | i    | UA:P:L | SA:F:L | PF:W:L |
   DNR     | i   | UA:LO:L | i    | UA:P:L | SA:F:L | PF:W:L |
   E::L    | (4) (5) | UA:LO:L | i    | UA:P:L | SA:F:L | PF:W:L |
   E::R    | i   | UA:LO:L | i    | UA:P:L | SA:F:L | PF:W:L |

           | SD-P    | SD-W    | MS-W    | MS-P    | WTRExp | EXER
   --------+---------+---------+---------+---------+--------+------
   N       | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i      | E::L
   UA:LO:L | i       | i       | i       | i       | i      | i
   UA:P:L  | i       | i       | i       | i       | i      | i
   UA:DP:L | i       | i       | i       | i       | i      | i
   UA:LO:R | UA:DP:L | PF:DW:L | i       | i       | i      | i
   UA:P:R  | UA:DP:L | PF:DW:L | i       | i       | i      | i
   UA:DP:R | UA:DP:L | PF:DW:L | i       | i       | i      | i
   PF:W:L  | i       | i       | i       | i       | i      | i
   PF:DW:L | i       | i       | i       | i       | i      | i
   PF:W:R  | UA:DP:L | PF:DW:L | i       | i       | i      | i
   PF:DW:R | UA:DP:L | PF:DW:L | i       | i       | i      | i
   SA:F:L  | i       | i       | i       | i       | i      | i
   SA:MW:L | UA:DP:L | PF:DW:L | i       | i       | i      | i
   SA:MP:L | UA:DP:L | PF:DW:L | i       | i       | i      | i
   SA:F:R  | UA:DP:L | PF:DW:L | i       | i       | i      | i
   SA:MW:R | UA:DP:L | PF:DW:L | SA:MW:L | i       | i      | i
   SA:MP:R | UA:DP:L | PF:DW:L | i       | SA:MP:L | i      | i
   WTR     | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | (6)    | i
   DNR     | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i      | E::L
   E::L    | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i      | i
   E::R    | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i      | E::L

11.2.  State transition by remote messages

           | LO      | SF-P   |
   NOTES:

   (1)  Re-evaluate to determine final state as if the LER is in the
        Normal state.

   (2)  In the case that both local input after SFDc and the last
        received remote message are no requests, the LER enters into the
        WTR state when the domain is configured for revertive behavior,
        or the LER enters into the DNR state when the domain is
        configured for non-revertive behavior.  In all the other cases,
        re-evaluate to determine the final state as if the LER is in the
        Normal state.

   (3)  Re-evaluate to determine final state as if the LER is in the
        Normal state when the domain is configured for revertive
        behavior, or as if the LER is in the DNR state when the domain
        is configured for non-revertive behavior,

   (4)  Remain in WTR and send NR(0,1).  Stop the WTR timer if it is
        running.

   (5)  If Path value is 0, re-evaluate to determine final state as if
        the LER is in the Normal state.  If Path value is 1, re-evaluate
        to determine final state as if the LER is in the DNR state.

   (6)  Remain in WTR and send NR(0,1).

11.2.  State transition by remote messages
           | LO      | SF-P   | FS     | SF-W   | SD-P    | SD-W    |
   --------+---------+--------+--------+--------+---------+---------+
   N       | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
   UA:LO:L | i       | i      | i      | i      | i       | i       |
   UA:P:L  | UA:LO:R | i      | i      | i      | i       | i       |
   UA:DP:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | i       | (10) (7)     |
   UA:LO:R | i       | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
   UA:P:R  | UA:LO:R | i      | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
   UA:DP:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | i       | PF:DW:R |
   PF:W:L  | UA:LO:R | UA:P:R | SA:F:R | i      | i       | i       |
   PF:DW:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | (11) (8)     | i       |
   PF:W:R  | UA:LO:R | UA:P:R | SA:F:R | i      | UA:DP:R | PF:DW:R |
   PF:DW:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R i       |
   SA:F:L  | UA:LO:R | UA:P:R | i      | i      | i       | i       |
   SA:MW:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
   SA:MP:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
   SA:F:R  | UA:LO:R | UA:P:R | i      | PF:W:R | UA:DP:R | PF:DW:R |
   SA:MW:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
   SA:MP:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
   WTR     | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
   DNR     | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
   E::L    | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
   E::R    | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |

           | MS-W    | MS-P    | WTR | EXER | RR | DNR  | NR
   --------+---------+---------+-----+------+----+-----+----
   --------+---------+---------+-----+------+----+------+----
   N       | SA:MW:R | SA:MP:R | i   | E::R | i  | i    | i
   UA:LO:L | i       | i       | i   | i    | i  | i    | i
   UA:P:L  | i       | i       | i   | i    | i  | i    | i
   UA:DP:L | i       | i       | i   | i    | i  | i    | i
   UA:LO:R | SA:MW:R | SA:MP:R | i   | E::R | i  | i    | N
   UA:P:R  | SA:MW:R | SA:MP:R | i   | E::R | i  | i    | N
   UA:DP:R | SA:MW:R | SA:MP:R | i   | E::R | i  | i    | N
   PF:W:L  | i       | i       | i   | i    | i  | i    | i
   PF:DW:L | i       | i       | i   | i    | i  | i    | i
   PF:W:R  | SA:MW:R | SA:MP:R | (7) (9) | E::R | i  | (8) (10) | (5) (11)
   PF:DW:R | SA:MW:R | SA:MP:R | (7) (9) | E::R | i  | (8) (10) | (5) (11)
   SA:F:L  | i       | i       | i   | i    | i  | i    | i
   SA:MW:L | i       | i       | i   | i    | i  | i    | i
   SA:MP:L | i       | i       | i   | i    | i  | i    | i
   SA:F:R  | SA:MW:R | SA:MP:R | i   | E::R | i  | DNR  | N
   SA:MW:R | i       | SA:MP:R | i   | E::R | i  | i    | N
   SA:MP:R | SA:MW:R | i       | i   | E::R | i  | DNR  | N
   WTR     | SA:MW:R | SA:MP:R | i   | i    | i  | i    | (9) (12)
   DNR     | SA:MW:R | SA:MP:R | i   | E::R | i  | i    | i
   E::L    | SA:MW:R | SA:MP:R | i   | (13)| i    | i  | i    | i
   E::R    | SA:MW:R | SA:MP:R | i   | i    | i  | DNR  | N
   NOTES:

   (1)  Re-evaluate to determine final state as if the LER is in

   (7)  If the
        Normal state.

   (2)  In received SD-W message has Path=0, ignore the case that both local input and message.  If
        the last received remote SD-W message are no request after the occurrence of SFc, the LER
        enters into the WTR has Path=1, go to PF:DW:R state when the domain is configured for
        revertive behavior, or the LER enters into and
        transmit SD(0,1)

   (8)  If the DNR state when received SD-P message has Path=1, ignore the domain is configured for non-revertive behavior.  In all message.  If
        the
        other cases, re-evaluate received SD-P message has Path=0, go to determine the final UA:DP:R state as if the
        LER is in the Normal state.

   (3)  Re-evaluate and
        transmit SD(1,0).

   (9)  Transition to determine final state as if the LER is in the
        Normal state when the domain is configured for revertive
        behavior, or as if the LER is in the DNR WTR state when the domain
        is configured for non-revertive behavior,

   (4)  If Path value is 0, re-evaluate and continue to determine final state as if
        the LER is in send the Normal state.  If Path value is 1, re-evaluate current
        message.

   (10) Transition to determine final state as if the LER is in the DNR state

   (5) and continue to send the current
        message.

   (11) If the received NR message has Path=1, transition to WTR if
        domain configured for revertive behavior, else transition to
        DNR.

   (6)  Remain in WTR, send NR(0,1).

   (7)  Transition to WTR state and continue to send  If the current
        message.

   (8)  Transition to DNR state and continue received NR message has Path=0, transition to send the current
        message.

   (9) N.

   (12) If the receiving LER's WTR timer is running, maintain current
        state and message.  If the WTR timer is not running, transition
        to N.

   (10) If the active path just before the SD is selected as the highest
        local input was the working path, then ignore.  Otherwise, go

   (13) Transit to
        PF:DW:R WTR state and transmit SD(0,1)

   (11) If the received SD-P message has Path=1, ignore the send NR(0,1) message.  If
        the received SD-P message has Path=0 and the active path just
        before the SD  The WTR timer is selected as the highest local input was the
        working path, then go to UA:DP:R
        not initiated.

11.3.  State transition for 1+1 unidirectional protection

   The state transition tables given in Section 11.1 and transmit SD(1,0).  If Section 11.2
   are for bidirectional protection switching, where remote PSC protocol
   messages are used to determine the
        received SD-P protection switching actions.  The
   1+1 unidirectional protection switching does not require the remote
   information in PSC protocol message has Path=0 and the active path just before
        the SD is selected as the highest acts upon local input was inputs only.
   The state transition by local inputs in Section 11.1 SHALL be reused
   for the 1+1 unidirectional protection
        path, then ignore under the following conditions:

   o  The value of Request field in the received SD-P message.

12.  Security considerations

   No specific security issue remote message is raised in addition
      ignored and always assumed to those ones
   already documented in [RFC6378]

13.  IANA considerations

13.1.  PSC Request Field

   This document defines two new values be no request.

   o  Replace footnote (4) with "Stop the WTR timer and transit to
      Normal state."

   o  Replace footnote (6) with "Transit to Normal state."

   o  Exercise is not applicable.

12.  Provisioning mismatch and protocol failure in the "MPLS PSC Request
   Registry". APS mode

   The remote PSC Request Field message that is 4 bits, and received from the two new values have been
   allocated as follows:

   Value Description              Reference
   ----- --------------------- ---------------
    TBD1 Reverse Request       [this document]
    TBD2 Exercise              [this document]

   [to be removed upon publication: It remote LER is requested
   subject to assign 2
   (=TBD1)for the Reverse Request value detection of provisioning mismatch and 3 (=TBD2) for protocol
   failure conditions.  In the Exercise
   value to be aligned with APS mode, provisioning mismatches are
   handled as follows:

   o  If the priority levels of those two requests
   defined in this document.]

13.2. PSC TLV

   This document defines a new value for message is received from the working path due to
      working/protection path configuration mismatch, the node MUST
      alert the operator and MUST NOT perform any protection switching.

   o  If the "Protection Type (PT)" field mismatches and two sides are
      unable to converge as described in Section 5.1 in
      [I-D.ietf-mpls-psc-updates], the node MUST alert the operator and
      MUST NOT perform any protection switching.

   o  If the "Revertive (R)" bit mismatches, two sides will interwork
      and traffic is protected in the APS mode.  The node MAY notify the
      operator of this event.

   o  If the Capabilities TLV type mismatches, the node MUST alert the
      operator and MUST NOT perform any protection switching.

   The followings are the protocol failure situations and the actions to
   be taken:

   o  No match in sent "Data Path (Path)" and received "Data Path
      (Path)" for more than 50 ms: The node MAY continue to perform
      protection switching and SHOULD notify the "MPLS operator of these
      events:

   o  No PSC message is received on the protection path during at least
      3.5 times the long PSC message interval (e.g. at least 17.5
      seconds) and there is no defect on the protection path (The
      Capabilities TLV Timeout error specifies in Section 9.1.3 is
      included in this situation.): The node MUST alert the operator and
      MUST NOT perform any protection switching.

13.  Security considerations

   No specific security issue is raised in addition to those ones
   already documented in RFC 6378 [RFC6378]

14.  IANA considerations
14.1.  MPLS PSC Request Registry

   In the "Multiprotocol Label Switching (MPLS) Operations,
   Administration, and Management (OAM) Parameters" registry, IANA
   maintains the "MPLS PSC Request Registry".

   Type  TLV Name

   IANA is requested to assign two new code points from this registry.
   The values shall be allocated as follows:

      Value Description           Reference
      ----- --------------------- ---------------
   TBD3  Capabilities          [this document]

   [Editor's note: Need to specify
       2    Reverse Request       (this document)
       3    Exercise              (this document)

14.2.  MPLS PSC TLV Registry

   In the "Multiprotocol Label Switching (MPLS) Operations,
   Administration, and Management (OAM) Parameters" registry, IANA
   maintains the "MPLS PSC TLV Registry".

   This document defines a registry new value for Value (=options)
   inside the Capabilities TLV type in
   the "MPLS PSC TLV Registry".

      Value  Description           Reference
      ------ --------------------- ---------------
      TBD    Capabilities          (this document)

14.3.  MPLS PSC Capability Flag Registry

   IANA is requested to create and maintain a later version new registry within the
   "Multiprotocol Label Switching (MPLS) Operations, Administration, and
   Management (OAM) Parameters" registry called "MPLS PSC Capability
   Flag Registry".  All flags within this registry SHALL be allocated
   according to the "Standards Action" procedures as specified in RFC
   5226 [RFC5226].

   The length of the flags MUST be a multiple of 4 octets.  This
   document defines 4 octet flags.  Flags greater than 4 octets SHALL be
   used only if more than 32 Capabilities need to be defined.  Flags
   defined in this draft]

14.  Acknowledgements document are:

   Bit  Hex Value  Capability                          Reference
   ---- ---------- ----------------------------------- ---------------
    0   0x80000000 priority modification               (this document)
    1   0x40000000 non-revertive behavior modification (this document)
    2   0x20000000 support of MS-W command             (this document)
    3   0x10000000 support of protection against SD    (this document)
    4   0x08000000 support of EXER command             (this document)
   5-31            Unassigned                          (this document)

15.  Acknowledgements

16.  References

15.1.

16.1.  Normative References

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

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

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

   [RFC6378]  Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
              A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear
              Protection", RFC 6378, October 2011.

   [I-D.ietf-mpls-psc-updates]
              Osborne, E., "Updates to PSC", draft-ietf-mpls-psc-
              updates-00 (work in progress), October 2013.

15.2.

16.2.  Informative References

   [RFC4427]  Mannie, E. and D. Papadimitriou, "Recovery (Protection and
              Restoration) Terminology for Generalized Multi-Protocol
              Label Switching (GMPLS)", RFC 4427, March 2006.

   [RFC6372]  Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS-
              TP) Survivability Framework", RFC 6372, September 2011.

   [G841]     International Telecommunications Union, "Types and
              characteristics of SDH network protection architectures",
              ITU-T Recommendation G.841, October 1998.

   [G873.1]   International Telecommunications Union, "Optical Transport
              Network (OTN): Linear protection", ITU-T Recommendation
              G.873.1, July 2011.

   [G8031]    International Telecommunications Union, "Ethernet Linear
              Protection Switching", ITU-T Recommendation G.8031/Y.1342,
              June 2011.

Appendix A.  An example of out-of-service scenarios

   The sequence diagram shown is an example of the out-of-service
   scenerios based on the priority level defined in [RFC6378]. out-of-service
   scenarios based on the priority level defined in RFC 6378.  The first
   PSC message which differs from the previous PSC message is shown.

                       A                  Z
                       |                  |
                   (1) |-- NR(0,0) ------>| (1)
                       |<----- NR(0,0) ---|
                       |                  |
                       |                  |
                       | (FS issued at Z) | (2)
                   (3) |<------ FS(1,1) --|
                       |-- NR(0,1) ------>|
                       |                  |
                       |                  |
                   (4) | (SF on P(A<-Z))  |
                       |                  |
                       |                  |
                       | (Clear FS at Z)  | (5)
                   (6) |   X <- NR(0,0) --|
                       |                  |
                       |                  |

   (1) Each end is in the Normal state, and transmits NR(0,0) messages.

   (2) When a FS command is issued at node Z, node Z goes into local
   Protecting administrative state (PA:F:L) and begins transmission of
   an FS(1,1) messages.

   (3) A remote FS message causes node A to go into remote Protecting
   administrative state (PA:F:R), and node A begins transmitting NR(0,1)
   messages.

   (4) When node A detects a unidirectional SF-P, node A keeps sending
   NR(0,1) message because SF-P is ignored under the PA:F:R state.

   (5) When a Clear command is issued at node Z, node Z goes into the
   Normal state and begins transmission of NR(0,0) messages.

   (6) But, node A cannot receive PSC message because of local
   unidirectional SF-P.  Because no valid PSC message is received, over
   a period of several successive message intervals, the last valid
   received message remains applicable and the node A continue to
   transmit an NR(0,1) message in the PA:F:R state.

   Now, there exists a mismatch between the bridge/selector positions of
   node A (transmitting an NR(0,1)) and node Z (transmitting an
   NR(0,0)).  It results in out-of-service even when there is neither
   SF-W nor FS.

Appendix B.  An example of sequence diagram showing the problem with the
             priority level of SFc

   An example of sequence diagram showing the problem with the priority
   level of SFc defined in RFC 6378 is given below.  The following
   sequence diagram is depicted for the case of bidirectional signal
   fails.  However, other cases with unidirectional signal fails can
   result in the same problem.  The first PSC message which differs from
   the previous PSC message is shown.

                       A                  Z
                       |                  |
                   (1) |-- NR(0,0) ------>| (1)
                       |<----- NR(0,0) ---|
                       |                  |
                       |                  |
                   (2) | (SF on P(A<->Z)) | (2)
                       |-- SF(0,0) ------>|
                       |<------ SF(0,0) --|
                       |                  |
                       |                  |
                   (3) | (SF on W(A<->Z)) | (3)
                       |                  |
                       |                  |
                   (4) |   (Clear SF-P)   | (4)
                       |                  |
                       |                  |
                   (5) |   (Clear SF-W)   | (5)
                       |                  |
                       |                  |

   (1) Each end is in the Normal state, and transmits NR(0,0) messages.

   (2) When SF-P occurs, each node enters into the UA:P:L state and
   transmits SF(0,0) messages.  Traffic remains on the working path.

   (3) When SF-W occurs, each node remains in the UA:P:L state as SF-W
   has a lower priority than SF-P.  Traffic is still on the working
   path.  Traffic cannot be delivered as both the working path and the
   protection path are experiencing signal fails.

   (4) When SF-P is cleared, local "Clear SF-P" request cannot be
   presented to the PSC Control logic, which takes the highest local
   request and runs PSC state machine, since the priority of "Clear
   SF-P" is lower than that of SF-W.  Consequently, there is no change
   in state, and the selector and/or bridge keep pointing at the working
   path, which has signal fail condition.

   Now, traffic cannot be delivered while the protection path is
   recovered and available.  It should be noted that the same problem
   will occur in the case that the sequence of SF-P and SF-W events is
   changed.

   If we further continue with this sequence to see what will happen
   after SF-W is cleared,

   (5) When SF-W is cleared, local "Clear SF-W" request can be passed to
   the PSC Control logic as there is no higher priority local input, but
   this will be ignored in the PSC Control logic according to the state
   transition definition in RFC 6378.  There will be no change in state
   or protocol message transmitted.

   As SF-W is now cleared and the selector and/or bridge are still
   pointing at the working path, traffic delivery is resumed.  However,
   each node is the in UA:P:L state and transmitting SF(0,0) message,
   while there exists no outstanding request for protection switching.
   Moreover, any future legitimate protection switching requests, such
   as SF-W, will be rejected as each node thinks the protection path is
   unavailable.

Appendix C.  Freeze Command

   The "Freeze" command applies only to the local LER of the protection
   group and is not signaled to the remote LER.  This command freezes
   the state of the protection group.  Until the Freeze is cleared,
   additional local commands are rejected and condition changes and
   received PSC information are ignored.

   "Clear Freeze" command clears the local freeze.  When the Freeze
   command is cleared, the state of the protection group is recomputed
   based on the persistent condition of the local triggers.

   Because the freeze is local, if the freeze is issued at one end only,
   a failure of protocol can occur as the other end is open to accept
   any operator command or a fault condition.

Appendix D.  Operation examples of the APS mode

   The sequence diagrams shown in this section are only a few examples
   of the APS mode operations.  The first PSC protocol message which
   differs from the previous PSC message is shown.  The operation of hold-
   off timer is omitted.  The Request, FPath and Path fields, whose
   values are changed during PSC message exchange are shown.  For an
   example, SF(1, 0) represents an PSC message with the following field
   values: Request = SF, FPath = 1, and Path = 1.  The values of the
   other fields remain unchanged from the initial configuration.
   W(A->Z) and P(A->Z) indicate the working path and the protection path
   in the direction of A to Z, respectively.

   Example 1. 1:1 bidirectional protection switching (revertive mode) -
   Unidirectional SF case

                       A                  Z
                       |                  |
                   (1) |-- NR(0,0) ------>| |<---- NR(0,0)---->| (1)
                    |<----- NR(0,0) ---|
                       |                  |
                       |                  |
                   (2) | (FS issued at Z) (SF on W(Z->A))  | (2)
                       |---- SF(1,1)----->| (3) |<------ FS(1,1) --|
                    |-- NR(0,1) ------>|
                   (4) |<----- NR(0,1)----|
                       |                  |
                       |                  |
                (4)
                   (5) | (SF on P(A<-Z))  (Clear SF-W)    |
                       |---- WTR(0,1)---->|
                      /|                  |
                     | |                  |
             WTR timer |                  | (Clear FS at Z)
                     | (5)
                (6) |   X <- NR(0,0) --|                  |
                      \|                  |
                   (6) |---- NR(0,1)----->| (7)
                   (8) |<----- NR(0,0)----|
                       |---- NR(0,0)----->| (9)
                       |                  |

   (1) Each end The protection domain is operating without any defect, and the
   working path is used for delivering the traffic in the Normal state, and transmits NR (0,0) messages. state.

   (2) When a Forced Switch command is issued at node Z, node SF-W occurs in the Z goes
   into local Protecting Administrative state (PA:F:L) and begins
   transmission of an FS (1,1) messages.

   (3) to A remote Forced Switch message causes node direction.  Node A to go enters into remote
   Protecting Administrative the
   PF:W:L state (PA:F:R), and generates SF(1, 1) message.  Selector and bridge of
   node A begins
   transmitting NR (0,1) messages.

   (4) When node A detects a unidirectional Signal Fail on are pointing at the
   Protection path, protection path.

   (3) Upon receiving SF(1, 1), node A keeps sending NR (0,1) message because SF-P
   is ignored under Z sets selector and bridge to the state PA:F:R.

   (5) When a Clear command
   protection path.  As there is issued at no local request in node Z, node Z goes into Normal
   state and begins transmission of NR (0,0) messages.

   (6) But node A cannot receive PSC
   generates NR(0, 1) message because of local
   unidirectional Signal Fail on in the Protection path.  Because no valid
   PSC message PF:W:R state.

   (4) Node A confirms that the remote LER is received, over a period also selecting protection
   path.

   (5) Node A detects clearing of several successive message
   intervals, SF condition, starts the last valid received message remains applicable WTR timer,
   and the
   node A continue to transmit an NR (0,1) sends WTR(0, 1) message in the state WTR state.

   (6) At expiration of
   PA:F:R.

   Now, there exists a mismatch between the bridge/selector positions of WTR timer, node A (transmitting an NR (0,1)) sets selector and node Z (transmitting an NR
   (0,0)).  It results in out-of-service even when there is neither
   signal fail on bridge
   to the working path nor FS.

Appendix B.  An example of sequence diagram showing the problem with and sends NR(0, 1) message.

   (7) Node Z is notified that the
             priority level of Clear SF

   An example of sequence diagram showing remote request has been cleared.
   Node Z transits to the problem with Normal state and sends NR(0,0) message.

   (8) Upon receiving NR(0,0) message, node A transits to the priority
   level of Clear SF defined in [RFC6378] Normal
   state and sends NR(0,0) message.

   (9) It is given below.  The following
   sequence diagram confirmed that the remote LER is depicted for also selecting the case of working
   path.

   Example 2. 1:1 bidirectional signal
   fails.  However, other cases with unidirectional signal fails can
   result in the same problem.  The first PSC message which differs from
   the previous PSC message is shown. protection switching (revertive mode) -
   Bidirectional SF case - Inconsistent WTR timers
                       A                  Z
                       |                  |
                   (1) |-- NR(0,0) ------>| |<---- NR(0,0)---->| (1)
                    |<----- NR(0,0) ---|
                    |                  |
                    |                  |
                (2) | (SF on P(A<->Z)) | (2)
                    |-- SF(0,0) ------>|
                    |<------ SF(0,0) --|
                       |                  |
                       |                  |
                (3)
                   (2) | (SF on W(A<->Z)) | (3) (2)
                       |<---- SF(1,1)---->|
                       |                  |
                       |                  |
                (4)
                   (3) |   (Clear SF-P) SF-W)   | (3)
                       |<---- NR(0,1)---->|
                   (4) |<--- WTR(0,1) --->| (4)
                      /|                  |\
                     | |                  | |
                (5)
             WTR timer |   (Clear SF-W)                  | WTR timer
                     | |                  | |
                     | |                  |/
                     | |<------ NR(0,1)---| (5)
                     | |                  |
                      \|                  |
                   (6) |--- NR(0,1)------>|
                       |<------ NR(0,0)---| (7)
                   (8) |--- NR(0,0)------>|
                       |                  |

   (1) Each end is in the Normal state, and transmits NR (0,0) NR(0,0) messages.

   (2) When signal fail on protection (SF-P) SF-W occurs, each node enters into [UA:P:L] the PF:W:L state and
   transmits SF (0,0) SF(1,1) messages.  Traffic remains
   on working is switched to the protection
   path.

   (3) When signal fail on working (SF-W) occurs,  Upon receiving SF(1,1), each node remains in
   [UA:P:L] state as SF-W has a lower priority than SF-P.  Traffic is
   still on confirms that the working path.  Traffic cannot be delivered as both
   working remote LER
   is also sending and protection paths are experiencing signal fails.

   (4) When receiving the traffic from the signal fail on protection path.

   (3) When SF-W is cleared, local "Clear SF-P"
   request cannot be presented each node transits to the PSC control logic, which takes the
   highest priority local request and runs PSC PF:W:R state machine, and
   transmits NR(0,1) messages as the
   priority of "Clear SF-P" last received message is lower than that of SF-W.  Consequently,
   there is no change in

   (4) Upon receiving NR(0,1) messages, each node goes into the WTR
   state, starts the WTR timer, and sends the WTR(0,1) messages.

   (5) At expiration of the WTR timer in node Z, node Z sends NR(0,1) as
   the last received APS message was WTR.  When NR(0,1) arrives at node
   A, node A maintains the WTR state and keeps sending current WTR
   messages as described in the state transition table.

   (6) At expiration of the WTR timer in node A, node A sends NR(0,1).

   (7) When the NR(0,1) message arrives at node Z, node Z moves to the
   Normal state, sets selector and/or and bridge keep
   pointing at to the working path, and sends
   NR(0, 0) message.

   (8) The received NR(0,0) message causes node A to go to the working path, which has signal fail condition. Normal
   state.  Now, the traffic cannot be delivered while is switched back to the working path.

   Example 3. 1:1 bidirectional protection path is
   recovered and available.  It should be noted switching - R bit mismatch

   This example shows that the same problem both sides will occur in the case that the sequence of SF-P interwork and SF-W events the traffic is
   changed.

   If we further continue with this sequence to see what will happen
   after SF-W
   protected when one side (node A) is cleared,

   (5) When configured as revertive mode and
   the signal fail on working other (node Z) is cleared, local "Clear SF-W"
   request can be passed to the PSC control logic (state machine) configured as
   there non-revertive mode.  The
   interworking is no higher priority local request, but this will be ignored covered in the PSC control logic according to the state transition definition
   in [RFC6378].  There will be no change in state or protocol message
   transmitted.

   As the signal fail tables.

           (revertive) A                  Z (non-revertive)
                       |                  |
                   (1) |<---- NR(0,0)---->| (1)
                       |                  |
                       |                  |
                   (2) | (SF on working W(A<->Z)) | (2)
                       |<---- SF(1,1)---->|
                       |                  |
                       |                  |
                   (3) |   (Clear SF-W)   | (3)
                       |<---- NR(0,1)---->|
                   (4) |<----- DNR(0,1)---| (4)
                      /|-- WTR(0,1)------>|
                     | |<----- NR(0,1)----| (5)
                     | |                  |
             WTR timer |                  |
                     | |                  |
                     | |                  |
                      \|                  |
                   (6) |--- NR(0,1)------>|
                       |<------ NR(0,0)---| (7)
                   (8) |--- NR(0,0)------>|
                       |                  |

   (1) Each end is now cleared and the selector and/or
   bridge are still pointing at in the working path, traffic delivery is
   resumed.  However, Normal state, and transmits NR(0,0) messages.

   (2) When SF-W occurs, each node is in [UA:P:L] enters into the PF:W:L state and transmitting
   SF(0,0) message, while there exists no outstanding request for
   protection switching.  Moreover, any future legitimate
   transmits SF(l,l) messages.  Traffic is switched to the protection
   switching requests, such as SF-W, will be rejected as
   path.  Upon receiving SF(1,1), each node
   thinks confirms that the protection path remote LER
   is unavailable.

Appendix C.  Freeze Command

   The "Freeze" command applies only to also sending and receiving the near end (local node) of traffic on the protection group and path.

   (3) When SF-W is not signalled cleared, each node transits to the far end.  This command
   freezes the PF:W:R state of the protection group.  Until and
   transmits NR(0,1) messages as the Freeze last received message is
   cleared, additional near end commands are rejected and condition
   changes SF-W.

   (4) Upon receiving NR(0,1) messages, node A goes into the WTR state,
   starts the WTR timer, and received PSC information are ignored.

   "Clear Freeze" command clears sends WTR(0,1) messages.  At the local freeze. same time,
   node B transits to the DNR state and sends DNR(0,1) message.

   (5) When the Freeze
   command is cleared, WTR message arrives at node Z, node Z transits to the
   WTR state of and send NR(0,1) message according to the protection group is recomputed
   based on state transition
   table.  At the persistent condition of same time, the local triggers.

   Because DNR message arrived at node Z is
   ignored according to the freeze state transition table.  Therefore, node Z,
   which is local, configured as non-revertive mode, is operating as if in
   revertive mode.

   (6) At expiration of the freeze is issued WTR timer in node A, node A sends NR(0,1).

   (7) When the NR(0,1) message arrives at one end only,
   a failure of protocol can occur as node Z, node Z moves to the other end
   Normal state, sets selector and bridge to the working path, and sends
   NR(0, 0) message.

   (8) The received NR(0,0) message causes node A to transits to the
   Normal state.  Now, the traffic is open switched back to accept
   any operator command or a fault condition. the working path.

Authors' Addresses

   Jeong-dong Ryoo (editor)
   ETRI
   218 Gajeongno
   Yuseong-gu, Daejeon  305-700
   South Korea

   Phone: +82-42-860-5384
   Email: ryoo@etri.re.kr

   Eric Gray (editor)
   Ericsson

   Email: eric.gray@ericsson.com

   Huub van Helvoort
   Huawei Technologies
   Karspeldreef 4,
   Amsterdam 1101 CJ
   the Netherlands

   Phone: +31 20 4300936
   Email: huub.van.helvoort@huawei.com
   Alessandro D'Alessandro
   Telecom Italia
   via Reiss Romoli, 274
   Torino  10148
   Italy

   Phone: +39 011 2285887
   Email: alessandro.dalessandro@telecomitalia.it

   Taesik Cheung
   ETRI
   218 Gajeongno
   Yuseong-gu, Daejeon  305-700
   South Korea

   Phone: +82-42-860-5646
   Email: cts@etri.re.kr

   Eric Osborne
   Cisco Systems, Inc.

   Email: eosborne@cisco.com