Internet DRAFT - draft-ezy-mpls-1ton-protection

draft-ezy-mpls-1ton-protection






Network Working Group                                         E. Osborne
Internet-Draft                                                     Cisco
Intended status: Standards Track                                F. Zhang
Expires: December 28, 2012                                           ZTE
                                                           Y. Weingarten
                                                           June 26, 2012


                        MPLS-TP 1toN Protection
                 draft-ezy-mpls-1ton-protection-02.txt

Abstract

   As part of the Transport Profile for Multiprotocol Label Switching
   (MPLS-TP) there is a requirement to support 1:n linear protection for
   transport paths.  This requirement is elaborated on in the MPLS-TP
   Survivability Framework document [SurvivFwk].  The basic protocol for
   linear protection was specified in the MPLS-TP Linear Protection
   document [LinProt] but is limited to 1+1 and 1:1 protection.  This
   document extends the protocol defined there to address the additional
   functionality necessary to support scenarios of a single protection
   path preconfigured to provide protection of multiple transport paths
   between two joint endpoints.

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

Status of this Memo

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

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 28, 2012.




Osborne, et al.         Expires December 28, 2012               [Page 1]

Internet-Draft                 MPLS-TP LP                      June 2012


Copyright Notice

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

























Osborne, et al.         Expires December 28, 2012               [Page 2]

Internet-Draft                 MPLS-TP LP                      June 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  1:n Protection architecture  . . . . . . . . . . . . . . .  4
     1.2.  Locking operation  . . . . . . . . . . . . . . . . . . . .  6
     1.3.  Non-Locking  . . . . . . . . . . . . . . . . . . . . . . .  7
     1.4.  Path priority  . . . . . . . . . . . . . . . . . . . . . .  7
     1.5.  Preemption . . . . . . . . . . . . . . . . . . . . . . . .  8
     1.6.  Contributing authors . . . . . . . . . . . . . . . . . . .  8
   2.  Conventions used in this document  . . . . . . . . . . . . . .  8
     2.1.  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . .  9
     2.2.  Definitions and Terminology  . . . . . . . . . . . . . . .  9
   3.  Use cases and scenarios  . . . . . . . . . . . . . . . . . . .  9
     3.1.  Non-locking use case: Per-node label space . . . . . . . .  9
     3.2.  Locking use-case:  . . . . . . . . . . . . . . . . . . . . 10
     3.3.  PSC Scenarios  . . . . . . . . . . . . . . . . . . . . . . 12
       3.3.1.  Unidirectional failure cases . . . . . . . . . . . . . 13
       3.3.2.  Bidirectional fault scenarios  . . . . . . . . . . . . 15
       3.3.3.  Preemption scenarios . . . . . . . . . . . . . . . . . 17
   4.  Changes to PSC . . . . . . . . . . . . . . . . . . . . . . . . 22
     4.1.  PSC  . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     4.2.  Changes to PSC Payload . . . . . . . . . . . . . . . . . . 23
       4.2.1.  Locking (L) flag . . . . . . . . . . . . . . . . . . . 24
       4.2.2.  Fault path (FPath) field . . . . . . . . . . . . . . . 24
       4.2.3.  Data path (Path) field . . . . . . . . . . . . . . . . 24
     4.3.  Changes to PSC Operation . . . . . . . . . . . . . . . . . 25
       4.3.1.  Basic operation  . . . . . . . . . . . . . . . . . . . 25
       4.3.2.  Two-phased operation . . . . . . . . . . . . . . . . . 25
       4.3.3.  Acknowledge message  . . . . . . . . . . . . . . . . . 26
       4.3.4.  Wait for Acknowledge (WFA) timer . . . . . . . . . . . 27
       4.3.5.  Additional PSC State . . . . . . . . . . . . . . . . . 27
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 31
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 31
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 31
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 32
   Appendix A.  PSC state machine tables  . . . . . . . . . . . . . . 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36












Osborne, et al.         Expires December 28, 2012               [Page 3]

Internet-Draft                 MPLS-TP LP                      June 2012


1.  Introduction

   The MPLS Transport Profile (MPLS-TP) Requirements document [TPReq]
   includes requirements for the necessary survivability tools that are
   required for MPLS based transport networks.  Network survivability is
   the ability of a network to recover traffic delivery following
   failure, or degradation of network resources.  Requirement 67 lists
   various types of 1:n protection architectures that are required for
   MPLS-TP.  The MPLS-TP Survivability Framework [SurvivFwk] is a
   framework for survivability in MPLS-TP networks, and describes
   recovery elements, types, methods, and topological considerations,
   focusing on mechanisms for recovering MPLS-TP Label Switched Paths
   (LSPs).

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

   [LinProt] defines a Protection State Coordination (PSC) protocol that
   supports the different 1+1 and 1:1 architectures described in
   [SurvivFwk].  The PSC protocol is a single-phased protocol that
   allows the two endpoints of the protection domain to coordinate the
   protection switching operation when a switching condition is detected
   on the transport paths of the protection domain.

   This document extends the PSC protocol to allow it to support a
   protection domain that includes multiple working transport paths that
   are protected by a single protection transport path.  All of the
   working transport paths and the protection transport path share
   common end points.  The protection transport path is pre-allocated
   with resources to transport the traffic normally carried by any one
   of the working transport paths.  This is the architecture described
   in [SurvivFwk] as 1:n protection, and is the generalization of the
   1:1 protection architecture already supported by PSC.

1.1.  1:n Protection architecture

   Linear protection switching is a fully allocated survivability
   mechanism.  It is fully allocated in the sense that the route and
   bandwidth of the protection path is reserved for a set of working
   paths.  For 1:n protection the protection path is allocated to
   protect any one of n working paths between the two endpoints of the
   protection domain.



Osborne, et al.         Expires December 28, 2012               [Page 4]

Internet-Draft                 MPLS-TP LP                      June 2012


               +-----+                             +-----+
               |     |=============================|     |
               |LER-A|     Working Path #1         |LER-Z|
               |     |                             |     |
               |     |=============================|     |
               |     |     Working Path #2         |     |
               |     |                             |     |
               |     |=============================|     |
               |     |     Working Path #3         |     |
               |     |                             |     |
               |     |      ooo                    |     |
               |     |                             |     |
               |     |=============================|     |
               |     |     Working Path #N         |     |
               |     |                             |     |
               |     |    Protection Path          |     |
               |     |*****************************|     |
               |     |                             |     |
               +-----+                             +-----+

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


                      Figure 1: 1:n Protection domain

   Figure 1 shows a protection domain with N working transport paths and
   a single protection path.  In 1:n protection, the protection path may
   transport the traffic of only a single working path at any particular
   time.  The identity of the working path that is being protected must
   be communicated between the two endpoints.

   Unless otherwise specified, all examples will be based on the network
   topology in Figure 1, with the working paths referenced as Wi (for
   1<=i<=N) and the protection path referenced as P. The end-points of
   the protection domain will be referred to as LER-A and LER-Z.

   The different working paths may be disjoint at the intermediary
   points on the path between LER-A and LER-Z and may also have
   different resource requirements.  In addition, each of the working
   paths may be assigned a priority that could be used to decide which
   working path would be protected in cases of conflict (see more on
   this topic in Section 1.5).  It is usually advised to arrange these
   protection groups in a way that would minimize any potential conflict
   situation.

   1:n protection in MPLS supports two modes of operation - locking and
   non-locking.  Locking mirrors the behavior that is used by many
   transport protection mechanisms, and is necessary in some cases but



Osborne, et al.         Expires December 28, 2012               [Page 5]

Internet-Draft                 MPLS-TP LP                      June 2012


   may incur increased latency (and thus packet loss), as a result of
   prolonged switching time, in comparison to the non-locking case.
   Non-locking 1:n can be used in many MPLS networks and has far less
   packet loss as compared to locking, but must be used with care -
   since incorrect use of non-locking can lead to misconnectivity.

