GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6378

Internet Engineering Task Force (IETF) Y. Weingarten, Ed. Request for Comments: 6378 Nokia Siemens Networks Category: Standards Track S. Bryant ISSN: 2070-1721 E. Osborne

                                                                 Cisco
                                                           N. Sprecher
                                                Nokia Siemens Networks
                                                     A. Fulignoli, Ed.
                                                              Ericsson
                                                          October 2011
         MPLS Transport Profile (MPLS-TP) Linear Protection

Abstract

 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 Pseudowire Emulation Edge-to-Edge
 (PWE3) architectures to support the capabilities and functionalities
 of a packet transport network as defined by the ITU-T.
 This document addresses the functionality described in the MPLS-TP
 Survivability Framework document (RFC 6372) 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.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6378.

Weingarten, et al. Standards Track [Page 1] RFC 6378 MPLS-TP LP October 2011

Copyright Notice

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

Weingarten, et al. Standards Track [Page 2] RFC 6378 MPLS-TP LP October 2011

Table of Contents

 1. Introduction ....................................................4
    1.1. Protection Architectures ...................................4
    1.2. Scope of the Document ......................................5
 2. Conventions Used in This Document ...............................6
    2.1. Acronyms ...................................................6
    2.2. Definitions and Terminology ................................7
 3. Protection State Control Logic ..................................7
    3.1. Local Request Logic ........................................9
    3.2. Remote Requests ...........................................11
    3.3. PSC Control Logic .........................................12
    3.4. PSC Message Generator .....................................12
    3.5. Wait-to-Restore (WTR) Timer ...............................12
    3.6. PSC Control States ........................................13
         3.6.1. Local and Remote State .............................14
 4. Protection State Coordination (PSC) Protocol ...................14
    4.1. Transmission and Acceptance of PSC Control Packets ........15
    4.2. Protocol Format ...........................................16
         4.2.1. PSC Ver Field ......................................16
         4.2.2. PSC Request Field ..................................17
         4.2.3. Protection Type (PT) Field .........................18
         4.2.4. Revertive (R) Field ................................18
         4.2.5. Fault Path (FPath) Field ...........................19
         4.2.6. Data Path (Path) Field .............................19
         4.2.7. Additional TLV Information .........................19
    4.3. Principles of Operation ...................................20
         4.3.1. Basic Operation ....................................20
         4.3.2. Priority of Inputs .................................21
         4.3.3. Operation of PSC States ............................22
 5. IANA Considerations ............................................33
    5.1. Pseudowire Associated Channel Type ........................33
    5.2. PSC Request Field .........................................33
    5.3. Additional TLVs ...........................................34
 6. Security Considerations ........................................34
 7. Acknowledgements ...............................................35
 8. Contributing Authors ...........................................36
 9. References .....................................................37
    9.1. Normative References ......................................37
    9.2. Informative References ....................................37
 Appendix A. PSC State Machine Tables ..............................39
 Appendix B. Exercising the Protection Domain ......................44

Weingarten, et al. Standards Track [Page 3] RFC 6378 MPLS-TP LP October 2011

1. Introduction

 The MPLS Transport Profile (MPLS-TP) [RFC5921] 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 [RFC6372] 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
 [RFC6372].  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 resources of
 the protection path are 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 and that can operate between any pair of points
 within the network.
 As described in the Survivability Framework document [RFC6372],
 protection switching is applied to a protection domain.  For the
 purposes of this document, we define the protection domain of a
 point-to-point LSP as consisting of two Label Edge Routers (LERs) and
 the transport paths that connect them (see Figure 3).  For a point-
 to-multipoint 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 [RFC6372], a
 protection 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 protection paths by a permanent bridge at the
 source of the protection domain.  The sink of the protection domain

Weingarten, et al. Standards Track [Page 4] RFC 6378 MPLS-TP LP October 2011

 uses a selector to choose either the working or protection path from
 which to receive the traffic, based on 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 protection transport path is dedicated to
 the working transport path of a single service, and the traffic is
 only transmitted on either the working or the protection path, by
 using a selector 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 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 protection path among n services.  Again, the protection
 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 listed in [RFC6372]), may be sent on the protection path.  The
 switching action is similar to the 1:1 case where a selector is used
 at the source.  In cases where multiple working path services have
 triggered protection switching, it should be noted that some
 services, dependent upon their Service Level Agreement (SLA), may not
 be transmitted as a result of limited resources on the protection
 path.  In this architecture, there may be a need for coordination of
 the protection switching and 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 [RFC6372] 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
 verify that the traffic continues to be transported on a
 bidirectional LSP that is co-routed.
 The scope of this document 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-65 and 74-79) and described
 in [RFC6372].  The basic protocol is designed for use in conjunction

Weingarten, et al. Standards Track [Page 5] RFC 6378 MPLS-TP LP October 2011

 with the 1:1 protection architecture, bidirectional protection, and
 for 1+1 protection of a bidirectional path (for both unidirectional
 and bidirectional protection switching).  Applicability of the
 protocol for 1:1 unidirectional protection and for 1:n protection
 schemes may be documented in a future document and is out of scope
 for this 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].  The use of this protocol for point-to-
 multipoint paths is out of scope for this document and may be
 addressed in a future applicability 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].

2.1. Acronyms

 This document uses the following acronyms:
 CT      Channel Type
 DNR     Do-not-Revert
 FS      Forced Switch
 G-ACh   Generic Associated Channel
 LER     Label Edge Router
 LO      Lockout of protection
 LSR     Label Switching Router
 MEG     Managed Entity Group
 MEP     MEG End Point
 MPLS-TP Transport Profile for MPLS
 MS      Manual Switch
 NR      No Request
 OAM     Operations, Administration, and Maintenance
 PSC     Protection State Coordination Protocol
 S-PE    Switching Provider Edge
 SD      Signal Degrade
 SF      Signal Fail
 SFc     Clear Signal Fail
 SLA     Service Level Agreement

Weingarten, et al. Standards Track [Page 6] RFC 6378 MPLS-TP LP October 2011

 T-PE    Terminating Provider Edge
 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 [RFC6372].
 In addition, we use the term "LER" to refer to an MPLS-TP Network
 Element, whether it is an LSR, LER, T-PE, or S-PE.

3. Protection State Control Logic

 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 to
 transmit on the working or protection path for 1:1 protection or
 switching the selector to receive the traffic for either 1:1 or 1+1
 protection and transmit different protocol messages.
 The following figure shows the logical decomposition of the
 Protection State Control logic into different logical processing
 units.  These processing units are presented in subsequent
 subsections of this document.  This logical decomposition is only
 intended for descriptive purposes; any implementation that produces
 the external behavior described in Section 4 is acceptable.

Weingarten, et al. Standards Track [Page 7] RFC 6378 MPLS-TP LP October 2011

                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  Control   |------------+
             ------------>|      logic      |
                Request   +-----------------+
                                  |
                                  |  Action         +------------+
                                  +---------------->|  Message   |
                                                    | Generator  |
                                                    +------------+
                                                          |
                                               Output PSC | Message
                                                          V
               Figure 1: Protection State Control Logic
 Figure 1 describes the logical architecture of the protection
 switching control.  The Local Request logic unit accepts the triggers
 from the OAM, server layer, external operator commands, 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 Control logic, that will cross-check this local request with the
 information received from the far-end LER.  The PSC Control 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.

