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

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

Network Working Group                                     S. Bryant, Ed.
Internet-Draft                                                     Cisco
Intended status: Standards Track                        N. Sprecher, Ed.
Expires: August 8, 2010                           Nokia Siemens Networks
                                                    H. van Helvoort, Ed.
                                                                  Huawei
                                                       A. Fulignoli, Ed.
                                                                Ericsson
                                                           Y. Weingarten
                                                  Nokia Siemens Networks
                                                        February 4, 2010


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

Abstract

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

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

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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



Bryant, et al.           Expires August 8, 2010                 [Page 1]

Internet-Draft                 MPLS-TP LP                  February 2010


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

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

   This Internet-Draft will expire on August 8, 2010.

Copyright Notice

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

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

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

















Bryant, et al.           Expires August 8, 2010                 [Page 2]

Internet-Draft                 MPLS-TP LP                  February 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Contributing authors . . . . . . . . . . . . . . . . . . .  5
   2.  Conventions used in this document  . . . . . . . . . . . . . .  5
     2.1.  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Definitions and Terminology  . . . . . . . . . . . . . . .  6
   3.  Protection switching logic . . . . . . . . . . . . . . . . . .  6
     3.1.  Protection switching trigger mechanisms  . . . . . . . . .  6
     3.2.  Protection switching control logical architecture  . . . .  7
       3.2.1.  PSC Status Module  . . . . . . . . . . . . . . . . . .  8
   4.  Protection state coordination (PSC) protocol . . . . . . . . .  8
     4.1.  Transmission and acceptance of PSC control packets . . . .  9
     4.2.  Protocol format  . . . . . . . . . . . . . . . . . . . . . 10
       4.2.1.  PSC Requests . . . . . . . . . . . . . . . . . . . . . 11
       4.2.2.  Protection Type (PT) . . . . . . . . . . . . . . . . . 12
       4.2.3.  Path fault identifier (FPath)  . . . . . . . . . . . . 12
       4.2.4.  Active path indicator (Path) . . . . . . . . . . . . . 12
     4.3.  Principles of Operation  . . . . . . . . . . . . . . . . . 13
       4.3.1.  PSC States . . . . . . . . . . . . . . . . . . . . . . 13
       4.3.2.  Failure or Degraded condition (Working path) . . . . . 14
       4.3.3.  Lockout of Protection  . . . . . . . . . . . . . . . . 15
       4.3.4.  Failure or Degraded condition (Recovery path)  . . . . 16
       4.3.5.  Operator Controlled Switching  . . . . . . . . . . . . 16
       4.3.6.  Recovery from switching  . . . . . . . . . . . . . . . 17
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19



















Bryant, et al.           Expires August 8, 2010                 [Page 3]

Internet-Draft                 MPLS-TP LP                  February 2010


1.  Introduction

   As noted in the architecture for Multi-Protocol Label Switching
   Transport Profile (MPLS-TP) [TPFwk], the overall architecture
   framework for MPLS-TP is based on a profile of the MPLS and
   Pseudowire (PW) procedures as specified for the MPLS and (MS-)PW
   architectures defined in [RFC3031], [RFC3985] and [RFC5085].  One of
   the basic survivability functions, pointed out by the Survivability
   Framework document [SurvivFwk], is that of simple and rapid
   protection switching mechanisms for Label Switched Paths (LSP) and
   Pseudo-wires (PW).

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

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

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

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



Bryant, et al.           Expires August 8, 2010                 [Page 4]

Internet-Draft                 MPLS-TP LP                  February 2010


   bridge at both ends select the same path, this architecture must
   support a PSC protocol.

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

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

1.1.  Contributing authors

   Hao Long (Huawei)


2.  Conventions used in this document

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













Bryant, et al.           Expires August 8, 2010                 [Page 5]

Internet-Draft                 MPLS-TP LP                  February 2010


2.1.  Acronyms

   This draft uses the following acronyms:

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

2.2.  Definitions and Terminology

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


3.  Protection switching logic

3.1.  Protection switching trigger mechanisms

   The protection switching should be initiated in reaction to any of
   the following triggers:

   o  Server layer indication - if the MPLS-TP server layer detects a
      failure within its own layer, or due to a failure of its server
      layer (e.g. the physical layer) notifies the MPLS-TP layer that a
      failure has been detected.

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




Bryant, et al.           Expires August 8, 2010                 [Page 6]

