[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-weingarten-mpls-tp-linear-protection) 00 01 02 03 04 05 06 07 08 09 RFC 6378

Network Working Group                                     S. Bryant, Ed.
Internet-Draft                                                E. Osborne
Intended status: Standards Track                                   Cisco
Expires: April 27, 2011                                 N. Sprecher, Ed.
                                                  Nokia Siemens Networks
                                                       A. Fulignoli, Ed.
                                                                Ericsson
                                                           Y. Weingarten
                                                  Nokia Siemens Networks
                                                        October 24, 2010


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

Abstract

   The Transport Profile for Multiprotocol Label Switching (MPLS-TP) is
   being specified jointly by IETF and ITU-T.  This document addresses
   the functionality described in the MPLS-TP Survivability Framework
   document [SurvivFwk] and defines a protocol that may be used to
   fulfill the function of the Protection State Coordination for linear
   protection, as described in that document.

   This document is a product of a joint Internet Engineering Task Force
   (IETF) / International Telecommunications Union Telecommunications
   Standardization Sector (ITU-T) effort to include an MPLS Transport
   Profile within the IETF MPLS and PWE3 architectures to support the
   capabilities and functionalities of a packet transport network as
   defined by the ITU-T.

Status of this Memo

   This Internet-Draft is submitted 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 April 27, 2011.




Bryant, et al.           Expires April 27, 2011                 [Page 1]

Internet-Draft                 MPLS-TP LP                   October 2010


Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

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

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

























Bryant, et al.           Expires April 27, 2011                 [Page 2]

Internet-Draft                 MPLS-TP LP                   October 2010


Table of Contents

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














Bryant, et al.           Expires April 27, 2011                 [Page 3]

Internet-Draft                 MPLS-TP LP                   October 2010


1.  Introduction

   The MPLS Transport Profile (MPLS-TP) [TPFwk] is a framework for the
   construction and operation of packet-switched transport networks
   based on the architectures for MPLS ([RFC3031] and [RFC3032]) and for
   Pseudowires (PWs) ([RFC3985] and [RFC5659]) and the requirements of
   [RFC5654].

   Network survivability is the ability of a network to recover traffic
   delivery following failure, or degradation of network resources.  The
   MPLS-TP Survivability Framework [SurvivFwk] is a framework for
   survivability in MPLS-TP networks, and describes recovery elements,
   types, methods, and topological considerations, focusing on
   mechanisms for recovering MPLS-TP Label Switched Paths (LSPs).

   Linear protection in mesh networks - networks with arbitrary
   interconnectivity between nodes - is described in Section 4.7 of
   [SurvivFwk].  Linear protection provides rapid and simple protection
   switching.  In a mesh network, linear protection provides a very
   suitable protection mechanism because it can operate between any pair
   of points within the network.  It can protect against a defect in an
   intermediate node, a span, a transport path segment, or an end-to-end
   transport path.

1.1.  Protection architectures

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

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

   In 1+1 unidirectional architecture as presented in [SurvivFwk], a
   recovery transport path is dedicated to the working transport path.
   Normal traffic is bridged (as defined in [RFC4427])and fed to both
   the working and the recovery transport entities by a permanent bridge
   at the source of the protection domain.  The sink of the protection
   domain selects which of the working or recovery entities to receive



Bryant, et al.           Expires April 27, 2011                 [Page 4]

Internet-Draft                 MPLS-TP LP                   October 2010


   the traffic from, based on a predetermined criteria, e.g. server
   defect indication.  When used for bidirectional switching the 1+1
   protection architecture must also support a Protection State
   Coordination (PSC) protocol.  This protocol is used to help
   coordinate between both ends of the protection domain in selecting
   the proper traffic flow.

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

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