1.2.  Locking operation

   The high-level functionality of the locking operation mode of 1:n
   protection would follow the following basic steps:

   o  LER-A detects a unidirectional failure of W1 and stops sending
      traffic on W1.

   o  LER-A transmits a PSC SF message to LER-Z indicating that W1 has
      failed and its traffic should be redirected to P. No traffic is
      sent on P at this point.

   o  LER-Z receives the PSC message from LER-A and begins transmitting
      W1 traffic in P, and sends a PSC message to LER-A indicating that
      W1 is now being protected by P. LER-A receives the normal data
      traffic intended for W1 from P, LER-Z receives the W1 data traffic
      from P and also bridges W1 data traffic into P.

   o  LER-A receives the PSC message from LER-Z and begins transporting
      W1 traffic in P -- that is, LER-A bridges W1 into P.

   It should be clear from this description that no traffic is sent over
   P until LER-Z processes the PSC message from LER-A, and that traffic
   is only sent unidirectionally (Z->A) until LER-A processes the
   "reply" PSC message from LER-Z.  As the message processing time is
   expected to be dwarfed by the propagation delay between LER-A to
   LER-Z, it can be said that there is complete traffic loss between the
   endpoints for the duration of the one-way propagation delay from
   LER-A to LER-Z, and full bidirectional traffic flow is not fully
   restored until after 1xRTT of the protection path.

   This operation mode is referred to as "locking" because the sequence
   of processing the PSC messages includes periods where the protection
   path is locked from carrying protected traffic, while the two end-
   points verify that both are ready to process the W1 traffic that is
   received on P. More detailed information on this mode of operation
   will be supplied later in the document when considering different
   scenarios.







Osborne, et al.         Expires December 28, 2012               [Page 6]

Internet-Draft                 MPLS-TP LP                      June 2012


1.3.  Non-Locking

   In non-locking protection operation mode, LER-A switches data traffic
   onto P immediately upon failure detection.  This minimizes traffic
   loss, but at the cost of temporary asymmetry of packet flow.  At a
   high level, it looks like this:

   o  LER-A detects the failure of W1 and stops sending traffic on W1.

   o  LER-A immediately begins to transport W1's data traffic over the
      protection path P.

   o  Simultaneously LER-A transmitts a PSC message to LER-Z indicating
      that W1 has failed and is currently being protected in P.

   o  LER-Z receives the PSC message from LER-A, switches all W1 data
      traffic to P, and transmits a PSC message to LER-A indicating that
      W1 is now protected in P.

   o  LER-A receives the PSC message from LER-Z and needs to take no
      action, as the protection switch had already been completed.

   In the non-locking case, the packet loss between the endpoints is
   minimized.  Packet loss in the A->Z direction is only the failure
   detection time , which is assumed, for this document, to be
   negligible.  Packet loss in the Z->A direction is almost entirely the
   result of the one-way propagation delay of the PSC message from LER-A
   to LER-Z.  Assuming the transport path from A->Z has the same delay
   as that from Z->A, it can be said that the packet loss in the non-
   locking case is roughly half that of the locking case.

1.4.  Path priority

   As the 1:n architecture requires the ability for one working path to
   preempt the traffic of another in the event of multiple failures (see
   Section 1.5), there must be an indication of priority between the
   different working paths so that an implementation can decide whether
   a new failure should be allowed to preempt a protection switch
   already in place.  The priority for a given Working path is
   determined by the value used to represent that path in the FPath
   field of the PSC packet.  When comparing two Working paths to
   determine priority, the numerically lower FPath value is the winner.
   That is, Wi>Wj if i<j.

   As described in Section 4.2.2, valid FPath values for Working paths
   are in the range 1-128.





Osborne, et al.         Expires December 28, 2012               [Page 7]

Internet-Draft                 MPLS-TP LP                      June 2012


1.5.  Preemption

   Preemption occurs, for example, when the protection path is being
   used to transport traffic and is then required to transport traffic
   for a working path with higher priority.  At this point, the current
   traffic that is being transported on the protection path needs to be
   interrupted to allow the transport of the protected traffic.

   There are two basic scenarios for preemption of traffic -

   1.  When the protection path is used to transport "extra traffic".
       While this practice is discouraged by [TPReq], it is still not
       precluded.  When the protection domain triggers a protection
       switch, the extra traffic should be preempted to allow the
       transport of the protected traffic from the working path that
       triggered the switching operation.  The subsequent treatment of
       the interrupted service is out of the scope of this document.

   2.  When the protection path is transporting traffic from a working
       path and a second working path triggers a switching condition.
       This second trigger may either be a trigger with a higher
       priority (e.g.  FS after a SF) or because the operator had
       assigned a higher priority to the working path of the second
       trigger.  At this point, the traffic for the lower priority
       working path will be interrupted, and the higher priority traffic
       will be transmitted on the protection path.  The preempted
       traffic will only renew transmission, when either the working
       path recovers, or the higher priority traffic relinquishes
       control of the protection path.

1.6.  Contributing authors

   Nurit Sprecher (NSN)


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











Osborne, et al.         Expires December 28, 2012               [Page 8]

Internet-Draft                 MPLS-TP LP                      June 2012


2.1.  Acronyms

   This draft uses the following acronyms:

   Ack     Acknowledge
   DNR     Do not revert
   FS      Forced Switch
   LER     Label Edge Router
   LO      Lockout of protection
   MPLS-TP Transport Profile for MPLS
   MS      Manual Switch
   NR      No Request
   P2P     Point-to-point
   P2MP    Point-to-multipoint
   PSC     Protection State Coordination Protocol
   SD      Signal Degrade
   SF      Signal Fail
   WFA     Wait for Acknowledge
   WTR     Wait-to-Restore

2.2.  Definitions and Terminology

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


3.  Use cases and scenarios

   This section will present some use-cases and scenarios that should
   illucidate the use of PSC for 1:n protection.

3.1.  Non-locking use case: Per-node label space

   Non-locking protection can be used when the payload that is received
   from the protection path is unambiguous and can be properly forwarded
   without the need to explicitly establish selector and bridge
   configuration at the time of failure.  One example where this applies
   is when the endpoints of the protection domain are using per-platform
   label space [RFC3031].

   In per-node or per-platform label space, the LIB is established on a
   node such that it can properly switch any labeled packet regardless
   of input interface.

   Consider, as an example, the protection topology as shown in Figure 1
   with four working paths - W1, W2, W3, W4 and a single protection



Osborne, et al.         Expires December 28, 2012               [Page 9]

Internet-Draft                 MPLS-TP LP                      June 2012


   path, P, that connect between LER-A and LER-Z.  Each packet that
   transported from LER-A to LER-Z is labelled by LER-A depending upon
   the path that it is being transmitted over.  From there the packet
   will traverse the relevant path and have its label manipulated by the
   intermediate LSRs until it arrives at LER-Z, at which point, the LER
   will pop the label for the path used within the protection domain and
   process the next label down to determine how to forward the packet
   payload.  The following table gives the label assigned by LER-A and
   the one expected by LER-Z for each of the transport paths:

                +------+----------------+-----------------+
                | Path | Label at LER-A | Label for LER-Z |
                +------+----------------+-----------------+
                |  W1  |       100      |       105       |
                |  W2  |       200      |       205       |
                |  W3  |       300      |       305       |
                |  W4  |       400      |       405       |
                |   P  |       500      |       505       |
                +------+----------------+-----------------+

   If there is a pseudowire (PW) that needs to be carried over one of
   these transport paths between LER-A and LER-Z, whose label is
   allocated from the per-platform label space on both LER-A and LER-Z
   (e.g. label 888), then when a packet for this PW is transported over
   W2, the label stack that will be sent from LER-A will be [200|888|..]
   and it will arrive at LER-Z with a label stack [205|888|..].  If W2
   were to report a failure that triggers a protection switch and LER-A
   would redirect a packet for this PW to P, it would be transported
   with a label stack of [500|888|..] and be received by LER-Z with a
   label stack [505|888|..].  Since the PW label is drawn from per-node
   label space, when LER-Z pops the path label it will be able to
   process the PW label regardless of the transport path that was used
   between LER-A & LER-Z.

   Since the forwarding behavior is preestablished, there is no need to
   ensure that LER-A and LER-Z coordinate the bridge/selector functions
   as part of the protection protocol.  This is true for any underlying
   label assigned from per-node space.  The label can be allocated by
   LDP, MPLS VPNs, PWs, TE tunnels, or any other application.  As long
   as the label is preprogrammed in the receiving node's label space,
   coordination of the bridge/selection functions is unnecessary.

3.2.  Locking use-case:

   Locking protection must be used when the payload that is received on
   the protection path is ambiguous; that is, the switching behavior for
   the payload of the protection path must be established at the time of
   failure.  One such example where this applies is when the endpoints



