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

Abstract

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

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

Status of this Memo

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

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

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

This Internet-Draft will expire on January 27, 2011.

Copyright Notice

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

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

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

Table of Contents

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

1.  Introduction

The MPLS Transport Profile (MPLS-TP) [TPFwk] (Bocci, M., Bryant, S., and L. Levrau, “A Framework for MPLS in Transport Networks,” July 2009.) is a framework for the construction and operation of packet-switched transport networks based on the architectures for MPLS ([RFC3031] (Rosen, E., Viswanathan, A., and R. Callon, “Multiprotocol Label Switching Architecture,” Jan 2001.) and [RFC3032] (Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, “MPLS Label Stack Encoding,” Jan 2001.)) and for Pseudowires (PWs) ([RFC3985] (Bryant, S. and P. Pate, “Pseudowire Emulation Edge-to-Edge (PWE3) Architecture,” March 2005.) and [RFC5659] (Bocci, M. and S. Bryant, “An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge,” October 2009.)) and the requirements of [RFC5654] (Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “Requirements of an MPLS Transport Profile,” September 2009.).

Network survivability is the ability of a network to recover traffic delivery following failure, or degradation of network resources. The MPLS-TP Survivability Framework [SurvivFwk] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.) 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] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.). Linear protection provides rapid and simple protection switching. In a mesh network, linear protection provides a very suitable protection mechanism because it can operate between any pair of points within the network. It can protect against a defect in an intermediate node, a span, a transport path segment, or an end-to-end transport path.

1.1.  Protection architectures

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

As specified in the Survivability Framework document [SurvivFwk] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.), protection switching is applied to a protection domain. For the purposes of this document, we define the protection domain of a P2P LSP as consisting of two Label Switching Routers (LER) and the transport paths that connect them. For a P2MP LSP the protection domain includes the root (or source) LER, the destination (or sink) LSRs, and the transport paths that connect them.

In 1+1 unidirectional architecture as presented in [SurvivFwk] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.), a recovery transport path is dedicated to each working transport path. Normal traffic is bridged (as defined in [RFC4427] (Mannie, E. and D. Papadimitriou, “Recovery Terminology for Generalized Multi-Protocol Label Switching,” Mar 2006.))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 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, similar to the 1:1 case by using a selector bridge at the source, either on the normal working path for that service or, in cases that trigger protection switching (as defined in [SurvivFwk] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.)), 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 may be 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.

1.2.  Scope of the document

As was pointed out in the Survivability Framework [SurvivFwk] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.) and highlighted above, there is a need for coordination between the end-points of the protection domain when employing bidirectional protection schemes. This is especially true when there is a need to maintain traffic over a co-routed bidirectional LSP.

The scope of this draft is to present a protocol for the Protection State Coordination of Linear Protection. The protocol addresses the protection of LSPs in an MPLS-TP network as required by [RFC5654] (Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “Requirements of an MPLS Transport Profile,” September 2009.) (in particular requirements 63-67 and 74-79) and described in [SurvivFwk] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.). The basic protocol is designed for use in conjunction with the 1:1 protection architecture (for both unidirectional and bidirectional protection) and for 1+1 protection of a bidirectional path (for both unidirectional and bidirectional protection switching). Applicability of the protocol for 1:n protection schemes may be documented in a future document. The applicability of this protocol to additional MPLS-TP constructs and topologies may be documented in future documents.

While the unidirectional 1+1 protection architecture does not require the use of a coordination protocol, the protocol may be used by the ingress node of the path to notify the far-side end point that a switching condition has occurred and verify the consistency of the end-point configuration. This use may be especially useful for point-to-multipoint transport paths, that are unidirectional by definition of [RFC5654] (Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “Requirements of an MPLS Transport Profile,” September 2009.).

1.3.  Contributing authors

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

2.  Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.1.  Acronyms

This draft uses the following acronyms:

2.2.  Definitions and Terminology

The terminology used in this document is based on the terminology defined in [RFC4427] (Mannie, E. and D. Papadimitriou, “Recovery Terminology for Generalized Multi-Protocol Label Switching,” Mar 2006.) and further adapted for MPLS-TP in [SurvivFwk] (Sprecher, N., Farrel, A., and H. Shah, “Multi-protocol Label Switching Transport Profile Survivability Framework,” Feb 2009.). In addition, we use the term LER to refer to a MPLS-TP Network Element, whether it is a LER, LER, T-PE, or S-PE.

