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

Abstract

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

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

Status of this Memo

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

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

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

This Internet-Draft will expire on January 01, 2012.

Copyright Notice

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

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

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

Table of Contents

• 1. Introduction
• 1.1. 1:n Protection architecture
• 1.2. Path priority
• 1.3. Preemption
• 1.4. Contributing authors
• 2. Conventions used in this document
• 2.1. Acronyms
• 2.2. Definitions and Terminology
• 3. Changes to PSC
• 3.1. PSC
• 3.2. Changes to PSC Payload
• 3.2.1. Acknowledge (K) flag
• 3.2.2. Fault path (FPath) field
• 3.2.3. Data path (Path) field
• 3.3. Changes to PSC Operation
• 3.3.1. Basic operation
• 3.3.2. Two-phased operation
• 3.3.3. Acknowledge message
• 3.3.4. Wait for Acknowledge (Wfa) timer
• 3.3.5. Additional PSC State
• 3.3.5.1. Wait for Acknowledge (Wfa) State
• 4. IANA Considerations
• 5. Security Considerations
• 6. Acknowledgements
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Appendix A. PSC state machine tables
• Authors' Addresses

1. Introduction

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

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

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

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

1.1. 1:n Protection architecture

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

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

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

   		  

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

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

1.2. Path priority

As the 1:n architecture requires the ability for one working path to preempt the traffic of another in the event of multiple failures (see Section 1.3), there must be an indication of priority between the different working paths so that an implementation can decide whether a new failure should be allowed to preempt a protection switch already in place. This priority is purely a local decision, i.e., determined by configuration at both endpoints of the protection domain. It is also possible to assign the same priority to multiple working paths, thus creating a "first come first served" preemption policy. This document provides no means to signal the priority of a given working path, nor a means to detect priority mismatches or misconfigurations. Any mismatch or misconfiguration will likely result in unexpected protection behavior.

1.3. Preemption

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

There are two basic scenarios for preemption of traffic –

1. When the protection path is used to transport "extra traffic". While this practice is discouraged by [TPReq], it is still not precluded. When the protection domain triggers a protection switch, the extra traffic should be preempted to allow the transport of the protected traffic from the working path that triggered the switching operation. The subsequent treatment of the interrupted service is out of the scope of this document.
2. When the protection path is transporting traffic from a working path and a second working path triggers a switching condition. This second trigger may either be a trigger with a higher priority (e.g. FS after a SF) or because the operator had assigned a higher priority to the working path of the second trigger. At this point, the traffic for the lower priority working path will be interrupted, and the higher priority traffic will be transmitted on the protection path. The preempted traffic will only renew transmission, when either the working path recovers, or the higher priority traffic relinquishes control of the protection path.

1.4. Contributing authors

Nurit Sprecher (NSN)

2. Conventions used in this document

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

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] and further adapted for MPLS-TP in [SurvivFwk]. In addition, we use the term LER to refer to a MPLS-TP Network Element, whether it is a LSR, LER, T-PE, or S-PE.

3. Changes to PSC

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

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

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

3.1. PSC

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

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

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

3.2. Changes to PSC Payload

In order to support 1:n protection there is a need to make changes to the format of the PSC payload (see Figure 3). In particular, there is the need to add a new field to the payload to indicate an acknowledge of a protection switching operation. In addition, the semantics of the FPath and Path field are adjusted to indicate an index of the multiple working paths. The details of these changes are supplied in the following subsections.

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

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

3.2.1. Acknowledge (K) flag

The Acknowledge flag is used by an endpoint to acknowledge the request to preempt any current traffic on the parotection path and instead transmit the traffic from the requested working path. See details in section x.y.

3.2.2. Fault path (FPath) field

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

• 0: indicates that the anomaly condition is on the protection path
• 1-128: indicates that the anomaly condition is on a working path whose index is indicated.
• 129-255: for future extensions or experimental use.

3.2.3. Data path (Path) field

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

• 0: indicates that the protection path is not transporting user data traffic.
• 1-128: indicates that the protection path is transmitting user traffic replacing the use of the working path indexed.
• 129-255: for future extensions or experimental use.

3.3. Changes to PSC Operation

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

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

3.3.1. Basic operation

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

3.3.2. Two-phased operation

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

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