Weingarten, et al. Standards Track [Page 8] RFC 6378 MPLS-TP LP October 2011

3.1. Local Request Logic

 The Local Request logic processes input triggers from five sources.
 o  Operator command - the network operator may issue local
    administrative commands on the LER that trigger protection
    switching.  The commands Forced Switch, Manual Switch, Clear,
    Lockout of protection (defined in [RFC4427] as Forced switch-over,
    Manual switch-over, Clear, and Lockout of recovery LSP/span,
    respectively) MUST be supported.  An implementation MAY provide
    additional commands for operator use; providing that these
    commands do not introduce incompatible behavior between two
    arbitrary implementations, they are outside the scope of this
    document.  For example, an implementation could provide a command
    to manually set off a "WTR Expires" trigger (see below) input
    without waiting for the duration of the WTR timer; as this merely
    hastens the transition from one state to another and has no impact
    on the state machine itself, it would be perfectly valid.
 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; therefore, this
    input MAY be controlled by a hold-off timer that SHOULD be
    configurable by the network operator.  The hold-off timer is
    described in greater detail in [RFC6372].
 o  Control-Plane Indication - 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] and [RFC4873].
 o  OAM indication - OAM fault management or performance measurement
    tools may detect a failure or degrade condition on either the
    working or protection transport path, and this MUST 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 SHALL revert to the normal
    transmission of the user data traffic.
 The input from these sources SHOULD be retained persistently for the
 duration of the condition that initiated the trigger.  The Local
 Request logic processes these different input sources and, based on

Weingarten, et al. Standards Track [Page 9] RFC 6378 MPLS-TP LP October 2011

 the priorities between them (see Section 4.3.2), produces a current
 local request.  If more than one local input source generates a
 trigger, then the Local Request logic selects the higher priority
 indicator and ignores any lower priority indicator.  As a result,
 there is a single current local request that is passed to the PSC
 Control logic.  The different local requests that may be output from
 the Local Request logic are as follows:
 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 prevent
    switching data traffic to the protection path, for any purpose.
 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.  The
    determination and actions for SD are for further study and may
    appear in a separate document.  All references to SD input are
    placeholders for this extension.
 o  Clear Signal Fail (SFc) - if all of the server-layer, control-
    plane, or OAM indications are no longer indicating a failure
    condition on a path that was previously 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 the working path to the protection path.  This is
    only relevant if there is no currently active fault condition or
    operator command.
 o  WTR Expires (WTRExp) - generated by the WTR timer completing its
    period.
 If none of the input sources have generated any triggers, then the
 Local Request logic should generate a No Request (NR) as the current
 local request.

Weingarten, et al. Standards Track [Page 10] RFC 6378 MPLS-TP LP October 2011

3.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.
 Remote messages indicate the status of the transport path from the
 viewpoint of the far-end LER.  These messages may drive state changes
 on the local MEP, as defined later in this document.  When using 1+1
 unidirectional protection, an LER that receives a remote request
 SHALL NOT perform any protection switching action, i.e., will
 continue to select traffic from the working path and transport
 traffic on both paths.
 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 includes 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 includes 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.
 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 from the working path to
    the protection path.
 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.

Weingarten, et al. Standards Track [Page 11] RFC 6378 MPLS-TP LP October 2011

 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.3. PSC Control Logic

 The PSC Control logic accepts the following input:
 a.  the current local request output from the Local Request logic
     (see Section 3.1),
 b.  the remote request message from the remote end point of the
     transport path (see Section 3.2), 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 Control
 logic determines the new state of the PSC Control logic and what
 actions need to be taken.
 The new state information is retained by the PSC Control logic, while
 the requested action should be sent to the PSC Message Generator (see
 Section 3.4) to generate and transmit the proper PSC message to be
 transmitted to the remote end point of the protection domain.

3.4. PSC Message Generator

 Based on the action output from the PSC Control logic, this unit
 formats the PSC protocol message that is transmitted to the remote
 end point of the protection domain.  This message may either be the
 same as the previously transmitted message or change when the PSC
 control state (see Section 3.6) has changed.  The messages are
 transmitted as described in Section 4.1 of this document.

3.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 length
 of the timer may be provisioned by the operator.  The WTR may be in

Weingarten, et al. Standards Track [Page 12] RFC 6378 MPLS-TP LP October 2011

 one of two states: Running or Stopped.  The control of the WTR timer
 is managed by the PSC Control logic, by use of internal signals to
 start and stop, i.e., reset, the WTR timer.
 If the WTR timer expires prior to being stopped, it SHALL generate a
 WTR Expires local signal that is processed by the Local Request
 logic.  If the WTR timer is running, sending a Stop command SHALL
 reset the timer, and put the WTR timer into Stopped state, but SHALL
 NOT generate a WTR Expires local signal.  If the WTR timer is
 stopped, a Stop command SHALL be ignored.

3.6. PSC Control States

 The PSC Control logic should maintain information on the current
 state of the protection domain.  Information on the state of the
 domain is maintained by each LER within the protection domain.  The
 state information would include information of the current state of
 the protection domain, an indication of the cause for the current
 state (e.g., unavailable due to local LO command, protecting due to
 remote FS), and, for each LER, 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 protection domain states that are supported by the PSC Control
 logic are as follows:
 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.
 o  Unavailable state - The protection path is unavailable -- either
    as a result of an operator Lockout command or a failure 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.

Weingarten, et al. Standards Track [Page 13] RFC 6378 MPLS-TP LP October 2011

 o  Wait-to-Restore state - The protection domain is recovering from
    an 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 has recovered from a
    Protecting state, but the operator has configured the protection
    domain not to 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.3 for details on what actions are taken by the PSC
 Process logic for each state and the relevant input.

3.6.1. Local and Remote State

 An end point may be in a given state as a result of either a local
 input indicator (e.g., OAM, WTR timer) or as a result of receiving a
 PSC message from the far-end LER.  If the state is entered as a
 result of a local input indicator, then the state is considered a
 local state.  If the state is entered as a result of a PSC message,
 in the absence of a local input, then the state is considered a
 remote state.  This differentiation affects how the LER reacts to
 different inputs, as described in Section 4.3.3.  The PSC Control
 logic should maintain, together with the current protection domain
 state, an indication of whether this is a local or remote state, for
 this LER.
 In any instance where the LER has both a local and remote indicator
 that cause the protection domain to enter a particular state, then
 the state is considered a local state, regardless of the order in
 which the indicators were processed.  If, however, the LER has local
 and remote indicators that would cause the protection domain to enter
 different states, e.g., a local SF on working and a remote Lockout of
 protection message, then the input with the higher priority (see
 Section 4.3.2) will be the deciding factor and the source of that
 indicator will determine whether it is local or remote.  In the given
 example, the result would be a Remote Unavailable state transmitting
 PSC messages that indicate an SF condition on the working path and
 that the protection path is not being used to transport protected
 traffic (as described in the next section).

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
 protection path, is transmitting the data traffic in any given