1.2.  Scope of the document

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

   The scope of this draft is to present a protocol for the Protection
   State Coordination of Linear Protection.  The protocol addresses the
   protection of LSPs in an MPLS-TP network as required by [RFC5654] (in
   particular requirements 63-67 and 74-79) and described in
   [SurvivFwk].  The basic protocol is designed for use in conjunction
   with the 1:1 protection architecture (for both unidirectional and
   bidirectional protection) and for 1+1 protection of a bidirectional



Bryant, et al.           Expires April 27, 2011                 [Page 5]

Internet-Draft                 MPLS-TP LP                   October 2010


   path (for both unidirectional and bidirectional protection
   switching).  Applicability of the protocol for 1:n protection schemes
   may be documented in a future document.  The applicability of this
   protocol to additional MPLS-TP constructs and topologies may be
   documented in future documents.

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

1.3.  Contributing authors

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


2.  Conventions used in this document

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


























Bryant, et al.           Expires April 27, 2011                 [Page 6]

Internet-Draft                 MPLS-TP LP                   October 2010


2.1.  Acronyms

   This draft uses the following acronyms:

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

2.2.  Definitions and Terminology

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


3.  Protection switching control logic

3.1.  Protection switching control logical architecture

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

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









Bryant, et al.           Expires April 27, 2011                 [Page 7]

Internet-Draft                 MPLS-TP LP                   October 2010


                  Server Indication     Control Plane Indication
                  -----------------+  +-------------
                Operator Command   |  |   OAM Indication
                ----------------+  |  |  +---------------
                                |  |  |  |
                                V  V  V  V
                             +---------------+         +-------+
                             | Local Request |<--------|  WTR  |
                             |    logic      |WTR Exps | Timer |
                             +---------------+         +-------+
                                    |                      ^
                       Highest local|request               |
                                    V                      | Start/Stop
                            +-----------------+            |
                Remote PSC  |  PSC  Process   |------------+
               ------------>|      logic      |
                  Request   +-----------------+
                                    |
                                    |  Action         +------------+
                                    +---------------->|  Message   |
                                                      | Generator  |
                                                      +------------+
                                                            |
                                                 Output PSC | Message
                                                            V


               Figure 1: Protection switching control logic

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

3.1.1.  Local Request Logic

   The protection switching logic processes input triggers from five
   sources:






Bryant, et al.           Expires April 27, 2011                 [Page 8]

Internet-Draft                 MPLS-TP LP                   October 2010


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

   o  Server layer alarm indication - the underlying server layer of the
      network detects failure conditions at the underlying layer and may
      issue an indication to the MPLS-TP layer.  The server layer may
      employ its own protection switching mechanism, and therefore this
      input MAY be controlled by a holdoff-timer that SHOULD be
      configurable by the network operator.

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

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

   o  WTR expires - The Wait-to-Restore timer is used in conjunction
      with recovery from failure conditions on the working path in
      revertive mode.  The timer SHALL signal the PSC control process
      when it expires and the end point SHOULD revert to the normal
      transmission of the user data traffic.

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

   o  Clear - if the operator cancels an active local administrative
      command, i.e.  LO/FS/MS.

   o  Lockout of Protection (LO) - if the operator requested to disable
      the protection path.

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

   o  Signal Degrade (SD) - if any of the Server Layer, Control plane,
      or OAM indications signaled a degraded transmission condition on
      either the protection path or one of the working paths




Bryant, et al.           Expires April 27, 2011                 [Page 9]

Internet-Draft                 MPLS-TP LP                   October 2010


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

   o  Forced Switch (FS) - if the operator requested that traffic be
      switched from one of the working paths to the protection path.

   o  Manual Switch (MS) - if the operator requested that traffic be
      switched from its current path to the other path.  This is only
      relevant if there is no currently active Fault condition or
      Operator command.

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

   If none of the input sources have generated any input then the
   current local request SHALL be a No Request (NR) request.