Osborne, et al.         Expires December 28, 2012              [Page 10]

Internet-Draft                 MPLS-TP LP                      June 2012


   of the protection domain are using per-interface label space, where
   the Working and Protect LSPs are instantiated as interfaces.

   In per-interface label space, a node may use the same label value to
   represent different switching behaviors on different interfaces.  For
   example, the label value 100 when received on LSP W1 may be treated
   differently than the label value 100 when received on LSP W2.  Since
   either W1 or W2 may be protected in P, LSP P must ensure that it has
   the proper forwarding behavior defined for label 100.  Using the
   wrong forwarding behavior (e.g. programming P's label space with W1's
   entry for label 100 when P is protecting W2) is likely to lead to
   misconnectivity.

   Consider, as an example, the protection topology as shown in Figure 1
   and in Section 3.1.  There are four working paths - W1, W2, W3, W4 -
   and a single protection path, P, that connect between LER-A and
   LER-Z.  Section 3.1 shows a table with the receive labels [105, 205,
   305, 405, 505] at LER-Z, and those do not change.  What changes is
   the payload of those labels.  Section 3.1 gives the example of a PW
   drawn from global label space which uses the label 888 - this label
   is treated to the same forwarding behavior no matter which LSP is
   used to carry it from LER-A to LER-Z.

   In per-interface label space, each W-LSP has its own label space.
   For this example, consider a PW switched over W1 with the outgoing
   label 900.  Thus, the label stack when leaving LER-A is [100|900] and
   when arriving at LER-Z is [105|900].  There is also a PW defined over
   W2 which also uses label 900, but with a different forwarding
   behavior.  The per-interface label switching tables on LER-Z look
   like this:

       +-----------------+-------+--------------------------------+
       | Input Interface | Label |       Switching behavior       |
       +-----------------+-------+--------------------------------+
       |        W1       |  900  |   Switch to Access Circuit #1  |
       |        W2       |  900  |   Switch to Access Circuit #2  |
       |        W3       |  900  |   Switch to Access Circuit #3  |
       |        W4       |  900  |   Switch to Access Circuit #4  |
       |        P        |  900  | none defined (drop, log error) |
       +-----------------+-------+--------------------------------+

   The label space for P is established at the time of failure, using
   PSC.  When there is no failure, there is no switching behavior
   defined for the P LSP's contents.

   When the protection domain has determined that W2 has failed and
   needs to be switched, it coordinates this protection, using PSC,
   between LER-A and LER-Z.  Part of the coordination is to establish



Osborne, et al.         Expires December 28, 2012              [Page 11]

Internet-Draft                 MPLS-TP LP                      June 2012


   the proper receive behavior on LER-Z, i.e. the Switching behavior on
   the input interface for Label 900 to be "Switch to Access Circuit
   #2".  Whereas, if W1 fails and preempts W2, the switching behavior on
   LER-Z is changed be "Switch to Access Circuit #1".

   Clearly it is imperative that there be no misconnectivity.  This
   requirement means that there must be a "lock" on P established, such
   that there are no packets transmitted on an LSP until both ends agree
   on the switching behavior for that LSP.  The details of the behavior
   in the locking use cases is explored further in Section 3.3. of this
   document.

3.3.  PSC Scenarios

   This section discusses the message exchange necessary to perform both
   non-locking and locking PSC options for 1:n protection.  There are
   several examples presented here that attempt to cover all the
   combinations of failure and preemption, unidirectional and
   bidirectional protection for the two modes of operation.  It should
   be noted that this is a non-exhaustive set of scenarios, but were
   chosen to highlight the main features of the proposal.

   It is not the intent of this document to spell out all the
   combinations of preemption, directionality and locking behavior which
   can occur.  That is not how one builds a robust protocol.  This
   document spells out a state machine which reacts appropriately in all
   possible cases, and as part of that walks through some of the failure
   cases as examples.  PSC is, at its heart, a simple protocol.  A node
   is aware of both its local status and the status of the remote node,
   and transitions to the appropriate state and takes appropriate action
   based on the combination of these two states.  Preemption, which as
   noted is only relevant in 1:n, does not increase the complexity of
   the protocol.  The examples are detailed, but the behavior is quite
   simple.

   All of these examples assume a protection domain consisting of four
   working paths [W1, W2, W3, W4] with priority in decreasing order,
   i.e.  W1 > W2 etc.  There is a single protection path, P. These
   examples use the notation "B = x" to indicate the protect LSP whose
   contents are bridged into the protect LSP.  For example, if W3 has
   failed and is currently protected, B = 3.  If no protection is in
   place, B = n/a.  All examples end with the REQ(FPath, Path) and B
   values for each node in each example.

   The non-locking cases assume that both LER-A and LER-Z have
   preestablished per-node label spaces, as per the use case above.

   All cases assume that the time required to perform on-box operations



Osborne, et al.         Expires December 28, 2012              [Page 12]

Internet-Draft                 MPLS-TP LP                      June 2012


   such as bridging or selecting is instantaneous.  The one-way delay
   between nodes is abbreviated OWD, and the round trip time is RTT
   (i.e.  RTT = 2 x OWD).

3.3.1.  Unidirectional failure cases

   The examples in this section provide the message flow between LER-A
   and LER-Z for the scenario where a unidirectional fault is detected
   by LER-A on working path W1.  The message flow is described as a
   sequence along a timeline.

3.3.1.1.  Non-locking

   Considering the scenario of a protection domain operating in non-
   locking mode the following is the event timeline:

  +--------------------------------------------------------------------+
  |Time|              Event  Description           |LER-A PSC|LER-Z PSC|
  |    |                                           |  Bridge |  Bridge |
  +----+-------------------------------------------+---------+---------+
  | t0 | Traffic is being transported on W1, P is  | NR(0,0) | NR(0,0) |
  |    | not carrying any traffic.  Both LER-A and | B = n/a | B = n/a |
  |    | LER-Z transmitting PSC NR(0,0) message.   |         |         |
  +----+-------------------------------------------+---------+---------+
  | t1 | LER-A detects SF on W1, bridges W1 into P | SF(1,1) | NR(0,0) |
  |    | and sends SF(1,1). LER-A enters into WFA  |  B = 1  | B = n/a |
  |    | (Waiting for Acknowledgement) state. LER-A|         |         |
  |    | still selects the traffic from W1. This is|         |         |
  |    | admittedly of not much use when LER-A sees|         |         |
  |    | SF, may be useful when LER-A encounters a |         |         |
  |    | partial failure such as SD.               |         |         |
  +----+-------------------------------------------+---------+---------+
  | t2 | LER-Z receives SF(1,1).  LER-Z enters     | SF(1,1) | NR(0,1) |
  |    | PF:W:R state.  LER-Z switches W1 onto P   |  B = 1  |  B = 1  |
  |    | and sends SF(1,1).  At this point traffic |         |         |
  |    | for W1 is protected in both directions    |         |         |
  +----+-------------------------------------------+---------+---------+
  | t3 | LER-A receives SF(1,1), which it takes as | SF(1,1) | NR(0,1) |
  |    | an ACK from LER-Z.  LER-A transits from   |  B = 1  |  B = 1  |
  |    | WFA to PF:W:L state.  Switch is complete. |         |         |
  +----+-------------------------------------------+---------+---------+


                   Figure 2: Unidirectional non-locking

   Note: Between t1 and t2, LER-A transports the data traffic on P while
   LER-Z continues transporting it on W1, and there is temporary path
   asymmetry.  After t2, the data traffic is in P in both directions.



Osborne, et al.         Expires December 28, 2012              [Page 13]

Internet-Draft                 MPLS-TP LP                      June 2012


   In this case, LER-A loses traffic for the OWD time, as it does not
   receive any traffic from LER-Z on P until LER-Z bridges W1 into P.
   LER-Z does not lose any traffic due to the immediate bridging on
   LER-A.