Weingarten, et al. Standards Track [Page 14] RFC 6378 MPLS-TP LP October 2011

 situation.  When protection switching is triggered as described in
 Section 3, the end points must inform each other of the switchover
 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 switchover 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 will
 complete the switchover.
 This protocol is a single-phased protocol, as described above.  In
 the following subsections, we describe the protocol messages that are
 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 protection domain state is changed due to a local input,
 three PSC messages SHALL 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 protection domain
 state changes due to a remote message, the LER SHOULD send the three
 rapid messages.  However, when the LER transfers from WTR state to
 Normal state as a result of a remote NR message, the three rapid
 messages SHALL be transmitted.  After the transmission of the three
 rapid messages, the LER MUST retransmit the most recently transmitted
 PSC message on a continual basis.
 Both the default frequency of the three rapid messages as well as the
 default frequency of the continual message transmission SHALL be
 configurable by the operator.  The actual frequencies used MAY be
 configurable, at the time of establishment, for each individual
 protected LSP.  For management purposes, the operator SHOULD be able
 to retrieve the current default frequency values as well as the
 actual values for any specific LSP.  For protection switching within
 50 ms, it is RECOMMENDED that the default interval of the first three
 rapid PSC messages SHOULD be no longer than 3.3 ms.  Using this

Weingarten, et al. Standards Track [Page 15] RFC 6378 MPLS-TP LP October 2011

 frequency would allow the far-end to be guaranteed of receiving the
 trigger indication within 10 ms and completion of the switching
 operation within 50 ms.  Subsequent messages SHOULD be continuously
 transmitted with a default interval of 5 seconds.  The purpose of the
 continual messages is to verify that the PSC session is still alive.
 If no valid PSC message is received, over a period of several
 continual messages intervals, the last valid received message remains
 applicable.

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.  The actual message function SHALL be identified by the
 Request field of the ACH payload as described below.
 The channel type for the PSC messages SHALL be PSC-CT=0x0024.
 The following figure shows the format for the complete PSC message.
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0 0 1|Version|  Reserved     |          PSC-CT               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Ver|Request|PT |R|  Reserved1  |     FPath     |     Path      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         TLV Length            |          Reserved2            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                         Optional TLVs                         ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Figure 2: Format of PSC Packet with a G-ACh Header
 Where:
 o  Both Reserved1 and Reserved2 fields MUST be set to 0 and ignored
    upon receipt.
 o  The following subsections describe the remaining fields of the PSC
    payload.

4.2.1. PSC Ver Field

 The Ver field identifies the version of the protocol.  For this
 version of the document, the value SHALL be 1.

Weingarten, et al. Standards Track [Page 16] RFC 6378 MPLS-TP LP October 2011

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  (14) 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  (12) 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  (10) 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
    FPath is set to 0; if working path, then FPath is 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 is set
    to 0; if working path is blocked, then Path is set to 1).
 o  (7) Signal Degrade - indicates 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.  This
    request is presented here only as a placeholder.  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 are left for future specification.
 o  (5) Manual Switch - indicates that the transmitting end point has
    switched traffic to the protection path 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  (4) 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).

Weingarten, et al. Standards Track [Page 17] RFC 6378 MPLS-TP LP October 2011

 o  (1) Do-not-Revert - indicates that the transmitting end point has
    recovered from a failure/blocked condition, but due to the local
    settings, is requesting that the protection domain continues to
    transport the data as if it is in a protecting state, 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  (0) No Request - indicates that the transmitting end point has
    nothing to report, FPath and Path fields SHALL be set according to
    the transmission state of the end point, see Section 4.3.3 for
    detailed scenarios.
 All other values are for future extensions (to be administered by
 IANA) and SHALL be ignored upon receipt.

4.2.3. Protection Type (PT) Field

 The PT field indicates the currently configured protection
 architecture type, this SHOULD be validated to be consistent for both
 ends of the protection domain.  If an inconsistency is detected, then
 an alarm SHALL be sent to the management system.  The following are
 the possible values:
 o  3: bidirectional switching using a permanent bridge
 o  2: bidirectional switching using a selector bridge
 o  1: unidirectional switching using a permanent bridge
 o  0: for future extensions
 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.  The following are the possible
 values:

Weingarten, et al. Standards Track [Page 18] RFC 6378 MPLS-TP LP October 2011

 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, when a fault or command is indicated by the
 Request field to be in effect.  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 and SHALL be ignored by this version
    of the protocol.

4.2.6. Data Path (Path) Field

 The Path field indicates which data is being transported 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
 transported over the protection path.  The following are the possible
 values:
 o  0: indicates that the protection path is not transporting user
    data traffic (in 1:n architecture) or transporting redundant user
    data traffic (in 1+1 architecture).
 o  1: indicates that the protection path is transmitting user traffic
    replacing the use of the working path.
 o  2-255: for future extensions and SHALL be ignored by this version
    of the protocol.

4.2.7. Additional TLV Information

 It may be necessary for future applications of the protocol to
 include additional information for the proper processing of the
 requests.  For this purpose, we provide for optional additional
 information to be included in the PSC payload.  This information MUST
 include a header that indicates the total length (in bytes) of the
 additional information.

Weingarten, et al. Standards Track [Page 19] RFC 6378 MPLS-TP LP October 2011

 This information includes the following fields:
 o  TLV Length: indicates the number of bytes included in the optional
    TLV information.  For the basic PSC protocol operation described
    in this document, this value MUST be 0.
 o  Optional TLVs: this includes any additional information formatted
    as TLV units.  There are no TLV units defined for the basic PSC
    operation.

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 an end point of the
 protection domain to notify its 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 user data traffic is
 being transmitted).  Except during a protection switch, 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).

Weingarten, et al. Standards Track [Page 20] RFC 6378 MPLS-TP LP October 2011

 The protocol is a single-phased protocol.  "Single-phased" implies
 that each end point notifies its peer of a change in the operation
 (switching to or from the protection path) and makes the switch
 without waiting for acknowledgement.  As a side effect of using a
 single-phased protocol, there will be a short period during state
 transitions of one-sided triggers (e.g., operator commands or
 unidirectional SF) when one LER may be transporting/selecting the
 data from one transport path while the other end point is
 transporting/selecting from the other transport path.  This should
 become coordinated once the remote message is received and the far-
 end LER performs the protection switching operation.
 The following subsections will identify the messages that will 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; whereas 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.  For 1+1 unidirectional protection, the state of the
 selector will only be switched in reaction to a local message.  When
 receiving a remote message, a LER that is configured for 1+1
 unidirectional protection, will transfer to the new remote state;
 however, it will continue to select data according to the latest
 known local state.  When the LER transitions into the Normal state,
 the PSC Control Process SHALL check the persistent state of the local
 triggers to decide if it should further transition into a new state.

4.3.2. Priority of Inputs

 As noted above (in Section 3.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.   Forced Switch (operator command)

Weingarten, et al. Standards Track [Page 21] RFC 6378 MPLS-TP LP October 2011

 4.   Signal Fail on protection (OAM / control-plane / server
      indication)
 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)
 10.  No Request (default)
 As was noted above, the Local Request logic SHALL always select the
 local input indicator with the highest priority as the current local
 request, i.e., only the highest priority local input will be used to
 affect the control logic.  All local inputs with lower priority than
 this current local request will be ignored.
 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 protection input.  As mentioned in
 Section 3.6.1, the state transition is determined by the higher
 priority input between the highest priority local input and the
 remote message.  This also determines the classification of the state
 as local or remote.  The following subsections detail the transition
 based on the current state and the higher priority of these two
 inputs.