3.1.2.  Remote Requests

   In addition to the local requests generated as a result of the local
   triggers indicated in the previous subsection, the PSC Control Logic
   SHALL accept PSC messages from the far-end LER of the transport path.
   These remote messages indicate the status of the transport path from
   the viewpoint of the far-end LER, and may indicate if the local MEP
   SHOULD initiate a protection switch operation.

   The following remote requests may be received by the PSC process:

   o  Remote LO - indicates that the remote end point is in Unavailable
      state due to a Lockout of Protection operator command.

   o  Remote SF - indicates that the remote end point has detected a
      Signal Fail condition on one of the transport paths in the
      protection domain.  This remote message SHALL include an
      indication of which transport path is affected by the SF
      condition.  In addition, it should be noted that the SF condition
      may be either a unidirectional or a bidirectional failure, even if
      the transport path is bidirectional.

   o  Remote SD - indicates that the remote end point has detected a
      Signal Degrade condition on one of the transport paths in the
      protection domain.  This remote message SHALL include an
      indication of which transport path is affected by the SD
      condition.  In addition, it should be noted that the SD condition
      may be either a unidirectional or a bidirectional failure, even if
      the transport path is bidirectional.





Bryant, et al.           Expires April 27, 2011                [Page 10]

Internet-Draft                 MPLS-TP LP                   October 2010


   o  Remote FS - indicates that the remote end point is operating under
      an operator command to switch the traffic to the protection path.

   o  Remote MS - indicates that the remote end point is operating under
      an operator command to switch the traffic to the path that was not
      being used previously.

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

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

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

3.1.3.  PSC Process Logic

   The PSC Process Logic SHALL accept as input -

   a.  the Local request output from the Local Request Logic,

   b.  the remote request message from the remote end point of the
       transport path, and

   c.  the current state of the PSC Control Logic (maintained internally
       by the PSC Control Logic).

   Based on the priorities between the different inputs, the PSC Process
   Logic SHALL determine the new state of the PSC Control Logic and what
   actions need to be taken.

   The new state information should be retained by the PSC Process
   Logic, while the requested action SHALL be sent to the PSC Message
   Generator (see subsection 3.1.4) to generate and transmit the proper
   PSC message to be transmitted to the remote end point of the
   protection domain.

3.1.4.  PSC Message Generator

   Based on the action output from the Process Logic this unit formats
   the PSC protocol message that is transmitted to the remote end point
   of the protection domain.  When the PSC information has changed,
   three PSC messages SHOULD be transmitted in quick succession, and



Bryant, et al.           Expires April 27, 2011                [Page 11]

Internet-Draft                 MPLS-TP LP                   October 2010


   subsequent messages should be transmitted continually at a lower
   rate.

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

3.1.5.  Wait-to-Restore (WTR) timer

   The WTR timer is used to delay reversion to Normal state when
   recovering from a failure condition on the working path and the
   protection domain is configured for revertive behavior.  The WTR may
   be in one of two states - either Running or Stopped.  The WTR timer
   MAY be started or stopped by the PSC Process Logic.

   If the WTR timer expires prior to being stopped it SHALL generate a
   WTR Expires local signal that shall be processed by the Local Request
   Logic.  If the WTR timer is running, sending a Stop command SHALL
   reset the timer but SHALL NOT generate a WTR Expires local signal.
   If the WTR timer is not running, a Stop command SHALL be ignored.

3.1.6.  PSC Control States

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

   It should be noted that when referring to the "transport" of the data
   traffic, in the following descriptions and later in the document that
   the data will be transmitted on both the working and the protection
   paths when using 1+1 protection, and on either the working or the
   protection path exclusively when using 1:1 protection.  When using
   1+1 protection, the receiving LER should select the proper
   transmission, according to the state of the protection domain.

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

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



Bryant, et al.           Expires April 27, 2011                [Page 12]

Internet-Draft                 MPLS-TP LP                   October 2010


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

   o  Protecting failure state - The working path has reported a
      failure/degrade condition and the user traffic is being
      transported (or selected) on the protection path.

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

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

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

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