3.3.1.2.  Locking

   When examining the similar scenario for a protection domain that is
   using the Locking mode of operation, we have the following time
   sequence:

  +--------------------------------------------------------------------+
  |Time|              Event  Description           |LER-A PSC|LER-Z PSC|
  |    |                                           |  Bridge |  Bridge |
  +----+-------------------------------------------+---------+---------+
  | t0 | Traffic is being transported on W1, P is  | NR(0,0) | NR(0,0) |
  |    | not carrying any traffic.  Both LER-A and | B = n/a | B = n/a |
  |    | LER-Z transmitting PSC NR(0,0) message.   |         |         |
  +----+-------------------------------------------+---------+---------+
  | t1 | LER-A detects SF on W1, LER-A enters into | SF(1,0) | NR(0,0) |
  |    | WFA  state and sends SF(1,1).  LER-A still| B = n/a  | B = n/a |
  |    | transports and  selects the traffic from  |         |         |
  |    | W1. This allows traffic to get through if |         |         |
  |    | the failure is truly unidirectional.      |         |         |
  +----+-------------------------------------------+---------+---------+
  | t2 | LER-Z receives SF(1,0).  LER-Z enters     | SF(1,0) | NR(0,1) |
  |    | PF:W:R state.  LER-Z bridges W1 into P and|  B = 1  |  B = 1  |
  |    | sends NR(0,1) but continues to select     |         |         |
  |    | traffic from W1                           |         |         |
  +----+-------------------------------------------+---------+---------+
  | t3 | LER-A receives NR(0,1), which it takes as | SF(1,1) | NR(0,1) |
  |    | an ACK from LER-Z.  LER-A completely      |  B = 1  |  B = 1  |
  |    | switches W1 traffic onto P. LER-A transits|         |         |
  |    | from WFA to PF:W:L state.  Switch complete|         |         |
  +----+-------------------------------------------+---------+---------+
  | t4 | LER-Z receives SF(1,1).  LER-Z selects W1 | SF(1,1) | NR(0,1) |
  |    | traffic from P and sends NR(0,1)          |  B = 1  |  B = 1  |
  +----+-------------------------------------------+---------+---------+


                     Figure 3: Unidirectional locking

   Note: At t1, LER-A stops sending traffic to LER-Z.  At t3, it
   resumes.  Since the majority of the time delay at both t1 and t2 is
   the one-way transmission delay between LER-A and LER-Z, there is a
   total of 1xRTT traffic loss at both endpoints.





Osborne, et al.         Expires December 28, 2012              [Page 14]

Internet-Draft                 MPLS-TP LP                      June 2012


3.3.2.  Bidirectional fault scenarios

   The examples above focused on unidirectional failures in order to
   illustrate the basic principles of 1:n protection.  However, most
   failures in carrier networks are bidirectional in nature.
   Bidirectionality includes not only the failure of both the tx and rx
   physical path (e.g. a fiber cut) but also a unidirectional failure
   made bidirectional by mechanisms outside of PSC such as CC-V or LDI.

   Both ends of a protection domain may not see the bidirectional
   failure at the same instant.  In the case of a true bidirectional
   fiber cut, the cut may be physically closer to one end of the domain
   than the other, and thus the end which is farther away takes longer
   to notice the failure.  This is referred to as "asymmetric
   notification delay" in this document.  Similarly, a unidirectional
   failure seen by one endpoint which triggers an LDI notification to
   the far endpoint will not be recognized by this far end until after
   ir has been noticed it at the near endpoint.

   There are a number of scenarios that constitute bidirectional
   failure, and the variety of triggers and notification delays mean
   that it is impossible to document them all here.  The scenario used
   in this case is of a true bidirectional failure, on working path W1,
   with asymmetric notification delay, as described above.  Both the
   case of Non-locking and Locking operation modes are presented.

   It is perhaps important to understand that a node, when reacting to a
   failure, simply reacts either to its local LSP status (e.g.  SF on
   the underlying fiber) or the status of the remote node (e.g. the
   remote node sending SF(x,y)).  A node neither knows nor cares whether
   the failure is bidirectional; it simply reacts to inputs to its local
   state machine.  It can easily be observed that there are no special
   states needed for unidirectional vs. bidirectional error handling.

3.3.2.1.  Non-Locking

   First we present the scenario when operating in non-locking mode:














Osborne, et al.         Expires December 28, 2012              [Page 15]

Internet-Draft                 MPLS-TP LP                      June 2012


  +--------------------------------------------------------------------+
  |Time|              Event  Description           |LER-A PSC|LER-Z PSC|
  |    |                                           |  Bridge |  Bridge |
  +----+-------------------------------------------+---------+---------+
  | t0 | Traffic is being transported on W1, P is  | NR(0,0) | NR(0,0) |
  |    | not carrying any traffic.  Both LER-A and | B = n/a | B = n/a |
  |    | LER-Z transmitting PSC NR(0,0) message.   |         |         |
  +----+-------------------------------------------+---------+---------+
  | t1 | LER-A detects SF on W1, bridges W1 into P | SF(1,1) | NR(0,0) |
  |    | and sends SF(1,1).  LER-A enters into WFA |  B = 1  | B = n/a |
  |    | state and continues to select the traffic |         |         |
  |    | from W1.                                  |         |         |
  +----+-------------------------------------------+---------+---------+
  | t2 | LER-Z detects the SF on W1.  LER-Z enters | SF(1,1) | SF(1,1) |
  |    | WFA state and bridges W1 into P and       |  B = 1  |  B = 1  |
  |    | transmitting SF(1,1). At this point       |         |         |
  |    | traffic for W1 is protected in both       |         |         |
  |    | directions, however the endpoints are     |         |         |
  |    | still not coordinated                     |         |         |
  +----+-------------------------------------------+---------+---------+
  | t3 | LER-Z receives the SF(1,1) from LER-A and | SF(1,1) | SF(1,1) |
  |    | considers it an Ack and transits from WFA |  B = 1  |  B = 1  |
  |    | to PF:W:L state                           |         |         |
  +----+-------------------------------------------+---------+---------+
  | t4 | LER-A receives SF(1,1), which it takes as | SF(1,1) | SF(1,1) |
  |    | an Ack from LER-Z and transits from WFA   |  B = 1  |  B = 1  |
  |    | to PF:W:L state.  Switch is complete.     |         |         |
  +----+-------------------------------------------+---------+---------+


                    Figure 4: Bidirectional non-locking

   It is perhaps instructive to note that the only differences between
   the unidirectional non-locking and bidirectional non-locking
   scenarios are the trigger at t2 which causes Z to send SF(1,1) and
   the state Z finally enters (PF:W:L rather than PF:W:R).  All other
   actions before and after this point are identical between the two
   cases.

3.3.2.2.  Locking

   We now follow the scenario for the locking mode of operation:









Osborne, et al.         Expires December 28, 2012              [Page 16]

Internet-Draft                 MPLS-TP LP                      June 2012


  +--------------------------------------------------------------------+
  |Time|              Event  Description           |LER-A PSC|LER-Z PSC|
  |    |                                           |  Bridge |  Bridge |
  +----+-------------------------------------------+---------+---------+
  | t0 | Traffic is being transported on W1, P is  | NR(0,0) | NR(0,0) |
  |    | not carrying any traffic.  Both LER-A and | B = n/a | B = n/a |
  |    | LER-Z transmitting PSC NR(0,0) message.   |         |         |
  +----+-------------------------------------------+---------+---------+
  | t1 | LER-A detects SF on W1 and sends SF(1,0). | SF(1,0) | NR(0,0) |
  |    | LER-A enters into WFA continues to bridge | B = n/a | B = n/a |
  |    | and select the traffic from W1.  This     |         |         |
  |    | allows traffic to get through if the      |         |         |
  |    | failure is really unidirectional.         |         |         |
  +----+-------------------------------------------+---------+---------+
  | t2 | LER-Z detects the SF on W1.  LER-Z enters | SF(1,0) | SF(1,0) |
  |    | WFA state and continues to bridge and     | B = n/a | B = n/a |
  |    | select traffic from W1 while transmitting |         |         |
  |    | SF(1,0).                                  |         |         |
  +----+-------------------------------------------+---------+---------+
  | t3 | LER-Z receives the SF(1,0) from LER-A and | SF(1,0) | SF(1,1) |
  |    | bridges traffic from W1 to P remaining in | B = n/a |  B = 1  |
  |    | WFA state now transmitting a SF(1,1)      |         |         |
  +----+-------------------------------------------+---------+---------+
  | t4 | LER-A receives the SF(1,0) from LER-Z and | SF(1,1) | SF(1,1) |
  |    | bridges traffic from W1 to P remaining in |  B = 1  |  B = 1  |
  |    | WFA state now transmitting a SF(1,1)      |         |         |
  +----+-------------------------------------------+---------+---------+
  | t5 | LER-A receives the SF(1,1) from LER-Z and | SF(1,1) | SF(1,1) |
  |    | considers it an Ack and transits from WFA |  B = 1  |  B = 1  |
  |    | to PF:W:L state                           |         |         |
  +----+-------------------------------------------+---------+---------+
  | t6 | LER-Z receives SF(1,1), which it takes as | SF(1,1) | SF(1,1) |
  |    | an Ack from LER-A and transits from WFA   |  B = 1  |  B = 1  |
  |    | to PF:W:L state.  Switch is complete.     |         |         |
  +----+-------------------------------------------+---------+---------+


                      Figure 5: Bidirectional locking

   As with non-locking, the major difference between the unidirectional
   and bidirectional scenarios of this failure are the alarm which
   causes LER-Z to take action and the final state LER-Z enters as a
   result.