3.  Protection switching control logic

3.1.  Protection switching control logical architecture

Protection switching processes the local triggers described in [RFC5654] (Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “Requirements of an MPLS Transport Profile,” September 2009.) requirements 74-79 together with inputs received from the far-end LER. Based on these inputs the LER will take certain protection switching actions, e.g. switching the Selector Bridge to select the working or protection path, and transmit different protocol messages.

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

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

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

3.1.1.  Local Request Logic

The protection switching logic processes input triggers from five sources:

• 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] (Mannie, E. and D. Papadimitriou, “Recovery Terminology for Generalized Multi-Protocol Label Switching,” Mar 2006.)).
• Server layer alarm indication – the underlying server layer of the network detects failure conditions at the underlying layer and may issue an indication to the MPLS-TP layer. The server layer may employ its own protection switching mechanism, and therefore this input MAY be controlled by a holdoff-timer that SHOULD be configurable by the network operator.
• 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] (Mannie, E., “Generalized Multi-Protocol Label Switching (GMPLS) Architecture,” Oct 2004.) then the recovery process SHALL comply with the process described in [RFC4872] (Lang, J., Papadimitriou, D., and Y. Rekhter, “RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery,” May 2007.).
• OAM indication – OAM fault management or performance measurement tools may detect a failure or degrade condition on the MPLS-TP transport path and this SHOULD input an indication to the Local Request Logic.
• WTR expires – The Wait-to-Restore timer is used in conjunction with recovery from failure conditions on the working path in revertive mode. The timer SHALL signal the PSC control process when it expires and the end-point SHOULD revert to the normal transmission of the user data traffic.

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

• Clear – if the opeartor cancels an active local administrative command, i.e. LO/FS/MS.
• Lockout of Protection (LO) – if the operator requested to disable the protection path.
• Signal Fail (SF) – if any of the Server Layer, Control plane, or OAM indications signaled a failure condition on either the protection path or one of the working paths.
• Signal Degrade (SD) – if any of the Server Layer, Control plane, or OAM indications signaled a degraded transmission condition on either the protection path or one of the working paths
• Clear Signal Fail – if all of the Server Layer, Control plane, or OAM indications are no longer indicating a failure condition on a path that was peviously indicating a failure condition.
• Forced Switch (FS) – if the operator requested that traffic be switched from one of the working paths to the protection path.
• Manual Switch (MS) – if the operator requested that traffic be switched from its current path to the other path. This is only relevant if there is no currently active Fault condition or Operator command.
• WTR Expires – generated by the WTR timer completing its period.

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

3.1.2.  Remote Requests

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

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

• Remote LO – indicates that the remote end-point is in Unavailable state due to a Lockout of Protection operator command.
• Remote SF – indicates that the remote end-point has detected a Signal Fail condition on one of the transport paths in the protection domain. This remote message SHALL include an indication of which transport path is affected by the SF condition. In addition, it should be noted that the SF condition may be either unidirectional or bidirectional failure, even if the transport path is bidirectional.
• Remote SD – indicates that the remote end-point has detected a Signal Degrade condition on one of the transport paths in the protection domain. This remote message SHALL include an indication of which transport path is affected by the SD condition. In addition, it should be noted that the SD condition may be either unidirectional or bidirectional failure, even if the transport path is bidirectional.
• Remote FS – indicates that the remote end point is operating under an operator command to switch the traffic to the protection path.
• Remote MS – indicates that the remote end point is operating under an operator command to switch the traffic to the path that was not being used previously.
• Remote WTR – indicates that the remote end-point has determined that the failure condition has recovered and has started its WTR timer in preparation for reverting to the Normal state.
• Remote DNR – indicates that the remote end-point has determined that the failure condition has recovered and will continue transporting traffic on the protection path due to operator configuration that prevents automatic reversion to the Normal state.
• Remote NR – indicates that the remote end-point has no abnormal condition to report.

3.1.3.  PSC Process Logic