Internet-Draft                 MPLS-TP LP                  February 2010


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

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

3.2.  Protection switching control logical architecture

   Protection switching processes the triggers described above together
   with the inputs received from the far-end LSR.  These inputs cause
   the LSR to take certain actions, e.g. switching the Selector Bridge
   to select the working or recovery path, and to transmit different
   protocol messages.

   +-------------+ Operator Command       Local PSC      +-----------+
   |  External   |-----------------+   +-----------------| PSC Status|
   |  Interface  |                 |   |   request   +---|   Module  |
   +-------------+                 |   |             |   +-----------+
                                   V   V             V Prot. Stat. ^
   +----------+ Local OAM  +---------------+Highest +------------+ |
   |   OAM    |----------->| Local Request |------->|  PSC Mess. | |
   |  Module  |  request   |    logic      |local R.| Generator  | |
   +----------+   +------->+---------------+        +------------+ |
   +----------+   |                      |                 |       |
   | Svr/CP   |---+         Highest local|request          |       |
   +----------+                          V                 V       |
   +-------------+             +-----------------+    PSC Message  |
   | Remote Req. | Remote PSC  |  global Request |                 |
   |  Receiver   |------------>|      logic      |                 |
   +-------------+   Request   +-----------------+                 |
          ^                             |                          |
          |       Highest global request|                          |
          |                             V                          |
          |                    +-----------------+   PSC status    |
   Remote PSC message          |    PSC Process  |-----------------+
                               |       logic     |--------> Action
                               |                 |
                               +-----------------+


               Figure 1: Protection switching control logic

   Figure 1 describes the logical architecture of the protection



Bryant, et al.           Expires August 8, 2010                 [Page 7]

Internet-Draft                 MPLS-TP LP                  February 2010


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

3.2.1.  PSC Status Module

   The PSC Control Logic must retain the status of the protection
   domain.  The possible different states indicate the current status of
   the protection environment, and can be in one of three states:

   o  Normal (Idle) state - When both the recovery and the working paths
      are fully allocated and active, data traffic is being transmitted
      over the working path, and there are no trigger events reported
      within the domain.

   o  Protecting state - When either the working path has reported a
      signal failure (SF) or degradation of signal (SD), or the operator
      has issued an operator command and the data traffic has been
      redirected to the recovery path.

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

   This state may affect the actions taken by the control logic, and
   therefore, the PSC Status Module transfers the current status to the
   Local Request Logic.

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


4.  Protection state coordination (PSC) protocol

   Bidirectional protection switching, as well as unidirectional 1:1
   protection, requires coordination between the two end-points in
   determining which of the two possible paths, the working or recovery
   path, is transmitting the data traffic in any given situation.  When
   protection switching is triggered as described in section 3.1, the



Bryant, et al.           Expires August 8, 2010                 [Page 8]

Internet-Draft                 MPLS-TP LP                  February 2010


   end-points must inform each other of the switch-over from one path to
   the other in a coordinated fashion.

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

   In the following sub-sections we describe the protocol messages that
   should be used between the two end-points of the protection domain.

   For the sake of simplicity of the protocol, this protocol is based on
   the single-phase approach described above.

4.1.  Transmission and acceptance of PSC control packets

   The PSC control packets should be transmitted over the recovery path
   only.  This allows the transmission of the messages without affecting
   the normal traffic in the most prevalent case, i.e. the idle 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.

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

   When the PSC information is changed, three PSC packets should be
   transmitted as quickly as possible, so that fast protection switching
   would be possible.  Transmission of three rapid packets allows for
   fast protection switching even if one or two PSC packets are lost or
   corrupted.  The frequency of the first three packets and the separate
   frequency of the continual transmission is configurable by the
   operator.  For protection switching within 50ms, the default interval
   of the first three PSC signals should be no larger than 3.3ms.  PSC
   packets after the first three should be transmitted with an interval
   of 5 seconds.

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






Bryant, et al.           Expires August 8, 2010                 [Page 9]

Internet-Draft                 MPLS-TP LP                  February 2010