4.3.3. Operation of PSC States

 The following subsections present the operation of the different
 states defined in Section 3.6.  For each state, we define the
 reaction, i.e., the new state and the message to transmit, to each
 possible input -- either the highest priority local input or the PSC
 message from the remote LER.  It should be noted that the new state
 of the protection domain is described from the point of view of the
 LER that is reporting the state; therefore, the language of "the LER
 goes into a state" is referring to the LER reporting that the
 protection domain is now in this new state.  If the definition states
 to "ignore" the message, the intention is that the protection domain
 SHALL remain in its current state and the LER SHALL continue
 transmitting (as presented in Section 4.1) the current PSC message.

Weingarten, et al. Standards Track [Page 22] RFC 6378 MPLS-TP LP October 2011

 When a LER is in a remote state, i.e., state transition in reaction
 to a PSC message received from the far-end LER, and receives a new
 PSC message from the far-end LER that indicates a contradictory
 state, e.g., in remote Unavailable state receiving a remote FS(1,1)
 message, then the PSC Control logic SHALL reevaluate all inputs (both
 the local input and the remote message) as if the LER is in the
 Normal state.

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 protection path as well.  The receiving LER SHALL read
 the data from the working path.
 When the LER transitions into the Normal state, the PSC Control
 Process SHALL check the persistent state of the local triggers to
 decide if it should further transition into a new state.  If the
 result of this check is a transition into a new state, the LER SHALL
 transmit the corresponding message described in this section and
 SHALL use the data path corresponding to the new state.  When the
 protection domain remains in Normal state, the end point SHALL
 transmit an NR(0,0) message, indicating -- Nothing to report and data
 traffic is being transported on the working path.
 When the protection domain is in Normal state, the following
 transitions are relevant in reaction to a local input to the LER:
 o  A local Lockout of protection input SHALL cause the LER to go into
    local Unavailable state and begin transmission of an LO(0,0)
    message.
 o  A local Forced Switch input SHALL cause the LER to go into local
    Protecting administrative state and begin transmission of an
    FS(1,1) message.
 o  A local Signal Fail indication on the protection path SHALL cause
    the LER to go into local Unavailable state and begin transmission
    of an SF(0,0) message.
 o  A local Signal Fail indication on the working path SHALL cause the
    LER to go into local Protecting failure state and begin
    transmission of an SF(1,1) message.
 o  A local Manual Switch input SHALL cause the LER to go into local
    Protecting administrative state and begin transmission of an
    MS(1,1) message.

Weingarten, et al. Standards Track [Page 23] RFC 6378 MPLS-TP LP October 2011

 o  All other local inputs SHALL be ignored.
 In Normal state, remote messages would cause the following reaction
 from the LER:
 o  A remote Lockout of protection message SHALL cause the LER to go
    into remote Unavailable state, while continuing to transmit the
    NR(0,0) message.
 o  A remote Forced Switch message SHALL cause the LER to go into
    remote Protecting administrative state and begin transmitting an
    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 remote
    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 to go into remote Protecting
    failure state, and transmit an NR(0,1) message.
 o  A remote Manual Switch message SHALL cause the LER to go into
    remote Protecting administrative state, and transmit an NR(0,1)
    message.
 o  All other remote messages SHALL 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 detected on the
 protection path -- then the protection domain is in the Unavailable
 state.  In this state, the data traffic SHALL be transported on the
 working path and is not protected.  When the domain is in Unavailable
 state, the PSC messages may not get through: therefore, the
 protection is more dependent on the local inputs than the remote
 messages (that may not be received).
 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 continue to send the PSC messages over the
 protection path, as a result of this recovery.
 When the LER (assume LER-A) is in Unavailable state, the following
 transitions are relevant in reaction to a local input:

Weingarten, et al. Standards Track [Page 24] RFC 6378 MPLS-TP LP October 2011

 o  A local Clear input SHALL 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.
 o  A local Lockout of protection input SHALL cause the LER to remain
    in local Unavailable state and transmit an LO(0,0) message to the
    far-end LER (LER-Z).
 o  A local Clear SF of the protection path in local Unavailable state
    that is due to an SF on the protection path SHALL cause the LER to
    go to Normal state.  If the LER is in remote Unavailable state but
    has an active local SF condition, then the local Clear SF SHALL
    clear the SF local condition and the LER SHALL remain in remote
    Unavailable state and begin transmitting NR(0,0) messages.  In all
    other cases, the local Clear SF SHALL be ignored.
 o  A local Forced Switch SHALL be ignored by the PSC Control logic
    when in Unavailable state as a result of a (local or remote)
    Lockout of protection.  If in Unavailable state due to an SF on
    protection, then the FS SHALL cause the LER to go into local
    Protecting administrative state and begin transmitting an FS(1,1)
    message.  It should be noted that due to the unavailability of the
    protection path (i.e., due to the SF condition) that this FS may
    not be received by the far-end until the SF condition is cleared.
 o  A local Signal Fail on the protection path input when in local
    Unavailable state (by implication, this is due to a local SF on
    protection) SHALL cause the LER to remain in local Unavailable
    state and transmit an SF(0,0) message.
 o  A local Signal Fail on the working path input when in remote
    Unavailable state SHALL cause the LER to remain in remote
    Unavailable state and transmit an SF(1,0) message.
 o  All other local inputs SHALL be ignored.
 If remote messages are being received over the protection path, then
 they would have the following effect:
 o  A remote Lockout of protection message SHALL cause the LER to
    remain in Unavailable state (note that if the LER was previously
    in local Unavailable state due to a Signal Fail on the protection
    path, then it will now be in remote Unavailable state) and
    continue transmission of the current message (either NR(0,0) or
    LO(0,0) or SF(0,0)).

Weingarten, et al. Standards Track [Page 25] RFC 6378 MPLS-TP LP October 2011

 o  A remote Forced Switch message SHALL be ignored by the PSC Control
    logic when in Unavailable state as a result of a (local or remote)
    Lockout of protection.  If in Unavailable state due to a local or
    remote SF on protection, then the FS SHALL cause the LER to go
    into remote Protecting administrative state; if in Unavailable
    state due to local SF, begin transmitting an SF(0,1) message.
 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 in remote Unavailable state
    and there is no active local Signal Fail SHALL cause the LER to go
    into Normal state and continue transmission of the current
    message.  If there is a local Signal Fail on the protection path,
    the LER SHALL remain in local Unavailable state and transmit an
    SF(0,0) message.  If there is a local Signal Fail on the working
    path, the LER SHALL go into local Protecting Failure state and
    transmit an SF(1,1) message.  When in local Unavailable state, the
    remote message SHALL be ignored.
 o  All other remote messages SHALL be ignored.