The PSC Process Logic SHALL accept as input – a. the Local request output from the Local Request Logic, b. the remote request message from the remote end-point of the transport path, and c. the current state of the PSC Control Logic (maintained internally by the PSC Control Logic). Based on the priorities between the different inputs, the PSC Process Logic SHALL determine the new state of the PSC Control Logic and what actions need to be taken.

The new state information SHALL be sent for retention by the State Manager, while the requested action SHALL be sent to the PSC Message Generator (see subsection 3.1.4) to generate and transmit the proper PSC message to be transmitted to the remote end-point of the protection domain.

3.1.4.  PSC Message Generator

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

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

3.1.5.  Wait-to-Restore (WTR) timer

The WTR timer is used to delay reversion to Normal state when recovering from a failure condition on the working path and the protection domain is configured for revertive behavior. The WTR timer MAY be started, stopped, or expire. If the WTR timer is running, sending a Stop command SHALL reset the timer but SHALL NOT generate a WTR Expires local signal. If the WTR timer is not running, a Stop command SHALL be ignored.

3.1.6.  PSC Control States

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

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

• Normal state – Both the protection and working paths are fully allocated and active, data traffic is being transmitted over the working path, and no trigger events are reported within the domain.
• Unavailable state – The protection path is unavailable – either as a result of an operator Lockout command or a failure/degrade condition detected on the protection path.
• Protecting failure state – The working path has reported a failure/degrade condition and the user traffic is being transmitted on the protection path.
• Protecting administrative state – The operator has issued a command switching the user traffic to the protection path.
• Wait-to-restore state – The protection domain is recovering from a SF/SD condition on the working path that is being controlled by the Wait-to-Restore (WTR) timer.
• Do-not-revert state – The protection domain is recovering from a Protecting state, but the operator has configured the protection domain to not automatically revert to the Normal state upon recovery. The protection domain SHALL remain in this state until the operator issues a command to revert to the Normal state or there is a new trigger to switch to a different state.

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

4.  Protection state coordination (PSC) protocol

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

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

For the sake of simplicity of the protocol, this protocol is based on the single-phase approach described above. In the following sub-sections we describe the protocol messages that SHALL be used between the two end-points of the protection domain.

4.1.  Transmission and acceptance of PSC control packets

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

When the PSC information is changed due to a local input, three PSC messages SHOULD be transmitted as quickly as possible, to allow for rapid protection switching. This set of three rapid messages allows for fast protection switching even if one or two of these packets are lost or corrupted. When the PSC information changes due to a remote message there is no need for the rapid transmission of three messages with the following exception – When going from Wait-to-Restore state to Normal state as a result of a remote NR message.

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

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

4.2.  Protocol format

The protocol messages SHALL be sent over the G-ACh as described in [RFC5586] (Vigoureux,, M., Bocci, M., Swallow, G., Aggarwal, R., and D. Ward, “MPLS Generic Associated Channel,” May 2009.). There is a single channel type for the set of PSC messages [to be assigned by IANA]. The actual message function SHALL be identified by the Request field of the ACH payload as described below. The following figure shows the format for the complete PSC message:.

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

Where:

• MPLS-TP PSC Channel Code is the G-ACh channel number assigned to the PSC = TBD
• The ACH TLV Header is described in [RFC5586] (Vigoureux,, M., Bocci, M., Swallow, G., Aggarwal, R., and D. Ward, “MPLS Generic Associated Channel,” May 2009.)
• The following subsections will describe the fields of the PSC payload.

4.2.1.  PSC Ver field

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

4.2.2.  PSC Request field

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