4.  Protection state coordination (PSC) protocol

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

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

   This protocol is a single-phase protocol, as described above.  In the
   following subsections we describe the protocol messages that SHALL be



Bryant, et al.           Expires April 27, 2011                [Page 13]

Internet-Draft                 MPLS-TP LP                   October 2010


   used between the two end points of the protection domain.

4.1.  Transmission and acceptance of PSC control packets

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

   When the PSC information is changed due to a local input, three PSC
   messages SHOULD be transmitted as quickly as possible, to allow for
   rapid protection switching.  This set of three rapid messages allows
   for fast protection switching even if one or two of these packets are
   lost or corrupted.  When the PSC information changes due to a remote
   message there is no need for the aforementioned rapid transmission of
   three messages.  The exception (e.g. when the rapid tranmission is
   still required) is when going from WTR state to Normal state as a
   result of a remote NR message.

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

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

4.2.  Protocol format

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











Bryant, et al.           Expires April 27, 2011                [Page 14]

Internet-Draft                 MPLS-TP LP                   October 2010


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

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

   Where:

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

   o  The ACH TLV Header is described in [RFC5586]

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

4.2.1.  PSC Ver field

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

4.2.2.  PSC Request field

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

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

   o  (1101) Forced switch - indicates that the transmitting end point
      has switched traffic to the protection path as a result of an
      administrative command.  The Fpath field 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).

   o  (0110) Signal Fail - indicates that the transmitting end point has
      identified a signal fail condition on either the working or
      protection path.  The Fpath field SHALL identify the path that is
      reporting the failure condition (i.e. if protection path then



Bryant, et al.           Expires April 27, 2011                [Page 15]

Internet-Draft                 MPLS-TP LP                   October 2010


      Fpath set to 0 and if working path then Fpath set to 1), and the
      Path field SHALL indicate where the data traffic is being
      transported (i.e. if protection path is blocked then Path set to 0
      and if working path is blocked then Path set to 1).

   o  (0101) Signal Defect - indicates that that the transmitting end
      point has identified a degradation of the signal, or integrity of
      the packet transmission on either the working or protection path.
      The specifics for the method of identifying this degradation is
      out-of-scope for this document.  The details of the actions to be
      taken for this situation is left for future specification.

   o  (0100) Manual switch - indicates that the transmitting end point
      has switched traffic as a result of an administrative Manual
      Switch command.  The Fpath field SHALL indicate 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).

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

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

   o  (0000) No request - indicates that the transmitting end point has
      nothing to report, Fpath and Path fields SHALL be set to according
      to the state of the end point, see section 4.3.3 for detailed
      scenarios.

4.2.3.  Protection Type (PT)

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






Bryant, et al.           Expires April 27, 2011                [Page 16]

Internet-Draft                 MPLS-TP LP                   October 2010


   o  11: bidirectional switching using a permanent bridge

   o  10: bidirectional switching using a selector bridge

   o  01: unidirectional switching using a permanent bridge

   o  00: unidirectional switching using a selector bridge

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

4.2.4.  Revertive (R) field

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

   o  0 - non-revertive mode

   o  1 - revertive mode

4.2.5.  Fault path (FPath) field

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

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

   o  1: indicates that the anomaly condition is on the working path

   o  2-255: for future extensions

4.2.6.  Data path (Path) field

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





Bryant, et al.           Expires April 27, 2011                [Page 17]

Internet-Draft                 MPLS-TP LP                   October 2010


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

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

   o  2-255: for future extensions

4.3.  Principles of Operation

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

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

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


                        Figure 3: Protection domain