4.2.  Protocol format

   The protocol messages SHALL be sent over the GACH as described in
   [RFC5586].  There is a single channel type for the set of PSC
   messages, each message will be identified by the first field of the
   ACH payload as described below.  PSC messages SHOULD support
   addressing by use of the method described in [RFC5586].  The
   following figure shows the format for the full PSC message.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0|   MPLS-TP PSC Channel Code    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    ACH TLV Header                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                    Addressing TLV                             +
      :                              ...                              :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                    PSC Control Packet                         ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 2: Format of PSC packet with a GACH header

   Where:

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

   o  The ACH TLV Header is described in [RFC5586]

   o  The use of the Addressing TLV are for further study

   o  The following figure shows the format of the PSC Control message
      that is the payload for the PSC packet.

   Editor's note: There is a suggestion that this format should be
   aligned with the format used by G.8031/G.8131/Y.1731 in ITU.  The
   argument being that this would make it easier to pass review from ITU
   and allow easier transfer of technology.

   The counter-argument is that the ITU format is based upon an attempt
   to find a common format for different functionality and therefore
   involves different fields that are not necessary for the protection
   switching.  Defining a new dedicated format would make for a simpler
   and more intuitive protocol.  End of editor's note.



Bryant, et al.           Expires August 8, 2010                [Page 10]

Internet-Draft                 MPLS-TP LP                  February 2010


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

                Figure 3: Format of the PSC control packet

   Where:

   o  Ver: is the version of the protocol, for this version the value
      SHOULD be 0.

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

   o  PT: indicates the type of protection scheme currently supported,
      more details are given in section 4.2.2

   o  FPath: used to indicate the path that is reporting a failure
      condition, the possible values are described in section 4.2.3

   o  Path: used to indicate the currently active path, possible values
      are described in section 4.2.4

   o  Reserved: field is reserved for possible future use.  These bits
      MUST be set to zero on transmission, and ignored upon reception.

4.2.1.  PSC Requests

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

   o  (1111) Clear

   o  (1110) Lockout protection

   o  (1101) Forced switch

   o  (0110) Signal fault

   o  (0101) Signal degrade

   o  (0100) Manual switch

   o  (0011) Wait to restore





Bryant, et al.           Expires August 8, 2010                [Page 11]

Internet-Draft                 MPLS-TP LP                  February 2010


   o  (0010) Do not revert (DNR)

   o  (0000) No request

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

4.2.2.  Protection Type (PT)

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

   o  11: 1+1 bidirectional switching

   o  10: 1:1 bidirectional switching

   o  01: 1+1 unidirectional switching

   o  00: 1:1 unidirectional switching

4.2.3.  Path fault identifier (FPath)

   The Fpath field of the PSC control SHALL be used only in a Signal
   fault (0101) or Signal degrade (0100) control packet.  Its value
   indicates on which path the signal anomaly was detected.  The
   following are the possible values:

   o  0: indicates that the fault condition is on the Recovery path

   o  1: indicates that the fault condition is on the Working path

   o  2-255: for future extensions

4.2.4.  Active path indicator (Path)

   The Path field of the PSC control SHALL be used to indicate which
   path the source MEP is currently using for data transmission.  The
   MEP should compare the value of this bit with the path that is
   locally selected for data transmission to verify that there is no
   inconsistency between the two end-points of the protected domain.  If
   an inconsistency is detected then an alarm should be raised.  The
   following are the possible values:

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




Bryant, et al.           Expires August 8, 2010                [Page 12]

Internet-Draft                 MPLS-TP LP                  February 2010


   o  1: indicates the Recovery path is being used to transmit the
      normal traffic from the Working path.

   o  2-255: for future extensions

4.3.  Principles of Operation

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

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

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


                        Figure 4: Protected domain

4.3.1.  PSC States

4.3.1.1.  Normal State

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

   The ingress LSR MAY transmit a No Request PSC packet with the Path
   field set to 0 indicating that the normal data traffic should be read
   from the working path.

4.3.1.2.  Protecting State

   When the protection mechanism has been triggered and the protected
   domain has performed a protection switch, the domain is in the
   protecting state.  In this state the normal data traffic is
   transmitted and received on the recovery path.

   If the protection domain is currently in a protecting state, then the
   LSRs SHOULD NOT accept a Manual Switch request.

   If the protection domain is currently in a protecting state, and a



Bryant, et al.           Expires August 8, 2010                [Page 13]

Internet-Draft                 MPLS-TP LP                  February 2010


   Forced Switch is requested then the normal traffic SHALL continue to
   be transmitted on the recovery path even if the original protection
   trigger is cleared, and the Forced Switch condition will be signalled
   by the PSC messages.