• (1110) Lockout of protection – indicates that the endpoint has disabled the protection path as a result of an administrative command. Both the FPath and Path fields SHOULD be set to 0.
• (1101) Forced switch – indicates that the transmitting end-point has switched traffic to the protection path as a result of an administrative command. The Fpath field SHOULD indicate that the working path is being blocked, and the Path field SHOULD indicate that user data traffic is being transmitted on the protection path.
• (0110) Signal Fail – indicates that the transmitting end-point has identified a signal fail condition on either the working or protection path. The Fpath field SHALL identify the path that is reporting the failure condition, and the Path field SHALL indicate where the data traffic is being transmitted.
• (0100) Manual switch – indicates that the transmitting end-point has switched traffic as a result of an administrative Manual Switch command. The Fpath field SHALL indicate the path that is the manual switch is being applied to and the Path field SHALL indicate the path being utilized by the endpoint to transmit user data traffic.
• (0011) Wait to restore – indicates that the transmitting endpoint is recovering from a failure condition of the working path and has started the Wait-to-Restore timer. Fpath SHOULD be set to 0 and ignored upon receipt. Path SHOULD indicate the working path that is currently being protected.
• (0010) Do not revert – indicates that the transmitting endpoint is recovering from a failure/blocked condition, but due to the local settings is requesting that the protection domain continues to transmit data over the protection path, rather than revert to the Normal state. Fpath SHOULD be set to 0 and ignored upon receipt. Path SHOULD indicate the working path that is currently being protected.
• (0000) No request – indicates that the transmitting end-point has nothing to report, Fpath and Path fields SHOULD be set to according to the state of the end-point.

4.2.3.  Protection Type (PT)

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

• 11: bidirectional switching using a permanent bridge
• 10: bidirectional switching using a selector bridge
• 01: unidirectional switching using a permanent bridge
• 00: unidirectional switching using a selector bridge

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

4.2.4.  Revertive (R) field

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

• 0 – non-revertive mode
• 1 – revertive mode

4.2.5.  Fault path (FPath) field

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

• 0: indicates that the anomaly condition is on the protection path
• 1: indicates that the anomaly condition is on the working path
• 2-255: for future extensions

4.2.6.  Data path (Path) field

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

• 0: indicates that the protection path is not transporting user data traffic (in 1:n architecture) or transporting redundant user data traffic (in 1+1 architecture).
• 1: indicates that the protection path is transmitting user traffic replacing the use of the working path.
• 2-255: for future extensions

4.3.  Principles of Operation

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

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

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

4.3.1.  Basic operation

The basic operation of the coordination protocol is to allow the end-points to notify their peer of the status that is known to that end-point. The parameters that are notified between the end-points – the local condition of the protection domain, the blocked path (if there is a blockage within the protection domain), and the current usage of the protection path. It should be noted that the messages exchanged between the two end-points may not be the same at a given point in time, although the states of the end-points are coordinated. In particular it should be noted that a remote message MAY not cause the end-point to change the Request field that is being transmitted while it does affect the Path field (see details in the following subsections).

The protocol is a single-phase protocol, although it includes a possibility to extend the protocol for multiple-phased operation. Single-phase implies that each end-point notifies its peer of a change in the operation (switching to or from the protection path) and makes the switch without waiting for acknowledgement.

The following subsections will identify the messages that are transmitted by the end-point in different scenarios. The messages are described as REQ(FP, P) – where REQ is the value of the Request field, FP is the value of the Fpath field, and P is the value of the Path field. All examples assume a protection domain between LER-A and LER-Z with a single working path and single protection path (as shown in figure 3).

4.3.2.  Priority of inputs

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

1. Clear (Operator command)
2. Lockout of protection (Operator command)
3. Signal Fail on protection (OAM/Control Plane/Server Indication)
4. Forced switch (Operator command)
5. Signal Fail on working (OAM/Control Plane/Server Indication)
6. Clear Signal Fail (OAM/Control Plane/Server Indication)
7. Manual switch (Operator command)
8. WTR expires (WTR Timer)

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

4.3.3.  Operation of PSC States

4.3.3.1.  Normal State

When the protection domain has no special condition in effect, the ingress LER 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 LER SHOULD read the data from the working path.

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

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

• A local Lockout of protection input SHALL cause the LER to go into Unavailable State and begin transmission of a LO(0,0) message to the far-end LER (LER-Z).
• A local Forced switch input SHALL cause the LER to go into Protecting administrative state and begin transmission of a FS(1,1) message to the far-end LER (LER-Z).
• A local Signal Fail indication on the protection path SHALL cause the LER to go into Unavailable state and begin transmission of a SF(0,0) message to the far-end LER (LER-Z).
• A local Signal Fail indication on the working path SHALL cause the LER to go into Protecting failure state and begin transmission of a SF(1,1) message to the far-end LER (LER-Z).
• A local Manual switch input SHALL cause the LER to go into Protecting administrative state and begin transmission of a MS(1,1) message to the far-end LER (LER-Z).
• All other local inputs SHOULD be ignored.

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