3.3.3.  Preemption scenarios

   In addition to a bidirectional failure, it is also necessary to
   consider preemption.  When protecting n entities e.g [W1, W2, W3] it



Osborne, et al.         Expires December 28, 2012              [Page 17]

Internet-Draft                 MPLS-TP LP                      June 2012


   is possible for multiple working LSPs to simultaneously fail.
   Consider the case where LSP W1 fails and starts to use the protection
   LSP.  After this failure, LSP W2 fails before W1 has been restored.
   If W2 is of a lower relative priority than W1, there is no
   preemption.  However, if W2 has a higher priority than W1, when W2
   fails it preempts W1 from the protection LSP.  Preemption is not an
   issue in 1:1 or 1+1, as with only a single working LSP there's
   nothing to preempt.

   There are multiple scenarios of preemption depending on where the
   failures were detected.  In addition to the combinations of failure
   directionality and preemption, it is also necessary to consider how
   these combinations behave in both the locking and non-locking modes
   of operation.

   First consider, the two flavors of preemption due to multiple
   unidirectional failures.

   The difference between Locking and Non-Locking is that in Non-Locking
   a node can continue to send traffic on the P-LSP during the
   preemption process.  The P-LSP contents may momentarily disagree (A
   may send W1 on P, Z may send W2 on P) but in the non-locking case
   there is no risk of misconnectivity as explained in the previous
   discussion.  For this reason, the identity of the path that the
   endpoints are selecting incoming traffic from are irrelevant.  In a
   sense there is no selector; each node is able to properly process
   arbitrary data on the P-LSP.

   However, WFA state is still necessary in order to ensure that the
   endpoints converge on the identity of the working path whose traffic
   is being transported on the P-LSP.  Failure to converge is a problem
   that should be flagged to the operator.

   The scenarios start after the two endpoints have converged on
   protecting a unidirectional SF condition that was detected on W2,
   when a new SF condition is detected on W1 (with higher priority):

3.3.3.1.  Unidirectional non-locking

   First, consider the event sequence for unidirectional faults in a
   domain in non-locking mode:










Osborne, et al.         Expires December 28, 2012              [Page 18]

Internet-Draft                 MPLS-TP LP                      June 2012


  +--------------------------------------------------------------------+
  |Time|              Event  Description           |LER-A PSC|LER-Z PSC|
  |    |                                           |  Bridge |  Bridge |
  +----+-------------------------------------------+---------+---------+
  | t0 | Traffic from W2 is being transported on P | SF(2,2) | NR(0,2) |
  |    | and both endpoints are coordinated        |  B = 2  |  B = 2  |
  +----+-------------------------------------------+---------+---------+
  | t1 | LER-A detects SF on W1 and sends SF(1,1). | SF(1,1) | NR(0,2) |
  |    | LER-A enters into WFA, blocks the W2      |  B = 1  |  B = 2  |
  |    | traffic and begins transporting W1 traffic|         |         |
  |    | on P. (Since W1 has higher priority)      |         |         |
  +----+-------------------------------------------+---------+---------+
  | t2 | LER-Z receives the SF(1,1) from LER-A and | SF(1,1) | NR(0,1) |
  |    | bridges traffic from W1 to P remaining in |  B = 1  |  B = 1  |
  |    | PF:W:R now transmitting a NR(0,1)         |         |         |
  +----+-------------------------------------------+---------+---------+
  | t3 | LER-A receives the NR(0,1) from LER-Z and | SF(1,1) | NR(0,1) |
  |    | considers it an Ack and transits from WFA |  B = 1  |  B = 1  |
  |    | to PF:W:L state.  Coordination complete   |         |         |
  +----+-------------------------------------------+---------+---------+


              Figure 6: Preemption unidirectional non-locking

   As mentioned, in steady state LER-A is sending SF(2,2) and LER-Z is
   sending NR(0,2).  If LER-A detects an SF on W1, W1 must preempt W2 in
   its use of the protection LSP.  What the network subsequently does
   with W2 is outside the scope of PSC, but likely recovery actions may
   include rerouting W2, alerting W2's clients as to the unprotected
   failure status of W2, and so forth.

3.3.3.2.  Unidirectional locking

   In locking operation mode, when A detects an SF on W1, it needs to
   alert the far-end, LER-Z, that the W2 traffic must be preempted.
   LER-A does this by indicating an SF on the higher priority LSP and by
   emptying the protection LSP.  The following table presents the
   sequence for this scenario (we include the indication of the working
   path that is expected by each endpoint to be on the protection path,
   shown as "S = n")











Osborne, et al.         Expires December 28, 2012              [Page 19]

Internet-Draft                 MPLS-TP LP                      June 2012


  +--------------------------------------------------------------------+
  |Time|              Event  Description           |LER-A PSC|LER-Z PSC|
  |    |                                           |  Bridge |  Bridge |
  |    |                                           |Selector | Selector|
  +----+-------------------------------------------+---------+---------+
  | t0 | Traffic from W2 is being transported on P | SF(2,2) | NR(0,2) |
  |    | and both endpoints are coordinated        |  B = 2  |  B = 2  |
  |    |                                           |  S = 2  |  S = 2  |
  +----+-------------------------------------------+---------+---------+
  | t1 | LER-A detects SF on W1 and sends SF(1,0). | SF(1,0) | NR(0,2) |
  |    | LER-A enters into WFA blocks all traffic  | B = n/a |  B = 2  |
  |    | on the protection path                    | S = n/a |  S = 2  |
  +----+-------------------------------------------+---------+---------+
  | t2 | LER-Z receives the SF(1,0) from LER-A and | SF(1,0) | NR(0,1) |
  |    | bridges traffic from W1 to P (higher      | B = n/a |  B = 1  |
  |    | priority), and begins transmitting NR(0,1)| S = n/a |  S = 2  |
  |    | At this point W1 traffic is flowing Z->A  |         |         |
  |    | but not A->Z                              |         |         |
  +----+-------------------------------------------+---------+---------+
  | t3 | LER-A receives NR(0,1) from LER-Z and     | SF(1,1) | NR(0,1) |
  |    | considers it an Ack and transits from WFA |  B = 1  |  B = 1  |
  |    | to PF:W:L state and transmits SF(1,1)     |  S = 1  |  S = 2  |
  +----+-------------------------------------------+---------+---------+
  | t4 | LER-Z receives SF(1,1), and begins        | SF(1,1) | NR(0,1) |
  |    | selecting the protected traffic as W1 data|  B = 1  |  B = 1  |
  |    | Switch is complete.                       |  S = 1  |  S = 1  |
  +----+-------------------------------------------+---------+---------+


                Figure 7: Preemption unidirectional locking

   Traffic loss is asymmetric.  Loss A->Z starts at t1 and ends at t4,
   roughly 1.5xRTT.  Loss Z->A starts at t1 and ends at t3, roughly
   0.5xRTT.

3.3.3.3.  Bidirectional non-locking

   Looking, similarly, at the implications of preemption on the basic
   scenarios of bidirectional faults in multiple working paths.  Both of
   the operating modes, i.e. non-locking and locking, are presented.
   The scenarios begin at the point where W2 traffic is being
   transported on the protection path in a coordinated fashion, when a
   SF is detected by both endpoints of the 1:n protection domain.  W1
   traffic has a higher priority than that of W2 traffic and, therefore,
   will preempt the current protected traffic.

   The following presents the scenario in non-locking operation:




Osborne, et al.         Expires December 28, 2012              [Page 20]

Internet-Draft                 MPLS-TP LP                      June 2012


  +--------------------------------------------------------------------+
  |Time|              Event  Description           |LER-A PSC|LER-Z PSC|
  |    |                                           |  Bridge |  Bridge |
  +----+-------------------------------------------+---------+---------+
  | t0 | Traffic from W2 is being transported on P | SF(2,2) | NR(0,2) |
  |    | and both endpoints are coordinated        |  B = 2  |  B = 2  |
  +----+-------------------------------------------+---------+---------+
  | t1 | LER-A detects SF on W1, bridges W1 into P | SF(1,1) | NR(0,2) |
  |    | and sends SF(1,1).  LER-A enters into WFA |  B = 1  |  B = 2  |
  |    | state and continues to select the         |         |         |
  |    | protected traffic from P that is for W2.  |         |         |
  +----+-------------------------------------------+---------+---------+
  | t2 | LER-Z detects the SF on W1.  LER-Z enters | SF(1,1) | SF(1,1) |
  |    | WFA state and bridges W1 into P and       |  B = 1  |  B = 1  |
  |    | transmitting SF(1,1). At this point       |         |         |
  |    | traffic for W1 is protected in both       |         |         |
  |    | directions, however the endpoints are     |         |         |
  |    | still not coordinated                     |         |         |
  +----+-------------------------------------------+---------+---------+
  | t3 | LER-Z receives the SF(1,1) from LER-A and | SF(1,1) | SF(1,1) |
  |    | considers it an Ack and transits from WFA |  B = 1  |  B = 1  |
  |    | to PF:W:L state                           |         |         |
  +----+-------------------------------------------+---------+---------+
  | t4 | LER-A receives SF(1,1), which it takes as | SF(1,1) | SF(1,1) |
  |    | an Ack from LER-Z and transits from WFA   |  B = 1  |  B = 1  |
  |    | to PF:W:L state.  Switch is complete.     |         |         |
  +----+-------------------------------------------+---------+---------+


              Figure 8: Preemption bidirectional non-locking

3.3.3.4.  Bidirectional locking

   When considering the locking mode of operation, we must consider that
   the protection path, P, must be cleared of all traffic during the
   transition of traffic caused by preemption.  The bidirectional case
   will be similar to the scenario for a unidirectional fault with the
   major difference being the final state of the two endpoints.  The
   following would be the sequence of events:












Osborne, et al.         Expires December 28, 2012              [Page 21]

Internet-Draft                 MPLS-TP LP                      June 2012


  +--------------------------------------------------------------------+
  |Time|              Event  Description           |LER-A PSC|LER-Z PSC|
  |    |                                           |  Bridge |  Bridge |
  |    |                                           |Selector | Selector|
  +----+-------------------------------------------+---------+---------+
  | t0 | Traffic from W2 is being transported on P | SF(2,2) | NR(0,2) |
  |    | and both endpoints are coordinated        |  B = 2  |  B = 2  |
  |    |                                           |  S = 2  |  S = 2  |
  +----+-------------------------------------------+---------+---------+
  | t1 | LER-A detects SF on W1 and sends SF(1,0). | SF(1,0) | NR(0,2) |
  |    | LER-A enters into WFA blocks all traffic  | B = n/a |  B = 2  |
  |    | on the protection path                    | S = n/a |  S = 2  |
  +----+-------------------------------------------+---------+---------+
  | t2 | LER-Z detects the SF on W1.  LER-Z enters | SF(1,0) | SF(1,0) |
  |    | WFA state and blocks all traffic on the   | B = n/a | B = n/a |
  |    | protection path while transmitting SF(1,0)| S = n/a | S = n/a |
  +----+-------------------------------------------+---------+---------+
  | t3 | LER-Z receives the SF(1,0) from LER-A and | SF(1,0) | SF(1,1) |
  |    | bridges traffic from W1 to P (higher      | B = n/a |  B = 1  |
  |    | priority)  At this point W1 traffic is    | S = n/a | S = n/a |
  |    | flowing Z->A but not A->Z                 |         |         |
  +----+-------------------------------------------+---------+---------+
  | t4 | LER-A receives NR(0,1) from LER-Z and     | SF(1,1) | SF(1,1) |
  |    | considers it an Ack and transits from WFA |  B = 1  |  B = 1  |
  |    | to PF:W:L state                           |  S = 1  | S = n/a |
  +----+-------------------------------------------+---------+---------+
  | t5 | LER-Z receives SF(1,1), and begins        | SF(1,1) | SF(1,1) |
  |    | selecting the protected traffic as W1 data|  B = 1  |  B = 1  |
  |    | Switch is complete.                       |  S = 1  |  S = 1  |
  +----+-------------------------------------------+---------+---------+


                Figure 9: Preemption bidirectional locking


4.  Changes to PSC

   The Protection State Coordination protocol (PSC) is defined in
   [LinProt].  This includes both the format of the G-ACh based message
   as well as a description of the operations and the state transition
   logic of the protocol.  The extension to cover 1:n protection
   includes changes to both aspects of PSC.

   The changes to the message structure, include both the addition of
   new information and extension of the semantics of some of the
   existing fields of the message.  These changes will be described in
   Section 4.2.




Osborne, et al.         Expires December 28, 2012              [Page 22]

Internet-Draft                 MPLS-TP LP                      June 2012


   The changes relative to the behavior of the base PSC protocol will be
   described in Section 4.3.