4.3.1.  Basic operation

   The purpose of the PSC protocol is to allow the end points of the
   protection domain to notify their peer of the status of the domain
   that is known at the end point and coordinate the transmission of the
   data traffic.  The current state of the end point is expressed in the
   values of the Request field [reflecting the local requests at that
   end point] and the Fpath field [reflecting knowledge of a blocked
   path].  The coordination between the end points is expressed by the
   value of the Path field [indicating where the data traffic is being
   transmitted].  The value of the Path field SHOULD be identical for
   both end points at any particular time.  The values of the Request
   and Fpath fields may not be identical between the two end points.In
   particular it should be noted that a remote message MAY not cause the
   end point to change the Request field that is being transmitted while
   it does affect the Path field (see details in the following
   subsections).

   The protocol is a single-phase protocol.  Single-phase implies that
   each end point notifies its peer of a change in the operation
   (switching to or from the protection path) and makes the switch



Bryant, et al.           Expires April 27, 2011                [Page 18]

Internet-Draft                 MPLS-TP LP                   October 2010


   without waiting for acknowledgement.

   The following subsections will identify the messages that SHALL be
   transmitted by the end point in different scenarios.  The messages
   are described as REQ(FP, P) - where REQ is the value of the Request
   field, FP is the value of the Fpath field, and P is the value of the
   Path field.  All examples assume a protection domain between LER-A
   and LER-Z with a single working path and single protection path (as
   shown in figure 3).  Again it should be noted that when using 1:1
   protection the data traffic will be transmitted exclusively on either
   the protection or working path, while when using 1+1 protection the
   traffic will be transmitted on both paths and the receiving LER
   should select the appropriate signal based on the state.  The text
   will refer to this transmission/selection as "transport" of the data
   traffic.

4.3.2.  Priority of inputs

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

   1.  Clear (Operator command)

   2.  Lockout of protection (Operator command)

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

   4.  Forced switch (Operator command)

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

   6.  Signal Degrade on working (OAM/Control Plane/Server Indication)

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

   8.  Manual switch (Operator command)

   9.  WTR expires (WTR Timer)

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




Bryant, et al.           Expires April 27, 2011                [Page 19]

Internet-Draft                 MPLS-TP LP                   October 2010


4.3.3.  Operation of PSC States

4.3.3.1.  Normal State

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

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

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

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

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

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

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

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

   o  All other local inputs SHOULD be ignored.

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

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





Bryant, et al.           Expires April 27, 2011                [Page 20]

Internet-Draft                 MPLS-TP LP                   October 2010


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

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

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

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

   o  All other remote messages SHOULD be ignored.

4.3.3.2.  Unavailable State

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

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

   When in unavailable state the data traffic is being transported on
   the working path and is not protected.  When the domain is in
   unavailable state the PSC messages may not get through and therefore
   the protection is more dependent on the local inputs rather than the
   remote messages (that may not be received).

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

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




Bryant, et al.           Expires April 27, 2011                [Page 21]

Internet-Draft                 MPLS-TP LP                   October 2010


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

   o  A local Clear SF in local Unavailable state due to a Signal Fail
      on the protection path and the Clear SF indicates that the
      protection path is now cleared, then the input SHALL cause the LER
      to go to Normal state and begin transmitting a NR(0,0) message.
      If the LER is in remote Unavailable state but is under a local SF
      condition, then the local Clear SF SHALL clear the SF local
      condition and the LER SHALL begin transmitting NR(0,0) messages,
      maintaining the remote Unavailable state.  In all other cases the
      local Clear SF SHOULD be ignored.

   o  A local Forced switch SHOULD be ignored by the PSC Process Logic.

   o  A local Signal Fail indication on the protection path SHALL cause
      the LER to remain in Unavailable state and begin transmission of a
      SF(0,0) message.

   o  All other local inputs SHOULD be ignored.

   If remote messages are being received over the protection path then
   they would have the following affect:

   o  A remote Lockout of protection message SHALL cause the LER to
      remain in Unavailable state, and continue transmission of the
      current message (either NR(0,0) or LO(0,0) or SF(0,0))

   o  A remote Signal Fail message that indicates that the failure is on
      the protection path SHALL cause the LER to remain in Unavailable
      state and continue transmission of the current message (either
      NR(0,0) or SF(0,0) or LO(0,0)).

   o  A remote No Request, when the LER is remote Unavailable state
      SHALL cause the LER to go into Normal state and begin transmission
      of a NR(0,0) message.  When in local Unavailable state, the
      message SHALL be ignored.

   o  All other remote messages SHOULD be ignored.