4.3.3.3. Protecting Administrative State

 In the Protecting administrative state, the user data traffic SHALL
 be transported on the protection path, while the working path is
 blocked due to an operator command, i.e., Forced Switch or Manual
 Switch.  The difference between a local FS and local MS affects what
 local indicators may be received -- the Local Request logic will
 block any local SF when under the influence of a local FS, whereas
 the SF would override a local MS.  In general, an MS will be canceled
 in case of either a local or remote SF or LO condition.
 The following describe the reaction to local input:
 o  A local Clear SHALL be ignored if in remote Protecting
    administrative state.  If in local Protecting administrative
    state, then this input SHALL cause the LER to go into Normal
    state.
 o  A local Lockout of protection input SHALL cause the LER to go into
    local Unavailable state and begin transmission of an LO(0,0)
    message.
 o  A local Forced Switch input SHALL cause the LER to remain in local
    Protecting administrative state and transmit an FS(1,1) message.

Weingarten, et al. Standards Track [Page 26] RFC 6378 MPLS-TP LP October 2011

 o  A local Signal Fail indication on the protection path SHALL cause
    the LER to go into local Unavailable state and begin transmission
    of an SF(0,0) message, if the current state is due to a (local or
    remote) Manual Switch operator command.  If the LER is in (local
    or remote) Protecting administrative state due to an FS situation,
    then the SF on protection SHALL be ignored.
 o  A local Signal Fail indication on the working path SHALL cause the
    LER to go into local Protecting failure state and begin
    transmitting an SF(1,1) message, if the current state is due to a
    (local or remote) Manual Switch operator command.  If the LER is
    in remote Protecting administrative state due to a remote Forced
    Switch command, then this local indication SHALL cause the LER to
    remain in remote Protecting administrative state and transmit an
    SF(1,1) message.  If the LER is in local Protecting administrative
    state due to a local Forced Switch command, then this indication
    SHALL be ignored (i.e., the indication should have been blocked by
    the Local Request logic).
 o  A local Clear SF SHALL clear any local SF condition that may
    exist.  If in remote Protecting administrative state, the LER
    SHALL stop transmitting the SF(x,1) message and begin transmitting
    an NR(0,1) message.
 o  A local Manual Switch input SHALL be ignored if in remote
    Protecting administrative state due to a remote Forced Switch
    command.  If the current state is due to a (local or remote)
    Manual Switch operator command, it SHALL cause the LER to remain
    in local Protecting administrative state and transmit an MS(1,1)
    message.
 o  All other local inputs SHALL 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 remote Unavailable state and begin transmitting an 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 Forced Switch message SHALL be ignored by the PSC Process
    logic if there is an active local Forced Switch operator command.
    If the Protecting administrative state is due to a remote Forced
    Switch message, then the LER SHALL remain in remote Protecting
    administrative state and continue transmitting the last message.
    If the Protecting administrative state is due to either a local or

Weingarten, et al. Standards Track [Page 27] RFC 6378 MPLS-TP LP October 2011

    remote Manual Switch, then the LER SHALL remain in remote
    Protecting administrative state (updating the state information
    with the proper relevant information) and begin transmitting an
    NR(0,1) message.
 o  A remote Signal Fail message indicating a failure on the
    protection path SHALL cause the LER to go into remote Unavailable
    state and begin transmitting an NR(0,0) message, if the Protecting
    administrative state is due to a Manual Switch command.  It should
    be noted that this automatically cancels the current 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 remote Protecting failure
    state and begin transmitting an NR(0,1) message.
 o  A remote Manual Switch message SHALL be ignored by the PSC Control
    logic if in Protecting administrative state due to a local or
    remote Forced Switch.  If in Protecting administrative state due
    to a remote Manual Switch, then the LER SHALL remain in remote
    Protecting administrative state and continue transmitting the
    current message.  If in local Protecting administrative state due
    to an active Manual Switch, then the LER SHALL remain in local
    Protecting administrative state and continue transmission of the
    MS(1,1) message.
 o  A remote DNR(0,1) message SHALL be ignored if in local Protecting
    administrative state.  If in remote Protecting administrative
    state, then the LER SHALL go to Do-not-Revert state and continue
    transmitting the current message.
 o  A remote NR(0,0) message SHALL be ignored if in local Protecting
    administrative state.  If in remote Protecting administrative
    state and there is no active local Signal Fail indication, then
    the LER SHALL go to Normal state and begin transmitting an NR(0,0)
    message.  If there is a local Signal Fail on the working path, the
    LER SHALL go to local Protecting failure state and begin
    transmitting an SF(1,1) message.
 o  All other remote messages SHALL 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

Weingarten, et al. Standards Track [Page 28] RFC 6378 MPLS-TP LP October 2011

 SHALL be transported on the protection path.  When an LER is in this
 state, it implies that there either was a local SF condition or it
 received a remote SF PSC message.  The SF condition or message
 indicated that the failure is on the working path.
 This state may be overridden by the Unavailable state triggers, i.e.,
 Lockout of protection or SF on the protection path, or by issuing an
 FS operator command.  This state will be cleared when the SF
 condition is cleared.  In order to prevent flapping due to an
 intermittent fault, the LER SHOULD employ a Wait-to-Restore timer to
 delay return to Normal state until the network has stabilized (see
 Section 3.5).
 The following describe the reaction to local input:
 o  A local Clear SF SHALL be ignored if in remote Protecting failure
    state.  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 an LO(0,0) message.
 o  A local Forced Switch input SHALL cause the LER to go into
    Protecting administrative state and begin transmission of an
    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 an
    SF(0,0) message.
 o  A local Signal Fail indication on the working path SHALL cause the
    LER to remain in local Protecting failure state and transmit an
    SF(1,1) message.
 o  All other local inputs SHALL 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 remote Unavailable state, and if in local Protecting failure
    state, then the LER SHALL transmit an SF(1,0) message; otherwise,

Weingarten, et al. Standards Track [Page 29] RFC 6378 MPLS-TP LP October 2011

    it SHALL transmit an 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 remote
    Protecting administrative state, and if in local Protecting
    failure state, the LER SHALL transmit the SF(1,1) message;
    otherwise, it SHALL transmit NR(0,1).
 o  A remote Signal Fail message indicating a failure on the
    protection path SHALL cause the LER to go into remote Unavailable
    state, and if in local Protecting failure state, then the LER
    SHALL transmit an SF(1,0) message; otherwise, it SHALL transmit an
    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 remote Protecting failure state, a remote Wait-to-Restore
    message SHALL cause the LER to go into remote Wait-to-Restore
    state and continue transmission of the current message.
 o  If in remote Protecting failure state, a remote Do-not-Revert
    message SHALL cause the LER to go into remote Do-not-Revert state
    and continue transmission of the current message.
 o  If in remote Protecting failure state, a remote NR(0,0) SHALL
    cause the LER to go to Normal state.
 o  All other remote messages SHALL be ignored.

4.3.3.5. Wait-to-Restore State

 When recovering from a failure condition on the working path, the
 Wait-to-Restore state is used by the PSC protocol to delay reverting
 to the Normal state, 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 send the Stop command
    to the WTR timer, go into local Unavailable state, and begin
    transmitting an LO(0,0) message.