4.3.1.3.  Unavailable State

   When the recovery path is unavailable - either as a result of a
   Lockout operator command (see section 4.3.3), or as a result of a SF
   or SD detected on the recovery path (see section 4.3.4) - then the
   protection domain is in the unavailable state.  In this state, the
   normal traffic is transmitted and received on the working path.

   While in unavailable state any event that would trigger a protection
   switching SHOULD be ignored with the following exception - If a
   Signal Degrade request is received, then protection switching will be
   activated only if the recovery path can guarantee a better signal
   than the working path.

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

4.3.2.  Failure or Degraded condition (Working path)

   If one of the LSRs (for example, LSR-A) detects a failure condition
   or a serious degradation condition on the working path that warrants
   invoking protection switching, then it SHOULD take the following
   actions:

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

   o  Transmit a PCS control packet, using GACH, with the appropriate
      Request code (either Signal fault or Signal degrade), the Fpath
      set to 1, to indicate that the fault/degrade was detected on the
      working path, and the Path set to 1, indicating that normal
      traffic is now being transmitted on the recovery path.

   o  Verify that LSR-Z replies with a PCS control packet indicating
      that it has switched to the recovery path.  If this is not
      received after 2 PSC cycles then send an alarm to the management
      system.

   When the far-end LSR (in this example LSR-Z) receives the PCS packet
   informing it that other LSR (LSR-A) has switched, it SHOULD perform



Bryant, et al.           Expires August 8, 2010                [Page 14]

Internet-Draft                 MPLS-TP LP                  February 2010


   the following actions:

   o  Check priority of the request

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

   o  Begin transmission of a PCS control packet, using GACH, with the
      appropriate Request code (either Signal fault or Signal degrade),
      the Fpath set to 1, to indicate that the fault/degrade was
      detected on the working path, and the Path set to 1, indicating
      that traffic is now being transmitted on the recovery path.

4.3.3.  Lockout of Protection

   If one of the LSRs (for example, LSR-A) receives a management command
   indicating that the protection is disabled, then it SHOULD indicate
   this to the far-end LSR (LSR-Z in this example) that it is not
   possible to use the recovery path.  The following actions MUST be
   taken:

   o  Transmit a PCS control packet, using GACH, with the Request code
      set to Lockout of protection (1110), the Fpath set to 0, and the
      Path set to 0.

   o  All normal traffic packets should be transmitted on the working
      path only.

   o  Verify that the far-end LSR (for example LSR-Z) is forwarding the
      data packets on the working path.  Raise alarm in case of
      mismatch.

   o  The PSC control logic should go into Unavailable state.

   When the far-end LSR (in this example LSR-Z) receives the PCS packet
   informing it that other LSR (LSR-A) has switched, it SHOULD perform
   the following actions:

   o  Check priority of request

   o  Switch all normal traffic addressed to LSR-A to the working path
      only.

   o  The PSC control logic should go into Unavailable status.

   o  Begin transmission of a PCS control packet, using GACH, with the
      appropriate Request code (Lockout of protection), the Fpath set to
      0, and the Path set to 0, indicating that traffic is now being



Bryant, et al.           Expires August 8, 2010                [Page 15]

Internet-Draft                 MPLS-TP LP                  February 2010


      transmitted on the working path only.

4.3.4.  Failure or Degraded condition (Recovery path)

   If one of the LSRs (for example, LSR-A) detects a failure condition
   or a serious degradation condition on the recovery path, then it
   SHOULD take the following actions:

   o  Begin transmission of a PCS control packet with the appropriate
      Request code (either Signal fault or Signal degrade), the Fpath
      set to 0, to indicate that the fault/degrade was detected on the
      recovery path, and the Path set to 0, indicating that traffic is
      now being forwarded on the working path.  Note that this will
      actually reach the far-end if this is a unidirectional fault or
      recovery path is possibly in a degraded situation.

   o  The PSC control logic should go into Unavailable state.

   o  All traffic MUST be transmitted on the working path for the
      duration of the SF/SD condition.

   When the far-end LSR (in this example LSR-Z) receives the PCS packet
   informing it that other LSR (LSR-A) has become Unavailable, it SHOULD
   perform the following actions:

   o  Transmit all traffic on the working path for the duration of the
      SF/SD condition

   o  The PSC Control logic should go into Unavailable state.