4.3.3.3.  Protecting administrative state

   In the protecting state the user data traffic is being transported on
   the protection path, while the working path is blocked due to an
   operator command, i.e.  Forced Switch or Manual Switch.

   The following describe the reaction to local input:



Bryant, et al.           Expires April 27, 2011                [Page 22]

Internet-Draft                 MPLS-TP LP                   October 2010


   o  A local Clear SHOULD be ignored if in remote Protecting state.  If
      in local Protecting administrative state then this input SHALL
      cause the LER to go into Normal state and begin transmitting a
      NR(0,0) message.

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

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

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

   o  A local Signal Fail indication on the working path SHOULD be
      filtered by the Local Request Logic if the protecting state was
      entered due to an active local Forced switch operator command.  If
      the protecting state is due to a remote Forced switch message,
      then this local indication SHOULD be filtered by the PSC Process
      Logic.  If the current state is due to a (local or remote) Manual
      switch operator command, it SHALL cause the LER to go into
      Protecting failure state and begin transmitting a SF(1,1) message.

   o  A local Clear SF when in remote Protecting administrative state
      SHOULD clear any local SF condition that may exist.  The LER SHALL
      stop transmitting the SF(1,1) message and begin transmitting an
      NR(0,1) message.

   o  A local Manual switch input SHALL be filtered by the Local Request
      Logic if there is an active local Forced switch.  If the
      protecting state is due to a remote Forced switch command, then
      this local indication SHOULD be filtered by the PSC Process Logic.
      If the current state is due to a (local or remote) Manual switch
      operator command, it SHALL cause the LER to remain in Protecting
      administrative state and begin transmission of a MS(1,1) message.

   o  All other local inputs SHOULD be ignored.

   While in Protecting administrative state the LER may receive and
   react as follows to remote PSC messages:

   o  A remote Lockout of protection message SHALL cause the LER to go
      into Unavailable state and begin transmitting a NR(0,0) message.
      It should be noted that this automatically cancels the current
      Forced switch or Manual switch command and data traffic is
      reverted to the working path.



Bryant, et al.           Expires April 27, 2011                [Page 23]

Internet-Draft                 MPLS-TP LP                   October 2010


   o  A remote Forced switch message SHOULD be ignored by the PSC
      Process Logic if there is an active local Forced switch operator
      command.  If the Protecting state is due to a remote Forced switch
      message then the LER SHALL remain in Protecting administrative
      state and continue transmission of the last message.  If the
      Protecting state is due to either a local or remote Manual switch
      then the LER SHALL remain in Protecting administrative state
      (updating the state information with the proper relevant
      information) and begin transmitting a NR(0,1) message.

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

   o  A remote Signal Fail message indicating a failure on the working
      path SHALL be ignored if there is an active local Forced switch
      command.  If the Protecting state is due to a local or remote
      Manual switch then the LER SHALL go to Protecting failure state
      and begin transmitting a NR(0,1) message.

   o  A remote Manual switch message SHALL be ignored by the PSC Process
      Logic if in Protecting state due to a local or remote Forced
      switch.  If in Protecting state due to a remote Manual switch then
      the LER SHALL remain in Protecting administrative state and
      continue transmitting the current message.  If in Protecting state
      due to an active local Manual switch then the LER SHALL remain in
      Protecting administrative state and continue transmission of the
      MS(1,1) message.

   o  A remote DNR(0,0) message SHALL be ignored if in Protecting state
      due to a local input.  If in Protecting state due to a remote
      message then the LER SHALL go to Do-not-revert state and begin
      transmitting a NR(0,0) message.

   o  A remote NR(0,0) message SHALL be ignored if in Protecting state
      due to a local input.  If in Protecting state due to a remote
      message then the LER SHALL go to Normal state and begin
      transmitting a NR(0,0) message.

   o  All other remote messages SHOULD be ignored.