Weingarten, et al. Standards Track [Page 30] RFC 6378 MPLS-TP LP October 2011

 o  A local Forced Switch command SHALL send the Stop command to the
    WTR timer, go into local Protecting administrative state, and
    begin transmission of an FS(1,1) message.
 o  A local Signal Fail indication on the protection path SHALL send
    the Stop command to the WTR timer, go into local Unavailable
    state, and begin transmission of an SF(0,0) message.
 o  A local Signal Fail indication on the working path SHALL send the
    Stop command to the WTR timer, go into local Protecting failure
    state, and begin transmission of an SF(1,1) message.
 o  A local Manual Switch input SHALL send the Stop command to the WTR
    timer, go into local Protecting administrative state, and begin
    transmission of an MS(1,1) message.
 o  A local WTR Expires input SHALL cause the LER to remain in Wait-
    to-Restore state, and begin transmitting an NR(0,1) message.
 o  All other local inputs SHALL be ignored.
 When in Wait-to-Restore state, the following describe the reaction to
 remote messages:
 o  A remote Lockout of protection message SHALL send the Stop command
    to the WTR timer, go into remote Unavailable state, and begin
    transmitting an NR(0,0) message.
 o  A remote Forced Switch message SHALL send the Stop command to the
    WTR timer, go into remote Protecting administrative state, and
    begin transmission of an NR(0,1) message.
 o  A remote Signal Fail message for the protection path SHALL send
    the Stop command to the WTR timer, go into remote Unavailable
    state, and begin transmission of an NR(0,0) message.
 o  A remote Signal Fail message for the working path SHALL send the
    Stop command to the WTR timer, go into remote Protecting failure
    state, and begin transmission of an NR(0,1) message.
 o  A remote Manual Switch message SHALL send the Stop command to the
    WTR timer, go into remote Protecting administrative state, and
    begin transmission of an NR(0,1) message.
 o  If the WTR timer is running, then a remote NR message SHALL be
    ignored.  If the WTR timer is stopped, then a remote NR message
    SHALL cause the LER to go into Normal state.

Weingarten, et al. Standards Track [Page 31] RFC 6378 MPLS-TP LP October 2011

 o  All other remote messages SHALL be ignored.

4.3.3.6. Do-not-Revert State

 Do-not-Revert state is a continuation of the Protecting failure state
 when the protection domain is configured for non-revertive behavior.
 While in Do-not-Revert state, data traffic SHALL continue to be
 transported on the protection path until the administrator sends a
 command to revert to Normal state.  It should be noted that there is
 a fundamental difference between this state and Normal -- whereas
 Forced Switch in Normal state actually causes a switch in the
 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!  To
 revert back to Normal state, the administrator SHALL issue a Lockout
 of protection command followed by a Clear command.
 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 local Unavailable state and begin transmitting an LO(0,0)
    message.
 o  A local Forced Switch command SHALL cause the LER to go into local
    Protecting administrative state and begin transmission of an
    FS(1,1) message.
 o  A local Signal Fail indication on the protection path SHALL cause
    the LER to go into local Unavailable state and begin transmission
    of an SF(0,0) message.
 o  A local Signal Fail indication on the working path SHALL cause the
    LER to go into local Protecting failure state and begin
    transmission of an SF(1,1) message.
 o  A local Manual Switch input SHALL cause the LER to go into local
    Protecting administrative state and begin transmission of an
    MS(1,1) message.
 o  All other local inputs SHALL 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 remote Unavailable state and begin transmitting an NR(0,0)
    message.

Weingarten, et al. Standards Track [Page 32] RFC 6378 MPLS-TP LP October 2011

 o  A remote Forced Switch message SHALL cause the LER to go into
    remote Protecting administrative state and begin transmission of
    an NR(0,1) message.
 o  A remote Signal Fail message for the protection path SHALL cause
    the LER to go into remote Unavailable state and begin transmission
    of an NR(0,0) message.
 o  A remote Signal Fail message for the working path SHALL cause the
    LER to go into remote Protecting failure state and begin
    transmission of an NR(0,1) message.
 o  A remote Manual Switch message SHALL cause the LER to go into
    remote Protecting administrative state and begin transmission of
    an NR(0,1) message.
 o  All other remote messages SHALL be ignored.

5. IANA Considerations

5.1. Pseudowire Associated Channel Type

 In the "Pseudowire Name Spaces (PWE3)" registry, IANA maintains the
 "Pseudowire Associated Channel Types" registry.
 IANA has assigned a new code point from this registry.  The code
 point has been assigned from the code point space that requires "IETF
 Review" as follows:
 Registry:
  Value       Description       TLV Follows    Reference
 ------ ----------------------- ----------- ---------------
 0x0024     Protection State         no     [this document]
        Coordination Protocol -
         Channel Type (PSC-CT)

5.2. PSC Request Field

 IANA has created and maintains a new sub-registry within the
 "Multiprotocol Label Switching (MPLS) Operations, Administration, and
 Management (OAM) Parameters" registry called the "MPLS PSC Request
 Registry".  All code points within this registry shall be allocated
 according to the "Standards Action" procedure as specified in
 [RFC5226].
 The PSC Request Field is 4 bits, and the values have been allocated
 as follows:

Weingarten, et al. Standards Track [Page 33] RFC 6378 MPLS-TP LP October 2011

 Value Description              Reference
 ----- --------------------- ---------------
   0   No Request            [this document]
   1   Do-not-Revert         [this document]
 2 - 3 Unassigned
   4   Wait-to-Restore       [this document]
   5   Manual Switch         [this document]
   6   Unassigned
   7   Signal Degrade        [this document]
 8 - 9 Unassigned
   10  Signal Fail           [this document]
   11  Unassigned
   12  Forced Switch         [this document]
   13  Unassigned
   14  Lockout of protection [this document]
   15  Unassigned

5.3. Additional TLVs

 The IANA has created and maintains a new sub-registry within the
 "Multiprotocol Label Switching (MPLS) Operations, Administration, and
 Management (OAM) Parameters" registry called the "MPLS PSC TLV
 Registry".  All code points within this registry shall be allocated
 according to the "IETF Review" procedure as specified in [RFC5226].

6. Security Considerations

 MPLS-TP is a subset of MPLS and so builds upon many of the aspects of
 the security model of MPLS.  MPLS networks make the assumption that
 it is very hard to inject traffic into a network and equally hard to
 cause traffic to be directed outside the network.  The control-plane
 protocols utilize hop-by-hop security and assume a "chain-of-trust"
 model such that end-to-end control-plane security is not used.  For
 more information on the generic aspects of MPLS security, see
 [RFC5920].
 This document describes a protocol carried in the G-ACh [RFC5586],
 and so is dependent on the security of the G-ACh, itself.  The G-ACh
 is a generalization of the Associated Channel defined in [RFC4385].
 Thus, this document relies heavily on the security mechanisms
 provided for the Associated Channel and described in those two
 documents.
 A specific concern for the G-ACh is that is can be used to provide a
 covert channel.  This problem is wider than the scope of this
 document and does not need to be addressed here, but it should be
 noted that the channel provides end-to-end connectivity and SHOULD