4.3.5.  Operator Controlled Switching

   If the management system indicated to one of the LSRs (for example
   LSR-A) that a switch is necessary, e.g. either a Forced Switch or a
   Manual Switch, then the LSR SHOULD switch the traffic to the recovery
   path and perform the following actions:

   o  Switch all data traffic to the recovery path only.

   o  Transmit a PCS control packet, using GACH, with the appropriate
      Request code (either Manual switch or Forced switch), the Fpath
      set to 0, to indicate that the fault/degrade was detected on the
      working path, and the Path set to 1, indicating that traffic is
      now being forwarded on the recovery path.

   o  Verify that LSR-Z replies with a PCS control packet indicating
      that it has switched to the recovery path.  If this is not
      received after 2 PSC cycles then send an alarm to the management



Bryant, et al.           Expires August 8, 2010                [Page 16]

Internet-Draft                 MPLS-TP LP                  February 2010


      system.

   When the far-end LSR (in this example LSR-Z) receives the PCS packet
   informing it that other LSR (LSR-A) has switched, it SHOULD perform
   the following actions:

   o  Check priority of the request

   o  Switch all normal traffic addressed to LSR-A to the recovery path
      only.

   o  Begin transmission of a PCS control packet, using GACH, with the
      appropriate Request code (either Manual switch of Forced switch),
      the Fpath set to 1, to indicate that the fault/degrade was
      detected on the working path, and the Path set to 1, indicating
      that traffic is now being forwarded on the recovery path.

4.3.5.1.  Clearing operator commands

   The operator may clear the switching condition by issuing a Clear
   request.  This command will cause immediate recovery from the switch
   that was initiated by any of the previous operator commands, i.e.
   Forced Switch or Manual Switch.  In addition, a Clear command after a
   Lockout Protection command should clear the Unavailable state and
   return the protection domain to the normal state.

   If the Clear request is issued in the absence of a Manual Switch,
   Forced Switch, or Lockout protection, then it SHALL be ignored.  In
   the presence of any of these commands, the Clear request SHALL clear
   the state affected by the operator command.

4.3.6.  Recovery from switching

   When the condition that triggered the protection switching clears,
   e.g. the cause of the failure condition has been corrected, or the
   operator clears a Manual Switch, then the protection domain SHOULD
   follow the following procedures:

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

   o  If the network is recovering from an operator switching command
      (in revertive mode), then both LSRs SHOULD return to using the
      working transport path and transmit No request (Request code 0000)
      messages.

   o  If the network is recovering from a failure or degraded condition
      (in revertive mode), then the LSR that detects this recovery SHALL



Bryant, et al.           Expires August 8, 2010                [Page 17]

Internet-Draft                 MPLS-TP LP                  February 2010


      activate a local Wait-to-restore (WTR) timer (see section 4.3.6.1)
      to verify that there is not an intermittent failure.  After the
      WTR expires, the LSR SHOULD return to using the working transport
      path and transmit No request (Request code 0000) messages.

4.3.6.1.  Wait-to-restore timer

   In revertive mode, in order to prevent frequent activation of
   protection switching due to an intermittent defect, the working
   transport path must become stable and fault-free before reverting to
   the normal condition.  In order to verify that this is the case a
   fixed period of time must elapse before the normal traffic uses the
   working transport path.  This period, called the Wait-to-restore
   (WTR) period, should be configurable by the operator in 1-minute
   intervals within the range 1-12 minutes.  The default value is 5
   minutes.

   During this period, if a failure condition is detected on the working
   transport path, then the WTR timer is cleared and the normal traffic
   SHALL continue to be transported over the recovery transport path.
   If the WTR timer expires without being pre-empted by a failure, then
   the traffic SHOULD be returned to use the working transport path (as
   above).


5.  IANA Considerations

   To be added in future version.


6.  Security Considerations

   To be added in future version.


7.  Acknowledgements

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


8.  References







Bryant, et al.           Expires August 8, 2010                [Page 18]

Internet-Draft                 MPLS-TP LP                  February 2010


8.1.  Normative References

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

8.2.  Informative References

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

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

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

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

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

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

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

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

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









Bryant, et al.           Expires August 8, 2010                [Page 19]

Internet-Draft                 MPLS-TP LP                  February 2010


Authors' Addresses

   Stewart Bryant (editor)
   Cisco
   United Kingdom

   Email: stbryant@cisco.com


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

   Email: nurit.sprecher@nsn.com


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

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


   Annamaria Fulignoli (editor)
   Ericsson
   Italy

   Phone:
   Email: annamaria.fulignoli@ericsson.com


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

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








Bryant, et al.           Expires August 8, 2010                [Page 20]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/