4.3.3.4.  Protecting failure state

   When the protection mechanism has been triggered and the protection
   domain has performed a protection switch, the domain is in the
   protecting failure state.  In this state the normal data traffic is



Bryant, et al.           Expires April 27, 2011                [Page 24]

Internet-Draft                 MPLS-TP LP                   October 2010


   transported on the protection path.

   The following describe the reaction to local input:

   o  A local Clear SF SHOULD be ignored if in remote Protecting state.
      If the Clear SF indicates that the protection path is now cleared
      (but working is still in SF condition) then the indicateion SHOULD
      be ignored.  If in local Protecting failure state and the LER is
      configured for revertive behavior then this input SHALL cause the
      LER to go into Wait-to-restore state, start the WTR timer, and
      begin transmitting a WTR(0,1) message.  If in local Protecting
      failure state and the LER is configured for non-revertive behavior
      then this input SHALL cause the LER to go into Do-not-revert state
      and begin transmitting a DNR(0,1) message.

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

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

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

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

   o  All other local inputs SHOULD be ignored.

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

   o  A remote Lockout of protection message SHALL cause the LER to go
      into Unavailable state and if in protecting failure state due to a
      local SF condition then the LER SHALL begin transmitting a SF(1,0)
      message, otherwise it SHALL transmit a NR(0,0) message.  It should
      be noted that this may cause loss of user data since the working
      path is still in a failure condition.

   o  A remote Forced switch message SHALL cause the LER go into
      Protecting administrative state and if in protecting failure state
      due to a local SF condition the LER SHALL begin transmitting the
      SF(1,1) message, otherwise it SHALL begin transmitting NR(0,0).





Bryant, et al.           Expires April 27, 2011                [Page 25]

Internet-Draft                 MPLS-TP LP                   October 2010


   o  A remote Signal Fail message indicating a failure on the
      protection path SHALL cause the LER to go into Unavailable state
      and if in protecting failure state due to a local SF condition
      then the LER SHALL begin transmitting a SF(1,0) message, otherwise
      it SHALL begin transmitting NR(0,0) message.  It should be noted
      that this may cause loss of user data since the working path is
      still in a failure condition.

   o  If in Protecting state due to a remote message, a remote Wait-to-
      Restore message SHALL cause the LER to go into Wait-to-Restore
      state and continue transmission of the current message.

   o  If in Protecting state due to a remote message, a remote Do-not-
      revert message SHALL cause the LER to go into Do-not-revert state
      and continue transmission of the current message.

   o  All other remote messages SHOULD be ignored.

4.3.3.5.  Wait-to-restore state

   The Wait-to-Restore state is used by the PSC protocol to delay
   reverting to the normal state, when recovering from a failure
   condition on the working path, for the period of the WTR timer to
   allow the recovering failure to stabilize.  While in the Wait-to-
   Restore state the data traffic SHALL continue to be transported on
   the protection path.  The natural transition from the Wait-to-Restore
   state to Normal state will occur when the WTR timer expires.

   When in Wait-to-Restore state the following describe the reaction to
   local inputs:

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

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

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

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





Bryant, et al.           Expires April 27, 2011                [Page 26]