• A remote Lockout of protection message SHALL cause the LER (LER-A) to go into Unavailable state, while continuing to transmit the NR(0,0) message.
• A remote Forced switch message SHALL cause the LER (LER-A) to go into Protecting administrative state, and transmit a NR(0,1) message.
• A remote Signal Fail message that indicates that the failure is on the protection path SHALL cause the LER (LER-A) to go into Unavailable state, while continuing to transmit the NR(0,0) message.
• A remote Signal Fail message that indicates that the failure is on the working path SHALL cause the LER (LER-A) to go into Protecting failure state, and transmit a NR(0,1) message.
• A remote Manual switch message SHALL cause the LER (LER-A) to go into Protecting administrative state, and transmit a NR(0,1) message.
• All other remote messages SHOULD be ignored.

4.3.3.2.  Unavailable State

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

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

When in unavailable state the data traffic is being transmitted on the working path and is not protected. In many cases the remote messages will not be received (since the protection path is blocked) and the main effect will be as a result of local inputs.

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

• A local Clear input SHOULD be ignored if the LER is in remote Unavailable state. If in local Unavailable state due to a Lockout command, then the input SHALL cause the LER to go to Normal state and begin transmitting a NR(0,0) message.
• A local Lockout of protection input SHALL cause the LER to remain in Unavailable State and begin transmission of a LO(0,0) message to the far-end LER (LER-Z).
• A local Clear SF indication SHOULD be ignored if the LER is in remote Unavailable state. If in local Unavailable state due to a Signal Fail on the protection path and the Clear SF indicates that the protection path is now cleared, then the input SHALL cause the LER to go to Normal state and begin transmitting a NR(0,0) message.
• A local Forced switch input when in Unavailable state due to a local or remote failure condition on the protection path SHALL cause the LER to go into Protecting administrative state and begin transmission of a FS(1,1) message. When in Unavailable state due to local Lockout input – this message SHOULD be filtered out by the Local Request Logic. If Unavailable due to remote Lockout input, then this message SHOULD be ignored by the PSC Process Logic.
• A local Signal Fail indication on the protection path SHALL cause the LER to remain in Unavailable state and begin transmission of a SF(0,0) message.
• All other local inputs SHOULD be ignored.

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

• A remote Lockout of protection message SHALL cause the LER to remain in Unavailable state, and continue transmission of the current message (either NR(0,0) or LO(0,0))
• A remote Signal Fail message that indicates that the failure is on the protection path SHALL cause the LER to remain in Unavailable state and continue transmission of the current message (either NR(0,0) or SF(0,0)).
• A remote No Report, when the LER is remote Unavailable state SHALL cause the LER to go into Normal state and begin transmission of a NR(0,0) message. When in local Unavailable state, the message SHALL be ignored.
• All other remote messages SHOULD be ignored.

4.3.3.3.  Protecting administrative state

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

The following describe the reaction to local input:

• A local Clear SHOULD be ignored if in remote Protecting state. If in local Protecting administrative state then this input SHALL cause the LER to go into Normal state and begin transmitting a NR(0,0) message.
• A local Lockout of protection input SHALL cause the LER to go into Unavailable state and begin transmission of a LO(0,0) message.
• A local Forced switch input SHALL cause the LER to remain in Protecting administrative state and begin transmission of a FS(1,1) message.
• A local Signal Fail indication on the protection path SHALL cause the LER to go into Unavailable state and begin transmission of a SF(0,0) message.
• A local Signal Fail indication on the working path SHOULD be filtered by the Local Request Logic if the protecting state was entered due to an active local Forced switch operator command. If the protecting state is due to a remote Forced switch message, then this local indication SHOULD be filtered by the PSC Process Logic. If the current state is due to a (local or remote) Manual switch operator command, it shall cause the LER to go into Protecting failure state and begin transmitting a SF(1,1) message.
• A local Manual switch input SHALL be filtered by the Local Request Logic if there is an active local Forced switch. If the protecting state is due to a remote Forced switch command, then this local indication SHOULD be filtered by the PSC Process Logic. If the current state is due to a (local or remote) Manual switch operator command, it shall cause the LER to remain in Protecting administrative state and begin transmission of a MS(1,1) message.
• All other local inputs SHOULD be ignored.

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