• If the protection domain is currently in either Protecting administrative or Protecting failure state, then the endpoint SHALL verify that the new trigger has a higher priority than the currently protected traffic. If the new trigger has a lower priority then it SHOULD be ignored.
• The PSC message SHALL set the FPath value to the index of the working path that generated the trigger. The Path value SHOULD be set to 0, unless the protection path was previously transporting traffic from another working path (as indicated by the value of the Path field.
• If the protection path is currently transporting protected traffic, then the endpoint SHALL block all traffic of the protected working path.
• The endpoint SHALL transfer to Wfa state (see below).
• Upon reception of the switching PSC message, the far end LER SHALL verify that the received request is of higher priority than the known current traffic on the protection path, and if so SHALL interrupt the current traffic on the protection path, perform the switch to the requested protected traffic, and send an Acknowledge message (i.e. a PSC message with the Acknowledge flag set to 1) with the Path field set to the index of the protecteed working path.
• Upon reception of the Acknowledge message, the initiating LER SHALL perform the protection switch and transmit the appropriate PSC message, with the FPath field indicating the index of the working path that triggered the protection switch and the Path field set to the index of the working path whose traffic is being transported on the protection path.

3.3.3. Acknowledge message

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

1. A reply message with the Request field reflecting the state of the far end, and the Path field set to the index of the working path that triggered the switching condition. For example, if there is a Forced Switch command detected by LER-Z on working path #4, then LER-Z will have sent an FS(4,0) message to LER-A. Then when LER-Z receives a message such as NR(0,4)Ack this should be considered acknowledgement of the switching and that the protection path is available to switch the traffic from working path #4.
2. A remote message with the same Request field and FPath field as that transmitted by the LER in the Wfa state. For example, if there is a bi- directional Signal fault detected by LER-A on working path #2, then LER-A will enter Wfa state and transmit a SF(4,0) message. When it receives the SF(4,0) message from LER-Z, that has also detected the SF condition, it should be considered an acknowledgement of the switching and that the protection path is available to switch the traffic from working path #2.

3.3.4. Wait for Acknowledge (Wfa) timer

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

3.3.5. Additional PSC State

As described above, there is a need for the endpoint that is reporting on a trigger for protection-switching to delay the actual switchover until an acknowledge is received from the far end LER. In order to facilitate this wait period it is necessary to define a new PSC State - Wait for Acknowledge (Wfa) state. This state will be entered by the LER upon receiving a trigger for protection switching, and will be exited either upon receiving an acknowledge message or receiving a remote message indicating that the protection path is currently occupied by a higher priority request.

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

3.3.5.1. Wait for Acknowledge (Wfa) State

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

• A local Clear SHALL cause the LER to go into Normal state if the LER is in Wfa state due to either a FS or MS trigger and transmit an NR(0,0) PSC message. If the LER is in Wfa state due to a SF trigger then the local Clear SHALL be ignored.
• A local LO SHALL cause the LER to go into Unavailable state and begin to transmit LO(x, 0) [where x indicates the index of the working path that triggered the Wfa state].
• A local FS SHALL cause the LER to remain in Wfa state and transmit the FS(x, 0) message [where x indicates the index of the protected working path]. If the LER is in Wfa state due to a FS from a different working path, then the working path with the higher priority SHALL be the protected working path. If the LER is in Wfa state due to any other switching trigger, then the working path that is identified in this FS will be the protected working path.
• A local SF SHALL cause the LER to remain in Wfa state. If the LER is in Wfa state due to an existing FS trigger, then ignore the local SF and continue to transmit the FS(x, 0) PSC message. If the LER is in Wfa state due to an existing SF trigger then transmit the SF(x, 0) PSC message [where x indicates the index of protected working path, i.e. the highest priority working path indicating an SF condition]. If the LER is in Wfa state due to any other trigger, then begin transmitting a SF(x, 0) PSC message [where x indicates the index of the working path that is generating the SF condition].
• A local ClearSF indication where the working path is the same as the path that triggered the LER into Wfa state SHALL cause the LER to go into WTR state (note: 1:N protection is always revertive) and to transmit the WTR(0, 0) message. If the ClearSF indicates a different index from the protected working path or incates the protection path then the indication SHALL be ignored.
• A local MS operator command SHALL cause the LER to remain in Wfa state. If the LER is in Wfa state due an existing MS trigger, then the node continues to transmit MS(x, 0) messages [where x indicates the index of the protected working path, i.e. the highest prirority working path indicating the MS condition]. If the LER is in Wfa state due to any other trigger, ignore the MS command and continue transmitting the current message.
• If the Wfa timer expires, i.e. the LER did not receive the Acknowledge message from the far end in a timely manner, then the LER SHALL go to Unavailable state, i.e. it assumes that there is a problem on the protection path (where all PSC traffic is transmitted) and send an error notification to the management system. The LER SHALL continue transmitting the current PSC message with Path field set to 0.
• All other local indications SHALL be ignored.

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

• Any remote message with the Acknowledge flag set to 1 and the Path field set to the index of the protected working path SHALL cause the LER to change state. If the trigger was either FS or MS command, the LER enters Protecting administrative state. The LER transmits the appropriate message according to the trigger (i.e. FS(x,x) for FS command and MS(x,x) for the MS command). If the trigger was a SF condition, then the LER enters the Protecting failure state and begins to transmit the appropriate SF(x, x) message. A remote message with the Acknowledge flag set to 1 but where the Path field does not match, according to the description above, SHALL be ignored.
• A remote LO message SHALL cause the LER to go into Unavailable state and transmit the appropriate message for the trigger that caused the Wfa state.
• A remote FS message indicating the same working path as the local FS command that triggered the Wfa state SHALL be considered an Acknowledge message, even if the Acknowledge flag is not set. The LER SHALL perform the protection switch, and begin transmitting the FS(x, x) message [where x indicates the index of the protected working path]. If the remote FS message indicates a different index than the one indicated in the local FS and if the remote FS message indicates a lower priority working path than the working path in the local FS trigger then the LER SHALL ignore the remote FS message and remain in Wfa state. If the remote FS message indicates an index of higher priority or the LER is in Wfa state as a result of a SF or MS trigger, then the LER SHALL perform the protection switch for the protected working path indicated by the remote FS message, and SHALL go to Protecting administrative state and transmit the appropriate message for the local trigger with the Path field set to the index of the remote message and the Acknowledge flag set to 1.
• A remote SF message indicating an error on the protection path SHALL cause the LER to go into Unavailable stateand transmit the appropriate message for the trigger that caused to Wfa state.
• A remote SF message indicating an error on the same working path as the local SF condition that triggered the Wfa state SHALL be considered an Acknowledge message (even if the Acknowledge flag is not set). The LER SHALL perform the protection switch, go to Protecting failure state and transmit the SF(x, x) message [where x is the index of the protected working path]. If the remote SF message indicates a different index than the one indicated in the local SF, then if the local command indicates a higher priority working path the LER SHALL ignore the remote SF message and remain in Wfa state. If the remote SF message indicates an index of higher priority or the LER is in Wfa state as a result of a MS trigger, then the LER SHALL perform the protection switch for the protected working path indicated by the remote SF message, and SHALL go to Protecting failure state and transmit the appropriate message for the local trigger with the Path field set to the index of the remote message and the Acknowledge flag set to 1. If the LER is in Wfa state due to a local FS command, then it SHALL ignore the remote message and remain in Wfa state.
• A remote MS message indicating an error on the same working path as the local MS that triggered the Wfa state SHALL be considered an Acknowledge message (even if the Acknowledge flag is not set). The LER SHALL perform the protection switch, go to Protecting administrative state and transmit the MS(x, x) message [where x is the index of the protected working path]. If the remote MS message indicates a different index than the one indicated in the local MS, then if the local command indicates a higher priority working path or the LER is in Wfa due to either a FS or SF trigger, the LER SHALL ignore the remote MS message and remain in Wfa state. If the remote MS message indicates an index of higher priority, then the LER SHALL perform the protection switch for the protected working path indicated by the remote MS message, and SHALL go to Protecting administrative state and transmit an NR(0, y) with the Path field set to the index of the remote message and the Acknowledge flag set to 1.
• All other remote messages SHOULD be ignored.

4. IANA Considerations

This document does not include any required IANA considerations

5. Security Considerations

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

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

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

7. References

7.1. Normative References

7.2. Informative References

Appendix A. PSC state machine tables

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

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

Each state corresponds to the transmission of a particular set of Request, FPath and Path bits. The table below lists the message that is generally sent in each particular state. If the message to be sent in a particular state deviates from the table below, it is noted in the footnotes to the state-machine table.

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

and the remote inputs are:

Section 4.3.3 refers to some states as 'remote' and some as 'local'. By definition, all states listed in the table of local sources are local states, and all states listed in the table of remote sources are remote states. For example, section 4.3.3.1 says "A local Lockout of protection input SHALL cause the LER to go into local Unavailable State". As the trigger for this state change is a local one, 'local Unavailable State' is by definition displayed in the table of local sources. Similarly, "A remote Lockout of protection message SHALL cause the LER to go into remote Unavailable state" means that the state represented in the Unavailable rows in the table of remote sources is by definition a remote Unavailable state.

Each cell in the table below contains either a state, a footnote, or the letter 'i'. 'i' stands for Ignore, and is an indication to continue with the current behavior. See section 4.3.3. The footnotes are listed below the table.

Part 1: Local input state machine

           | OC  | LO    | SF-P | FS   | SF-W | SFc  | MS   | WTRExp
   --------+-----+-------+------+------+------+------+------+-------
   N       | i   |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i    |PA:M:L| i
   UA:LO:L | N   | i     | i    | i    | i    | i    | i    | i
   UA:P:L  | i   |UA:LO:L| i    | i    | i    | [5]  | i    | i
   UA:LO:R | i   |UA:LO:L| [1]  | i    | [2]  | [6]  | i    | i
   UA:P:R  | i   |UA:LO:L|UA:P:L| i    | [3]  | [6]  | i    | i
   PF:W:L  | i   |UA:LO:L|UA:P:L|PA:F:L| i    | [7]  | i    | i
   PF:W:R  | i   |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i    | i    | i
   PA:F:L  | N   |UA:LO:L|UA:P:L| i    | i    | i    | i    | i
   PA:M:L  | N   |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i    | i    | i
   PA:F:R  | i   |UA:LO:L|UA:P:L|PA:F:L| [4]  | [8]  | i    | i
   PA:M:R  | i   |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i    |PA:M:L| i
   WTR     | i   |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i    |PA:M:L| [9]
   DNR     | i   |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i    |PA:M:L| i
		  

Part 2: Remote messages state machine

           | LO    | SF-P | FS   | SF-W | MS   | WTR  | DNR  | NR
   --------+-------+------+------+------+------+------+------+------
   N       |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i    | i    | i
   UA:LO:L | i     | i    | i    | i    | i    | i    | i    | i
   UA:P:L  | [10]  | i    | i    | i    | i    | i    | i    | i
   UA:LO:R | i     | i    | i    | i    | i    | i    | i    | [16]
   UA:P:R  |UA:LO:R| i    | i    | i    | i    | i    | i    | [16]
   PF:W:L  | [11]  | [12] |PA:F:R| i    | i    | i    | i    | i
   PF:W:R  |UA:LO:R|UA:P:R|PA:F:R| i    | i    | [14] | [15] | N 
   PA:F:L  |UA:LO:R|UA:P:R| i    | i    | i    | i    | i    | i 
   PA:M:L  |UA:LO:R|UA:P:R|PA:F:R| [13] | i    | i    | i    | i 
   PA:F:R  |UA:LO:R|UA:P:R| i    | i    | i    | i    | i    | [17] 
   PA:M:R  |UA:LO:R|UA:P:R|PA:F:R| [13] | i    | i    | i    | N 
   WTR     |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i    | i    | [18]
   DNR     |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i    | i    | i 
		  

The following are the footnotes for the table:

[1] Remain in the current state (UA:LO:R) and transmit SF(0,0)

[2] Remain in the current state (UA:LO:R) and transmit SF(1,0)

[3] Remain in the current state (UA:P:R) and transmit SF(1,0)

[4] Remain in the current state (PA:F:R) and transmit SF(1,1)

[5] If the SF being cleared is SF-P, Transition to N. If it's SF-W, ignore the clear.

[6] Remain in current state (UA:x:R), if the SFc corresponds to a previous SF then begin transmitting NR(0,0).

[7] If domain configured for revertive behavior transition to WTR, else transition to DNR

[8] Remain in PA:F:R and transmit NR(0,1)

[9] Remain in WTR, send NR(0,1)

[10] Transition to UA:LO:R continue sending SF(0,0)

[11] Transition to UA:LO:R and send SF(1,0)

[12] Transition to UA and send SF(1,0)

[13] Transition to PF:W:R and send NR(0,1)

[14] Transition to WTR state and continue to send the current message.

[15] Transition to DNR state and continue to send the current message.

[16] If the local input is SF-P then transition to UA:P:L. If the local input is SF-W then transition to PF:W:L. Else - transition to N state and continue to send the current message.

[17] If the local input is SF-W then transition to PF:W:L. Else - transition to N state and continue to send the current message.

[18] If the receiving LER's WTR timer is running, maintain current state and message. If the WTR timer is stopped, transition to N.

Authors' Addresses