4.1.  PSC

   Base PSC (as defined in [LinProt] is a single-phased protocol, i.e.
   the endpoints perform protection switching without waiting for
   acknowledgement from the far end LER.  The protocol messages are
   transmitted using the G-ACh and the format is described in Figure 10.

        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 = 0x0024         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Ver|Request|PT |R|  Reserved1  |     FPath     |     Path      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         TLV Length            |         Reserved2             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                         Optional TLVs                         ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   In regards to the G-ACh Header no changes are suggested in the
   extensions for 1:n protection, i.e., the channel type field will
   continue to use the PSC-CT value defined in [LinProt].  The fields
   from the PSC payload which are affected by this document are the Ver
   field, the Reserved1 field, and the Fpath and Path fields.

4.2.  Changes to PSC Payload

   In order to support 1:n protection there is a need to make one small
   change to the format of the PSC payload (see Figure 11).  In
   particular, we have added a new flag (L), taken from the Reserved1
   space, to whether the protection domain is locking or non-locking.
   In addition, the semantics of the FPath and Path field are adjusted
   to indicate an index of the multiple working paths.  The details of
   these changes are supplied in the following subsections.

   Due to the significance of these changes, the value of the Ver field
   (in the PSC payload) for 1:n protection domain MUST be set to 2.









Osborne, et al.         Expires December 28, 2012              [Page 23]

Internet-Draft                 MPLS-TP LP                      June 2012


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Ver|Request|PT |R|L| Reserved1 |     FPath     |     Path      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         TLV Length            |         Reserved2             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                         Optional TLVs                         ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 11: Format of 1:n PSC message payload

4.2.1.  Locking (L) flag

   The Locking flag is used to indicate that the end-point is configured
   for Locking mode (see Section 1.2).

   If the value is 1 then the protection-domain is using the locking
   mode

   The Locking flag must be the same on both ends; if the two endpoints
   of a protection domain have different L-flag settings, this MUST
   raise an error to the network operator

4.2.2.  Fault path (FPath) field

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

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

   o  1-128: indicates that the anomaly condition is on a working path
      whose index is indicated.

   o  129-255: for future extensions or experimental use.

4.2.3.  Data path (Path) field

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






Osborne, et al.         Expires December 28, 2012              [Page 24]

Internet-Draft                 MPLS-TP LP                      June 2012


   o  0: indicates that the protection path is not transporting user
      data traffic.

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

   o  129-255: for future extensions or experimental use.

4.3.  Changes to PSC Operation

   In all of the following subsections, assume a protection domain
   between LER-A and LER-Z, using working paths 1-N and the protection
   path as shown in figure 1.

   A basic premise of this protection architecture is that both
   endpoints of the protection domain are configured to associate the
   indices of the working paths with the proper LSP identifiers.  If
   this condition is not met then the protection scheme will cause
   inconsistencies in traffic transmission.

4.3.1.  Basic operation

   Protection of the N working paths is based on the operational
   principles outlined in [LinProt] and will employ the same basic
   Protection State Coordination Protocol (PSC) outlined in that
   document.  However, as can be expected, due to certain basic
   differences in the architecture of the protection domain, a small set
   of differences in operation are necessary.  The following sub-
   sections will highlight these differences and explain their effects
   on the PSC state machine.

4.3.2.  Two-phased operation

   PSC, as presented in [LinProt] is a single-phased protocol.  This
   means that when an endpoint receives a trigger to perform a
   protection switch, the LER switches traffic and then notifies the far
   end of the switch, without waiting for acknowledgement.  When
   addressing the situation in a 1:n protection domain, the endpoint
   that receives the trigger must first verify that the protection path
   is available to transmit the protected traffic.  This may involve
   interrupting the traffic that is currently being transmitted on the
   protection path by both endpoints.

   In general, after the LER has detected a trigger for protection
   switching, e.g. a FS operator command, or a SF indication for one of
   the working paths, the LER SHALL transmit the appropriate PSC message
   as described in [LinProt] with the following changes:




Osborne, et al.         Expires December 28, 2012              [Page 25]

Internet-Draft                 MPLS-TP LP                      June 2012


   o  If the protection domain is currently in either Protecting
      administrative or Protecting failure state, then the endpoint
      SHALL verify that the new trigger has a higher priority than the
      currently protected traffic.  If the new trigger has a lower
      priority then it MUST be ignored.

   o  The PSC message SHALL set the FPath value to the index of the
      working path that generated the trigger.  The Path value SHOULD be
      set to 0, unless the protection path was previously transporting
      traffic from another working path (as indicated by the value of
      the Path field.)

   o  If the protection path is currently transporting protected traffic
      and the protection domain is operating in locking mode, then the
      endpoint SHALL block all traffic of the protected working path.

   o  The endpoint SHALL transit to WFA state (see below).

   o  Upon reception of the switching PSC message, the far end LER SHALL
      verify that the received request is of higher priority than the
      known current traffic on the protection path, and if so SHALL
      interrupt the current traffic on the protection path, perform the
      switch to the requested protected traffic, and send a PSC message
      with the Path field set to the index of the current protected
      working path.

   o  Upon reception of the PSC message, the initiating LER SHALL verify
      that the Path field is set to the index of the working path of the
      highest priority.  If the Path field matches the highest priority
      path the LER SHALL perform the protection switch and transmit the
      appropriate PSC message, with the FPath field indicating the index
      of the working path that triggered the protection switch and the
      Path field set to the index of the working path whose traffic is
      being transported on the protection path.

4.3.3.  Acknowledge message

   As stated above, before performing a protection switch the endpoint
   that detected a switching trigger MUST wait for an Acknowledge
   message prior to performing the switch.  There are two types of
   message that will be considered as an Acknowledge message:

   1.  A reply message with the Request field reflecting the state of
       the far end, and the Path field set to the index of the working
       path that triggered the switching condition.  For example, if
       there is a Forced Switch command detected by LER-Z on working
       path W4, then LER-Z will have sent an FS(4,0) message to LER-A.
       Then when LER-Z receives a message such as NR(0,4)Ack this should



Osborne, et al.         Expires December 28, 2012              [Page 26]

Internet-Draft                 MPLS-TP LP                      June 2012


       be considered acknowledgement of the switching and that the
       protection path is available to switch the traffic from working
       path W4.

   2.  A remote message with the same Request field and FPath field as
       that transmitted by the LER in the WFA state.  For example, if
       there is a bidirectional Signal fault detected by LER-A on
       working path W4, then LER-A will enter WFA state and transmit a
       SF(4,0) message.  When it receives the SF(4,0) message from
       LER-Z, that has also detected the SF condition, it should be
       considered an acknowledgement of the switching and that the
       protection path is available to switch the traffic from working
       path W2.

4.3.4.  Wait for Acknowledge (WFA) timer

   The protection system MUST include a timer called the Wait for
   Acknowledge (WFA) timer that SHALL be started when the LER enters WFA
   state and reset when the Acknowledge message is received.  The length
   of the WFA timer SHOULD be configured to allow protection switching
   within the normal time constraints.  The WFA timer will expire only
   if no Acknowledge message was recieved by the LER in WFA state.  The
   WFA Expires local input should have a priority just below that of the
   WTRExpires signal.

4.3.5.  Additional PSC State

   As described above and demonstrated in the scenarios in Section 3.3,
   there is a need, in some scenarios, for the endpoint that is
   reporting on a trigger for protection-switching to delay the actual
   switchover until an acknowledge is received from the far end LER.  In
   order to facilitate this wait period it is necessary to define a new
   PSC State - Wait for Acknowledge (WFA) state.  WFA is used in both
   the Locking and Non-Locking cases.  It is more essential to the
   Locking mode of operation, as agreement is the mechanism to establish
   and release the lock on the protection LSP.  However, it is necessary
   for the Non-Locking mode as a persistent disagreement on the contents
   of the protection LSP indicates an error in the network devices and
   WFA is the method used to detect this error.

   In the locking mode, WFA comes into play when a failed LSP preempts
   another LSP.  This is highlighted in the scenarios presented in
   Figure 7 & Figure 9.

   When a working path is preempted, the protection domain must
   transition the contents of the protecting path from the preempted
   working path to the preempting working path.  In the locking case,
   the protecting path must temporarily be blocked (that is, nothing is



Osborne, et al.         Expires December 28, 2012              [Page 27]

Internet-Draft                 MPLS-TP LP                      June 2012


   being protected) in order to ensure that there is no misconnectivity.
   In the case where W1 preempts W2, the contents of the protection path
   transitions from transporting the W2 to not carrying any traffic
   before beginning to transport W1 traffic.

   The following sub-section will describe the actions to be taken when
   an LER is in the WFA state.

4.3.5.1.   Wait for Acknowledge (WFA) State

   An LER will enter the Wait for Acknowledge state before transitioning
   into a protection state, i.e. either Protecting administrative or
   Protecting failure state.  The LER SHALL remain in this state until
   either receiving an Acknowledge message, or until a WFA timer
   expires.  Normally, the Acknowledge message will be a remote PSC
   input.  The following describe how the LER, in WFA state, should
   react to a new local input:

   o  A local Clear SHALL cause the LER to go into Normal state if the
      LER is in WFA state due to either a FS or MS trigger and transmit
      an NR(0,0) PSC message.  If the LER is in WFA state due to a SF
      trigger then the local Clear SHALL be ignored.

   o  A local LO SHALL cause the LER to go into Unavailable state and
      begin to transmit LO(x, 0) [where x indicates the index of the
      working path that triggered the WFA state].

   o  A local FS SHALL cause the LER to remain in WFA state and transmit
      the FS(x, 0) message [where x indicates the index of the protected
      working path].  If the LER is in WFA state due to a FS from a
      different working path, then the working path with the higher
      priority SHALL be the protected working path.  If the LER is in
      WFA state due to any other switching trigger, then the working
      path that is identified in this FS will be the protected working
      path.

   o  A local SF SHALL cause the LER to remain in WFA state.  If the LER
      is in WFA state due to an existing FS trigger, then ignore the
      local SF and continue to transmit the FS(x, 0) PSC message.  If
      the LER is in WFA state due to an existing SF trigger then
      transmit the SF(x, 0) PSC message [where x indicates the index of
      protected working path, i.e. the highest priority working path
      indicating an SF condition].  If the LER is in WFA state due to
      any other trigger, then begin transmitting a SF(x, 0) PSC message
      [where x indicates the index of the working path that is
      generating the SF condition].





Osborne, et al.         Expires December 28, 2012              [Page 28]

Internet-Draft                 MPLS-TP LP                      June 2012


   o  A local ClearSF indication where the working path is the same as
      the path that triggered the LER into WFA state SHALL cause the LER
      to go into WTR state (note: 1:N protection is always revertive)
      and to transmit the WTR(0, 0) message.  If the ClearSF indicates a
      different index from the protected working path or incates the
      protection path then the indication SHALL be ignored.

   o  A local MS operator command SHALL cause the LER to remain in WFA
      state.  If the LER is in WFA state due an existing MS trigger,
      then the node continues to transmit MS(x, 0) messages [where x
      indicates the index of the protected working path, i.e. the
      highest prirority working path indicating the MS condition].  If
      the LER is in WFA state due to any other trigger, ignore the MS
      command and continue transmitting the current message.

   o  If the WFA timer expires, i.e. the LER did not receive the
      Acknowledge message from the far end in a timely manner, then the
      LER SHALL go to Unavailable state, i.e. it assumes that there is a
      problem on the protection path (where all PSC traffic is
      transmitted) and send an error notification to the management
      system.  The LER SHALL continue transmitting the current PSC
      message with Path field set to 0.

   o  All other local indications SHALL be ignored.

   The following details the reactions of the LER in WFA state to remote
   messages:

   o  Any remote message with the Acknowledge flag set to 1 and the Path
      field set to the index of the protected working path SHALL cause
      the LER to change state.  If the trigger was either FS or MS
      command, the LER enters Protecting administrative state.  The LER
      transmits the appropriate message according to the trigger (i.e.
      FS(x,x) for FS command and MS(x,x) for the MS command).  If the
      trigger was a SF condition, then the LER enters the Protecting
      failure state and begins to transmit the appropriate SF(x, x)
      message.  A remote message with the Acknowledge flag set to 1 but
      where the Path field does not match, according to the description
      above, SHALL be ignored.

   o  A remote LO message SHALL cause the LER to go into Unavailable
      state and transmit the appropriate message for the trigger that
      caused the WFA state.

   o  A remote FS message indicating the same working path as the local
      FS command that triggered the WFA state SHALL be considered an
      Acknowledge message, even if the Acknowledge flag is not set.  The
      LER SHALL perform the protection switch, and begin transmitting



Osborne, et al.         Expires December 28, 2012              [Page 29]

Internet-Draft                 MPLS-TP LP                      June 2012


      the FS(x, x) message [where x indicates the index of the protected
      working path].  If the remote FS message indicates a different
      index than the one indicated in the local FS and if the remote FS
      message indicates a lower priority working path than the working
      path in the local FS trigger then the LER SHALL ignore the remote
      FS message and remain in WFA state.  If the remote FS message
      indicates an index of higher priority or the LER is in WFA state
      as a result of a SF or MS trigger, then the LER SHALL perform the
      protection switch for the protected working path indicated by the
      remote FS message, and SHALL go to Protecting administrative state
      and transmit the appropriate message for the local trigger with
      the Path field set to the index of the remote message and the
      Acknowledge flag set to 1.

   o  A remote SF message indicating an error on the protection path
      SHALL cause the LER to go into Unavailable stateand transmit the
      appropriate message for the trigger that caused to WFA state.

   o  A remote SF message indicating an error on the same working path
      as the local SF condition that triggered the WFA state SHALL be
      considered an Acknowledge message (even if the Acknowledge flag is
      not set).  The LER SHALL perform the protection switch, go to
      Protecting failure state and transmit the SF(x, x) message [where
      x is the index of the protected working path].  If the remote SF
      message indicates a different index than the one indicated in the
      local SF, then if the local command indicates a higher priority
      working path the LER SHALL ignore the remote SF message and remain
      in WFA state.  If the remote SF message indicates an index of
      higher priority or the LER is in WFA state as a result of a MS
      trigger, then the LER SHALL perform the protection switch for the
      protected working path indicated by the remote SF message, and
      SHALL go to Protecting failure state and transmit the appropriate
      message for the local trigger with the Path field set to the index
      of the remote message and the Acknowledge flag set to 1.  If the
      LER is in WFA state due to a local FS command, then it SHALL
      ignore the remote message and remain in WFA state.

   o  A remote MS message indicating an error on the same working path
      as the local MS that triggered the WFA state SHALL be considered
      an Acknowledge message (even if the Acknowledge flag is not set).
      The LER SHALL perform the protection switch, go to Protecting
      administrative state and transmit the MS(x, x) message [where x is
      the index of the protected working path].  If the remote MS
      message indicates a different index than the one indicated in the
      local MS, then if the local command indicates a higher priority
      working path or the LER is in WFA due to either a FS or SF
      trigger, the LER SHALL ignore the remote MS message and remain in
      WFA state.  If the remote MS message indicates an index of higher



Osborne, et al.         Expires December 28, 2012              [Page 30]

Internet-Draft                 MPLS-TP LP                      June 2012


      priority, then the LER SHALL perform the protection switch for the
      protected working path indicated by the remote MS message, and
      SHALL go to Protecting administrative state and transmit an NR(0,
      y) with the Path field set to the index of the remote message and
      the Acknowledge flag set to 1.

   o  All other remote messages SHOULD be ignored.


5.  IANA Considerations

   This document does not include any required IANA considerations


6.  Security Considerations

   The generic security considerations for the data-plane of MPLS-TP are
   described in the security framework document [SecureFwk] together
   with the required mechanisms needed to address them.  The security
   considerations for the generic associated control channel are
   described in [RFC5586].  The security considerations for protection
   and recovery aspects of MPLS-TP are addressed in [SurvivFwk].

   The extensions to the protocol described in this document are
   extensions to the protocol defined in [LinProt] and does not
   introduce any new security risks.


7.  Acknowledgements

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


8.  References

8.1.  Normative References

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

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

   [LinProt]  Bryant, S., Sprecher, N., Osborne, E., Fulignoli, A., and



Osborne, et al.         Expires December 28, 2012              [Page 31]

Internet-Draft                 MPLS-TP LP                      June 2012


              Y. Weingarten, "Multi-protocol Label Switching Transport
              Profile Linear Protection", RFC 6378, Apr 2011.

8.2.  Informative References

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

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

   [RFC3031]  Rosen, Eric., Viswanathan, A., and Ross. Callon,
              "Multiprotocol Label Switching Architecture", RFC 3031,
              Mar 2006.

   [SurvivFwk]
              Sprecher, N., Farrel, A., and H. Shah, "Multi-protocol
              Label Switching Transport Profile Survivability
              Framework", RFC 6372, Feb 2009.

   [SecureFwk]
              Fang, L., Niven-Jenkins, B., Mansfield, S., Zhang, R.,
              Bitar, N., Daikoku, M., and L. Wang, "MPLS-TP Security
              Framework",
              ID draft-ietf-mpls-tp-security-framework-02.txt, Feb 2011.


Appendix A.  PSC state machine tables

   Note/Disclaimer: This state machine is not currently in sync with the
   text of the document and will be updated in a future revision.

   The full PSC state machine is described in [LinProt], both in textual
   and tabular form.  This appendix highlights the changes to the basic
   PSC state machine.  In the event of a mismatch between these tables
   and the text either in [LinProt] or in this document, the text is
   authoritative.  Note that this appendix is intended to be a
   functional description, not an implementation specification.

   The tables here use the same format and state descriptions used in
   the Linear Protection document with the addition of the WFA state,
   WFA Expires, and the changes in the behavior that is noted.

   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



Osborne, et al.         Expires December 28, 2012              [Page 32]

Internet-Draft                 MPLS-TP LP                      June 2012


   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)

   The top row in each table is the list of possible inputs.  The local
   inputs are:

   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:

   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