Internet-Draft                 MPLS-TP LP                   October 2010


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

   o  A local WTR expires input SHALL cause the LER to remain in Wait-
      to-Restore state and begin transmitting a NR(0,1) message.

   o  All other local inputs SHOULD be ignored.

   When in Wait-to-Restore state the following describe the reaction to
   remote messages:

   o  A remote Lockout of protection message SHALL cause the LER to Stop
      the WTR timer, go into Unavailable state, and begin transmitting a
      NR(0,0) message.

   o  A remote Forced switch message SHALL cause the LER to Stop the WTR
      timer, go into Protecting administrative state, and begin
      transmission of a NR(0,1) message.

   o  A remote Signal Fail message for the protection path SHALL cause
      the LER to Stop the WTR timer, go into Unavailable state, and
      begin transmission of a NR(0,0) message.

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

   o  A remote Manual switch message SHALL cause the LER to Stop the WTR
      timer, go into Protecting administrative state and begin
      transmission of a NR(0,1) message.

   o  If the WTR timer is running then a remote NR message SHALL be
      ignored.  If the WTR timer is no longer running then a remote NR
      message SHALL cause the LER to go into Normal state and begin
      transmitting a NR(0,0) message.

   o  All other remote messages SHOULD be ignored.

4.3.3.6.  Do-not-revert state

   Do-not-revert state is a continuation of the protecting state when
   the protection domain is configured for non-revertive behavior.
   While in Do-not-revert state, data traffic continues to be
   transported on the protection path until the administrator sends a
   command to revert to the Normal state.  It should be noted that there
   is a fundemental difference between this state and Normal - whereas
   Forced Switch in Normal state actually causes a switch in the



Bryant, et al.           Expires April 27, 2011                [Page 27]

Internet-Draft                 MPLS-TP LP                   October 2010


   transport path used, in Do-not-revert state the Forced switch just
   switches the state (to Protecting administrative state) but the
   traffic would continue to be transported on the protection path!  The
   command to revert back to Normal state could either be a Lockout of
   protection (followed be a Clear command), a Clear command, or a new
   form of the Manual switch command [note: This would also require some
   kind of agreement, although it seems to have been adopted by ITU-T in
   G.8031 for Ethernet].  The following description of operation is
   based on the Lockout/Clear option mentioned!

   When in Do-not-revert state the following describe the reaction to
   local input:

   o  A local Lockout of protection command SHALL cause the LER to go
      into Unavailable state and begin transmitting a LO(0,0) message.

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

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

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

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

   o  All other local inputs SHOULD be ignored.

   When in Do-not-revert state the following describe the reaction to
   remote messages:

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

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

   o  A remote Signal Fail message for the protection path SHALL cause
      the LER to go into Unavailable state and begin transmission of a
      NR(0,0) message.




Bryant, et al.           Expires April 27, 2011                [Page 28]

Internet-Draft                 MPLS-TP LP                   October 2010


   o  A remote Signal Fail message for the working path SHALL cause the
      LER to go into Protecting failure state, and begin transmission of
      a NR(0,1) message.

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

   o  All other remote messages SHOULD be ignored.


5.  IANA Considerations

   To be added in future version.


6.  Security Considerations

   To be added in future version.


7.  Acknowledgements

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


8.  References

8.1.  Normative References

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

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

8.2.  Informative References

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

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



Bryant, et al.           Expires April 27, 2011                [Page 29]

Internet-Draft                 MPLS-TP LP                   October 2010


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

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

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

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

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

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

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

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

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


Authors' Addresses

   Stewart Bryant (editor)
   Cisco
   United Kingdom

   Email: stbryant@cisco.com






Bryant, et al.           Expires April 27, 2011                [Page 30]

Internet-Draft                 MPLS-TP LP                   October 2010


   Eric Osborne
   Cisco
   United States

   Email: eosborne@cisco.com


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

   Email: nurit.sprecher@nsn.com


   Annamaria Fulignoli (editor)
   Ericsson
   Italy

   Phone:
   Email: annamaria.fulignoli@ericsson.com


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

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



















Bryant, et al.           Expires April 27, 2011                [Page 31]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/