• A remote Lockout of protection message SHALL cause the LER to go into Unavailable state and begin transmitting a NR(0,0) message. It should be noted that this automatically cancels the current Forced switch or Manual switch command and data traffic is reverted to the working path.
• A remote Forced switch message SHOULD be ignored by the PSC Process Logic if there is an active local Forced switch operator command. If the Protecting state is due to a remote Forced switch message then the LER SHALL remain in Protecting administrative state and continue transmission of the last message. If the Protecting state is due to either a local or remote Manual switch then the LER SHALL remain in Protecting administrative state (updating the state information with the proper relevant information) and begin transmitting a NR(0,1) message.
• A remote Signal Fail message indicating a failure on the protection path SHALL cause the LER to go into Unavailable state and begin transmitting a NR(0,0) message. It should be noted that this automatically cancels the current Forced switch or Manual switch command and data traffic is reverted to the working path.
• A remote Signal Fail message indicating a failure on the working path SHALL be ignored if there is an active local Forced switch command. If the Protecting state is due to a local or remote Manual switch then the LER SHALL go to Protecting failure state and begin transmitting a NR(0,1) message.
• A remote Manual switch message SHALL be ignored by the PSC Process Logic if in Protecting state due to a local or remote Forced switch. If in Protecting state due to a remote Manual switch then the LER SHALL remain in Protecting administrative state and continue transmitting the current message. If in Protecting state due to an active local Manual switch then the LER SHALL remain in Protecting administrative state and continue transmission of the MS(1,1) message.
• A remote DNR(0,0) message SHALL be ignored if in Protecting state due to a local input. If in Protecting state due to a remote message then the LER SHALL go to Do-not-revert state and begin transmitting a NR(0,0) message.
• A remote NR(0,0) message SHALL be ignored if in Protecting state due to a local input. If in Protecting state due to a remote message then the LER SHALL go to Normal state and begin transmitting a NR(0,0) message.
• All other remote messages SHALL be ignored.

4.3.3.4.  Protecting failure state

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

The following describe the reaction to local input:

• A local Clear SF SHOULD be ignored if in remote Protecting state. If the Clear SF indicates that the protection path is now cleared (but working is still in SF condition) then the indicateion SHOULD be ignored. If in local Protecting failure state and the LER is configured for revertive behavior then this input SHALL cause the LER to go into Wait-to-restore state, start the WTR timer, and begin transmitting a WTR(0,1) message. If in local Protecting failure state and the LER is configured for non-revertive behavior then this input SHALL cause the LER to go into Do-not-revert state and begin transmitting a DNR(0,1) message.
• A local Lockout of protection input SHALL cause the LER to go into Unavailable state and begin transmission of a LO(0,0) message.
• A local Forced switch input SHALL cause the LER to go into Protecting administrative state and begin transmission of a FS(1,1) message.
• A local Signal Fail indication on the protection path SHALL cause the LER to go into Unavailable state and begin transmission of a SF(0,0) message.
• A local Signal Fail indication on the working path SHALL cause the LER to remain in Protecting failure state and begin transmitting a SF(1,1) message.
• All other local inputs SHOULD be ignored.

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

• A remote Lockout of protection message SHALL cause the LER to go into Unavailable state and if in protecting failure state due to a local SF condition begin transmitting a SF(1,0) message, otherwise transmit a NR(0,0) message. It should be noted that this may cause loss of user data since the working path is still in a failure condition.
• A remote Forced switch message SHALL cause the LER go into Protecting administrative state and if in protecting failure state due to a local SF condition begin transmitting the SF(1,1) message, otherwise begin transmitting NR(0,0).
• A remote Signal Fail message indicating a failure on the protection path SHALL cause the LER to go into Unavailable state and if in protecting failure state due to a local SF condition begin transmitting a SF(1,0) message, otherwise begin transmitting NR(0,0) message. It should be noted that this may cause loss of user data since the working path is still in a failure condition.
• If in Protecting state due to a remote message, a remote Wait-to-Restore message SHOULD cause the LER to go into Wait-to-Restore state and continue transmission of the current message.
• If in Protecting state due to a remote message, a remote Do-not-revert message SHOULD cause the LER to go into Do-not-revert state and continue transmission of the current message.
• All other remote messages SHALL be ignored.