Weingarten, et al. Standards Track [Page 34] RFC 6378 MPLS-TP LP October 2011

 NOT be policed by transit nodes.  Thus, there is no simple way of
 preventing any traffic being carried between in the G-ACh consenting
 nodes.
 A good discussion of the data-plane security of an associated channel
 may be found in [RFC5085].  That document also describes some
 mitigation techniques.
 It should be noted that the G-ACh is essentially connection oriented
 so injection or modification of control messages specified in this
 document require the subversion of a transit node.  Such subversion
 is generally considered hard in MPLS networks and impossible to
 protect against at the protocol level.  Management level techniques
 are more appropriate.
 However, a new concern for this document is the accidental corruption
 of messages (through faulty implementations or random corruption).
 The main concern is around the Request, FPath, and Path fields as a
 change to these fields would change the behavior of the peer end
 point.  Although this document does not define a way to avoid a
 change in network behavior upon receipt of a message indicating a
 change in protection status, the transition between states will
 converge on a known and stable behavior in the face of messages that
 do not match reality.

7. Acknowledgements

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

Weingarten, et al. Standards Track [Page 35] RFC 6378 MPLS-TP LP October 2011

8. Contributing Authors

 Hao Long
 Huawei Technologies Co., Ltd.
 F3 Building, Huawei Industrial Park
 Bantian, Shenzhen, China
 EMail: longhao@huawei.com
 Davide Chiara
 Ericsson
 Via Calda 5, 16152 Genova Italy
 EMail: davide.chiara@ericsson.com
 Dan Frost
 Cisco Systems
 EMail: danfrost@cisco.com
 Francesco Fondelli
 Ericsson
 via Moruzzi 1
 56100, Pisa
 Italy
 EMail: francesco.fondelli@ericsson.com

Weingarten, et al. Standards Track [Page 36] RFC 6378 MPLS-TP LP October 2011

9. References

9.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC4385]  Bryant, S., Swallow, G., Martini, L., and D. McPherson,
            "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
            Use over an MPLS PSN", RFC 4385, February 2006.
 [RFC5586]  Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
            Associated Channel", RFC 5586, June 2009.
 [RFC5654]  Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
            and S. Ueno, "Requirements of an MPLS Transport Profile",
            RFC 5654, September 2009.