Osborne, et al.         Expires December 28, 2012              [Page 33]

Internet-Draft                 MPLS-TP LP                      June 2012


   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, "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.

   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    | i    | 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| i    | [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|UA:P:L| 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|UA:P:L|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






















Osborne, et al.         Expires December 28, 2012              [Page 34]

Internet-Draft                 MPLS-TP LP                      June 2012


   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    | i    | i    | i    | i    | i    | i
       UA:LO:R | i     | i    | i    | i    | i    | i    | i    | [16]
       UA:P:R  |UA:LO:R| i    | i    | 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|UA:P:R| 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|UA:P:R| i    | i    | i    | i    | i    | [17]
       PA:M:R  |UA:LO:R|UA:P:R|PA:F:R| [13] | i    | i    | i    | 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.

   [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)



Osborne, et al.         Expires December 28, 2012              [Page 35]

Internet-Draft                 MPLS-TP LP                      June 2012


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


Authors' Addresses

   Eric Osborne
   Cisco
   United States

   Email: eosborne@cisco.com


   Fei Zhang
   ZTE
   China

   Email: zhang.fei3@zte.com.cn


   Yaacov Weingarten
   34 Hagefen St
   Karnei Shomron,   44853
   Israel

   Email: wyaacov@gmail.com












Osborne, et al.         Expires December 28, 2012              [Page 36]