4.3.3.5.  Wait-to-restore state

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

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

• A local Lockout of protection command SHALL cause the LER to Stop the WTR timer, go into Unavailable state, and begin transmitting a LO(0,0) message.
• A local Forced switch command SHALL cause the LER to Stop the WTR timer, go into Protecting administrative state, and begin transmission of a FS(1,1) message.
• A local Signal Fail indication on the protection path SHALL cause the LER to Stop the WTR timer, go into Unavailable state, and begin transmission of a SF(0,0) message.
• A local Signal Fail indication on the working path SHALL cause the LER to Stop the WTR timer, go into Protecting failure state, and begin transmission of a SF(1,1) message.
• A local Manual switch input SHALL cause the LER to Stop the WTR timer, go into Protecting administrative state and begin transmission of a MS(1,1) message.
• A local WTR expires input SHALL cause the LER to remain in Wait-to-Restore state and begin transmitting a NR(0,1) message.
• All other local inputs SHOULD be ignored.

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

• A remote Lockout of protection message SHALL cause the LER to Stop the WTR timer, go into Unavailable state, and begin transmitting a NR(0,0) message.
• A remote Forced switch message SHALL cause the LER to Stop the WTR timer, go into Protecting administrative state, and begin transmission of a NR(0,1) message.
• A remote Signal Fail message for the protection path SHALL cause the LER to Stop the WTR timer, go into Unavailable state, and begin transmission of a NR(0,0) message.
• A remote Signal Fail message for the working path SHALL cause the LER to Stop the WTR timer, go into Protecting failure state, and begin transmission of a NR(0,1) message.
• A remote Manual switch message SHALL cause the LER to Stop the WTR timer, go into Protecting administrative state and begin transmission of a NR(0,1) message.
• If the WTR timer is running then a remote NR message SHALL be ignored. If the WTR timer is no longer running then a remote NR message SHALL cause the LER to go into Normal state and begin transmitting a NR(0,0) message.
• All other remote messages SHOULD be ignored.

4.3.3.6.  Do-not-revert state

Do-not-revert state is a continuation of the protecting state when the protection domain is configured for non-revertive behavior. While in Do-not-revert state data traffic continues to be transmitted on the protection path until the administrator sends a command to revert to the Normal state. It should be noted that there is a fundemental difference between this state and Normal – whereas Forced Switch in Normal state actually causes a switch in the transport path used, in Do-not-revert state the Forced switch just switches the state but the traffic would continue to be transmitted on the protection path! The command to revert back to Normal state could either be a Lockout of protection (followed be a Clear command), a Clear command, or a new form of the Manual switch command [note: This would also require some kind of agreement, although it seems to have been adopted by ITU-T in G.8031 for Ethernet]. The following description of operation is based on the Lockout/Clear option mentioned!

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

• A local Lockout of protection command SHALL cause the LER to go into Unavailable state and begin transmitting a LO(0,0) message.
• A local Forced switch command SHALL cause the LER to go into Protecting administrative state and begin transmission of a FS(1,1) message.
• A local Signal Fail indication on the protection path SHALL cause the LER to go into Unavailable state and begin transmission of a SF(0,0) message.
• A local Signal Fail indication on the working path SHALL cause the LER to go into Protecting failure state and begin transmission of a SF(1,1) message.
• A local Manual switch input SHALL cause the LER to go into Protecting administrative state and begin transmission of a MS(1,1) message.
• All other local inputs SHOULD be ignored.

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

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

5.  IANA Considerations

To be added in future version.

6.  Security Considerations

To be added in future version.

7.  Acknowledgements

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

8.  References

8.1. Normative References

8.2. Informative References

Authors' Addresses