9.2. Informative References

 [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
            Label Switching Architecture", RFC 3031, January 2001.
 [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
            Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
            Encoding", RFC 3032, January 2001.
 [RFC3945]  Mannie, E., "Generalized Multi-Protocol Label Switching
            (GMPLS) Architecture", RFC 3945, October 2004.
 [RFC3985]  Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
            Edge (PWE3) Architecture", RFC 3985, March 2005.
 [RFC4427]  Mannie, E. and D. Papadimitriou, "Recovery (Protection and
            Restoration) Terminology for Generalized Multi-Protocol
            Label Switching (GMPLS)", RFC 4427, March 2006.
 [RFC4872]  Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
            Extensions in Support of End-to-End Generalized Multi-
            Protocol Label Switching (GMPLS) Recovery", RFC 4872,
            May 2007.
 [RFC4873]  Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
            "GMPLS Segment Recovery", RFC 4873, May 2007.
 [RFC5085]  Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
            Connectivity Verification (VCCV): A Control Channel for
            Pseudowires", RFC 5085, December 2007.

Weingarten, et al. Standards Track [Page 37] RFC 6378 MPLS-TP LP October 2011

 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            May 2008.
 [RFC5659]  Bocci, M. and S. Bryant, "An Architecture for Multi-
            Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
            October 2009.
 [RFC5920]  Fang, L., "Security Framework for MPLS and GMPLS
            Networks", RFC 5920, July 2010.
 [RFC5921]  Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
            Berger, "A Framework for MPLS in Transport Networks",
            RFC 5921, July 2010.
 [RFC6372]  Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport
            Profile (MPLS-TP) Survivability Framework", RFC 6372,
            September 2011.

Weingarten, et al. Standards Track [Page 38] RFC 6378 MPLS-TP LP October 2011

Appendix A. PSC State Machine Tables

 The PSC state machine is described in Section 4.3.3.  This appendix
 provides the same information but in tabular format.  In the event of
 a mismatch between these tables and the text in Section 4.3.3, the
 text is authoritative.  Note that this appendix is intended to be a
 functional description, not an implementation specification.
 For the sake of clarity of the table, the six states listed in the
 text are split into 13 states.  The logic of the split is to
 differentiate between the different cases given in the conditional
 statements in the descriptions of each state in the text.  In
 addition, the remote and local states were split for the Unavailable,
 Protecting failure, and Protecting administrative states.
 There is only one table for the PSC state machine, but it is broken
 into two parts for space reasons.  The first part lists the 13
 possible states, the eight possible local inputs (that is, inputs
 that are generated by the node in question), and the action taken
 when a given input is received when the node is in a particular
 state.  The second part of the table lists the 13 possible states and
 the eight remote inputs (inputs that come from a node other than the
 one executing the state machine).
 There are 13 rows in the table, headers notwithstanding.  These rows
 are the 13 possible extended states in the state machine.
 The text in the first column is the current state.  Those states that
 have both source and cause are formatted as State:Cause:Source.  For
 example, the string UA:LO:L indicates that the current state is
 'Unavailable', that the cause of the current state is a Lockout of
 protection that was a local input.  In contrast, the state N simply
 is Normal; there is no need to track the cause for entry into Normal
 state.

Weingarten, et al. Standards Track [Page 39] RFC 6378 MPLS-TP LP October 2011

 The 13 extended states, as they appear in the table, are as follows:
 N       Normal state
 UA:LO:L Unavailable state due to local Lockout
 UA:P:L  Unavailable state due to local SF on protection path
 UA:LO:R Unavailable state due to remote Lockout of protection message
 UA:P:R  Unavailable state due to remote SF message on protection path
 PF:W:L  Protecting failure state due to local SF on working path
 PF:W:R  Protecting failure state due to remote SF message on working
         path
 PA:F:L  Protecting administrative state due to local FS operator
         command
 PA:M:L  Protecting administrative state due to local MS operator
         command
 PA:F:R  Protecting administrative state due to remote FS message
 PA:M:R  Protecting administrative state due to remote MS 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-machine table.
 State   REQ(FP,P)
 ------- ---------
 N       NR(0,0)
 UA:LO:L LO(0,0)
 UA:P:L  SF(0,0)
 UA:LO:R NR(0,0)
 UA:P:R  NR(0,0)
 PF:W:L  SF(1,1)
 PF:W:R  NR(0,1)
 PA:F:L  FS(1,1)
 PA:M:L  MS(1,1)
 PA:F:R  NR(0,1)
 PA:M:R  NR(0,1)
 WTR     WTR(0,1)
 DNR     DNR(0,1)

Weingarten, et al. Standards Track [Page 40] RFC 6378 MPLS-TP LP October 2011

 The top row in each table is the list of possible inputs.  The local
 inputs are as follows:
 NR     No Request
 OC     Operator Clear
 LO     Lockout of protection
 SF-P   Signal Fail on protection path
 SF-W   Signal Fail on working path
 FS     Forced Switch
 SFc    Clear Signal Fail
 MS     Manual Switch
 WTRExp WTR Expired
 and the remote inputs are as follows:
 LO   remote LO message
 SF-P remote SF message indicating protection path
 SF-W remote SF message indicating working path
 FS   remote FS message
 MS   remote MS message
 WTR  remote WTR message
 DNR  remote DNR message
 NR   remote NR message
 Section 4.3.3 refers to some states as 'remote' and some as 'local'.
 By definition, all states listed in the table of local sources are
 local states, and all states listed in the table of remote sources
 are remote states.  For example, Section 4.3.3.1 says "A local
 Lockout of protection input SHALL cause the LER to go into local
 Unavailable state".  As the trigger for this state change is a local
 one, 'local Unavailable state' is, by definition, displayed in the
 table of local sources.  Similarly, Section 4.3.3.1 also states that
 "A remote Lockout of protection message SHALL cause the LER to go
 into remote Unavailable state" means that the state represented in
 the Unavailable rows in the table of remote sources is by definition
 a remote Unavailable state.
 Each cell in the table below contains either a state, a footnote, or
 the letter 'i'. 'i' stands for Ignore, and is an indication to
 continue with the current behavior.  See Section 4.3.3.  The
 footnotes are listed below the table.

Weingarten, et al. Standards Track [Page 41] RFC 6378 MPLS-TP LP October 2011

 Part 1: Local input state machine
             | OC  | LO    | SF-P | FS   | SF-W | SFc  | MS   | WTRExp
     --------+-----+-------+------+------+------+------+------+-------
     N       | i   |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i    |PA:M:L| i
     UA:LO:L | N   | i     | i    | i    | i    | i    | i    | i
     UA:P:L  | i   |UA:LO:L| i    |PA:F:L| i    | [5]  | i    | i
     UA:LO:R | i   |UA:LO:L| [1]  | i    | [2]  | [6]  | i    | i
     UA:P:R  | i   |UA:LO:L|UA:P:L|PA:F:L| [3]  | [6]  | i    | i
     PF:W:L  | i   |UA:LO:L|UA:P:L|PA:F:L| i    | [7]  | i    | i
     PF:W:R  | i   |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i    | i    | i
     PA:F:L  | N   |UA:LO:L| i    | i    | i    | i    | i    | i
     PA:M:L  | N   |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i    | i    | i
     PA:F:R  | i   |UA:LO:L| i    |PA:F:L| [4]  | [8]  | i    | i
     PA:M:R  | i   |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i    |PA:M:L| i
     WTR     | i   |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i    |PA:M:L| [9]
     DNR     | i   |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i    |PA:M:L| i
 Part 2: Remote messages state machine
             | LO    | SF-P | FS   | SF-W | MS   | WTR  | DNR  | NR
     --------+-------+------+------+------+------+------+------+------
     N       |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i    | i    | i
     UA:LO:L | i     | i    | i    | i    | i    | i    | i    | i
     UA:P:L  | [10]  | i    | [19] | i    | i    | i    | i    | i
     UA:LO:R | i     | i    | i    | i    | i    | i    | i    | [16]
     UA:P:R  |UA:LO:R| i    |PA:F:R| i    | i    | i    | i    | [16]
     PF:W:L  | [11]  | [12] |PA:F:R| i    | i    | i    | i    | i
     PF:W:R  |UA:LO:R|UA:P:R|PA:F:R| i    | i    | [14] | [15] | N
     PA:F:L  |UA:LO:R| i    | i    | i    | i    | i    | i    | i
     PA:M:L  |UA:LO:R|UA:P:R|PA:F:R| [13] | i    | i    | i    | i
     PA:F:R  |UA:LO:R| i    | i    | i    | i    | i    | DNR  | [17]
     PA:M:R  |UA:LO:R|UA:P:R|PA:F:R| [13] | i    | i    | DNR  | N
     WTR     |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i    | i    | [18]
     DNR     |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i    | i    | i
 The following are the footnotes for the table:
 [1]   Remain in the current state (UA:LO:R) and transmit SF(0,0).
 [2]   Remain in the current state (UA:LO:R) and transmit SF(1,0).
 [3]   Remain in the current state (UA:P:R) and transmit SF(1,0).
 [4]   Remain in the current state (PA:F:R) and transmit SF(1,1).
 [5]   If the SF being cleared is SF-P, transition to N.  If it's
       SF-W, ignore the clear.

Weingarten, et al. Standards Track [Page 42] RFC 6378 MPLS-TP LP October 2011

 [6]   Remain in current state (UA:x:R), if the SFc corresponds to a
       previous SF, then begin transmitting NR(0,0).
 [7]   If domain configured for revertive behavior transition to WTR,
       else transition to DNR.
 [8]   Remain in PA:F:R and transmit NR(0,1).
 [9]   Remain in WTR, send NR(0,1).
 [10]  Transition to UA:LO:R continue sending SF(0,0).
 [11]  Transition to UA:LO:R and send SF(1,0).
 [12]  Transition to UA and send SF(1,0).
 [13]  Transition to PF:W:R and send NR(0,1).
 [14]  Transition to WTR state and continue to send the current
       message.
 [15]  Transition to DNR state and continue to send the current
       message.
 [16]  If the local input is SF-P, then transition to UA:P:L.  If the
       local input is SF-W, then transition to PF:W:L.  Else,
       transition to N state and continue to send the current message.
 [17]  If the local input is SF-W, then transition to PF:W:L.  Else,
       transition to N state and continue to send the current message.
 [18]  If the receiving LER's WTR timer is running, maintain current
       state and message.  If the WTR timer is stopped, transition to
       N.
 [19]  Transition to PA:F:R and send SF (0,1).

Weingarten, et al. Standards Track [Page 43] RFC 6378 MPLS-TP LP October 2011

Appendix B. Exercising the Protection Domain

 There is a requirement in [RFC5654] (number 84) that discusses a
 requirement to verify that the protection path is viable.  While the
 PSC protocol does not define a specific operation for this
 functionality, it is possible to perform this operation by combining
 operations of the PSC and other OAM functionalities.  One such
 possible combination would be to issue a Lockout of protection
 operation and then use the OAM function for diagnostic testing of the
 protection path.  Similarly, to test the paths when the working path
 is not active would involve performing a Forced Switch to protection
 and then perform the diagnostic function on either the working or
 protection path.

Weingarten, et al. Standards Track [Page 44] RFC 6378 MPLS-TP LP October 2011

Authors' Addresses

 Yaacov Weingarten (editor)
 Nokia Siemens Networks
 3 Hanagar St. Neve Ne'eman B
 Hod Hasharon  45241
 Israel
 EMail: yaacov.weingarten@nsn.com
 Stewart Bryant
 Cisco
 United Kingdom
 EMail: stbryant@cisco.com
 Eric Osborne
 Cisco
 United States
 EMail: eosborne@cisco.com
 Nurit Sprecher
 Nokia Siemens Networks
 3 Hanagar St. Neve Ne'eman B
 Hod Hasharon  45241
 Israel
 EMail: nurit.sprecher@nsn.com
 Annamaria Fulignoli (editor)
 Ericsson
 Via Moruzzi
 Pisa  56100
 Italy
 EMail: annamaria.fulignoli@ericsson.com

Weingarten, et al. Standards Track [Page 45]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6378.txt · Last modified: 2011/11/01 04:38 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki