draft-ietf-mpls-tp-linear-protection-09.txt   rfc6378.txt 
Network Working Group S. Bryant Internet Engineering Task Force (IETF) Y. Weingarten, Ed.
Internet-Draft E. Osborne Request for Comments: 6378 Nokia Siemens Networks
Intended status: Standards Track Cisco Category: Standards Track S. Bryant
Expires: February 4, 2012 N. Sprecher ISSN: 2070-1721 E. Osborne
Cisco
N. Sprecher
Nokia Siemens Networks Nokia Siemens Networks
A. Fulignoli, Ed. A. Fulignoli, Ed.
Ericsson Ericsson
Y. Weingarten, Ed. October 2011
Nokia Siemens Networks
August 3, 2011
MPLS-TP Linear Protection MPLS Transport Profile (MPLS-TP) Linear Protection
draft-ietf-mpls-tp-linear-protection-09.txt
Abstract 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] 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 This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications (IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge
capabilities and functionalities of a packet transport network as (PWE3) architectures to support the capabilities and functionalities
defined by the ITU-T. of a packet transport network as defined by the ITU-T.
Status of this Memo This document addresses the functionality described in the MPLS-TP
Survivability Framework document (RFC 6372) and defines a protocol
that may be used to fulfill the function of the Protection State
Coordination for linear protection, as described in that document.
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on February 4, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6378.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................4
1.1. Protection architectures . . . . . . . . . . . . . . . . . 4 1.1. Protection Architectures ...................................4
1.2. Scope of the document . . . . . . . . . . . . . . . . . . 5 1.2. Scope of the Document ......................................5
1.3. Contributing authors . . . . . . . . . . . . . . . . . . . 6 2. Conventions Used in This Document ...............................6
2. Conventions used in this document . . . . . . . . . . . . . . 6 2.1. Acronyms ...................................................6
2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Definitions and Terminology ................................7
2.2. Definitions and Terminology . . . . . . . . . . . . . . . 7 3. Protection State Control Logic ..................................7
3. Protection switching control logic . . . . . . . . . . . . . . 7 3.1. Local Request Logic ........................................9
3.1. Local Request Logic . . . . . . . . . . . . . . . . . . . 8 3.2. Remote Requests ...........................................11
3.2. Remote Requests . . . . . . . . . . . . . . . . . . . . . 10 3.3. PSC Control Logic .........................................12
3.3. PSC Control Logic . . . . . . . . . . . . . . . . . . . . 11 3.4. PSC Message Generator .....................................12
3.4. PSC Message Generator . . . . . . . . . . . . . . . . . . 12 3.5. Wait-to-Restore (WTR) Timer ...............................12
3.5. Wait-to-Restore (WTR) timer . . . . . . . . . . . . . . . 12 3.6. PSC Control States ........................................13
3.6. PSC Control States . . . . . . . . . . . . . . . . . . . . 12 3.6.1. Local and Remote State .............................14
3.6.1. Local and Remote state . . . . . . . . . . . . . . . . 14 4. Protection State Coordination (PSC) Protocol ...................14
4. Protection state coordination (PSC) protocol . . . . . . . . . 14 4.1. Transmission and Acceptance of PSC Control Packets ........15
4.1. Transmission and acceptance of PSC control packets . . . . 15 4.2. Protocol Format ...........................................16
4.2. Protocol format . . . . . . . . . . . . . . . . . . . . . 15 4.2.1. PSC Ver Field ......................................16
4.2.1. PSC Ver field . . . . . . . . . . . . . . . . . . . . 16 4.2.2. PSC Request Field ..................................17
4.2.2. PSC Request field . . . . . . . . . . . . . . . . . . 16 4.2.3. Protection Type (PT) Field .........................18
4.2.3. Protection Type (PT) . . . . . . . . . . . . . . . . . 18 4.2.4. Revertive (R) Field ................................18
4.2.4. Revertive (R) field . . . . . . . . . . . . . . . . . 18 4.2.5. Fault Path (FPath) Field ...........................19
4.2.5. Fault path (FPath) field . . . . . . . . . . . . . . . 18 4.2.6. Data Path (Path) Field .............................19
4.2.6. Data path (Path) field . . . . . . . . . . . . . . . . 19 4.2.7. Additional TLV Information .........................19
4.2.7. Additional TLV information . . . . . . . . . . . . . . 19 4.3. Principles of Operation ...................................20
4.3. Principles of Operation . . . . . . . . . . . . . . . . . 19 4.3.1. Basic Operation ....................................20
4.3.1. Basic operation . . . . . . . . . . . . . . . . . . . 20 4.3.2. Priority of Inputs .................................21
4.3.2. Priority of inputs . . . . . . . . . . . . . . . . . . 21 4.3.3. Operation of PSC States ............................22
4.3.3. Operation of PSC States . . . . . . . . . . . . . . . 22 5. IANA Considerations ............................................33
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 5.1. Pseudowire Associated Channel Type ........................33
5.1. Pseudowire Associated Channel Type . . . . . . . . . . . . 32 5.2. PSC Request Field .........................................33
5.2. PSC Request Field . . . . . . . . . . . . . . . . . . . . 33 5.3. Additional TLVs ...........................................34
5.3. Additional TLVs . . . . . . . . . . . . . . . . . . . . . 33 6. Security Considerations ........................................34
6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 7. Acknowledgements ...............................................35
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 8. Contributing Authors ...........................................36
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 9. References .....................................................37
8.1. Normative References . . . . . . . . . . . . . . . . . . . 35 9.1. Normative References ......................................37
8.2. Informative References . . . . . . . . . . . . . . . . . . 35 9.2. Informative References ....................................37
Appendix A. PSC state machine tables . . . . . . . . . . . . . . 36 Appendix A. PSC State Machine Tables ..............................39
Appendix B. Exercising the protection domain . . . . . . . . . . 40 Appendix B. Exercising the Protection Domain ......................44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
The MPLS Transport Profile (MPLS-TP) [TPFwk] is a framework for the The MPLS Transport Profile (MPLS-TP) [RFC5921] is a framework for the
construction and operation of packet-switched transport networks construction and operation of packet-switched transport networks
based on the architectures for MPLS ([RFC3031] and [RFC3032]) and for based on the architectures for MPLS ([RFC3031] and [RFC3032]) and for
Pseudowires (PWs) ([RFC3985] and [RFC5659]) and the requirements of Pseudowires (PWs) ([RFC3985] and [RFC5659]) and the requirements of
[RFC5654]. [RFC5654].
Network survivability is the ability of a network to recover traffic Network survivability is the ability of a network to recover traffic
delivery following failure, or degradation of network resources. The delivery following failure, or degradation, of network resources.
MPLS-TP Survivability Framework [SurvivFwk] is a framework for The MPLS-TP Survivability Framework [RFC6372] is a framework for
survivability in MPLS-TP networks, and describes recovery elements, survivability in MPLS-TP networks, and describes recovery elements,
types, methods, and topological considerations, focusing on types, methods, and topological considerations, focusing on
mechanisms for recovering MPLS-TP Label Switched Paths (LSPs). mechanisms for recovering MPLS-TP Label Switched Paths (LSPs).
Linear protection in mesh networks - networks with arbitrary Linear protection in mesh networks -- networks with arbitrary
interconnectivity between nodes - is described in Section 4.7 of interconnectivity between nodes -- is described in Section 4.7 of
[SurvivFwk]. Linear protection provides rapid and simple protection [RFC6372]. Linear protection provides rapid and simple protection
switching. In a mesh network, linear protection provides a very switching. In a mesh network, linear protection provides a very
suitable protection mechanism because it can operate between any pair suitable protection mechanism because it can operate between any pair
of points within the network. It can protect against a defect in an 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 intermediate node, a span, a transport path segment, or an end-to-end
transport path. transport path.
1.1. Protection architectures 1.1. Protection Architectures
Protection switching is a fully allocated survivability mechanism. Protection switching is a fully allocated survivability mechanism.
It is fully allocated in the sense that the route and resources of It is fully allocated in the sense that the route and resources of
the protection path are reserved for a selected working path or set the protection path are reserved for a selected working path or set
of working paths. It provides a fast and simple survivability of working paths. It provides a fast and simple survivability
mechanism, that allows the network operator to easily grasp the mechanism that allows the network operator to easily grasp the active
active state of the network, that can operate between any pair of state of the network and that can operate between any pair of points
points within the network. within the network.
As described in the Survivability Framework document [SurvivFwk], As described in the Survivability Framework document [RFC6372],
protection switching is applied to a protection domain. For the protection switching is applied to a protection domain. For the
purposes of this document, we define the protection domain of a purposes of this document, we define the protection domain of a
point-to-point LSP as consisting of two Label Edge Routers (LER) and point-to-point LSP as consisting of two Label Edge Routers (LERs) and
the transport paths that connect them (see Figure 3 below). For a the transport paths that connect them (see Figure 3). For a point-
point-to-multipoint LSP the protection domain includes the root (or to-multipoint LSP, the protection domain includes the root (or
source) LER, the destination (or sink) LERs, and the transport paths source) LER, the destination (or sink) LERs, and the transport paths
that connect them. that connect them.
In 1+1 unidirectional architecture as presented in [SurvivFwk], a In 1+1 unidirectional architecture as presented in [RFC6372], a
protection transport path is dedicated to the working transport path. protection transport path is dedicated to the working transport path.
Normal traffic is bridged (as defined in [RFC4427])and fed to both Normal traffic is bridged (as defined in [RFC4427]) and fed to both
the working and the protection paths by a permanent bridge at the the working and the protection paths by a permanent bridge at the
source of the protection domain. The sink of the protection domain source of the protection domain. The sink of the protection domain
uses a selector to select either the working or protection paths to uses a selector to choose either the working or protection path from
receive the traffic from, based on a predetermined criteria, e.g. which to receive the traffic, based on predetermined criteria, e.g.,
server defect indication. When used for bidirectional switching the server defect indication. When used for bidirectional switching the
1+1 protection architecture must also support a Protection State 1+1 protection architecture must also support a Protection State
Coordination (PSC) protocol. This protocol is used to help Coordination (PSC) protocol. This protocol is used to help
coordinate between both ends of the protection domain in selecting coordinate between both ends of the protection domain in selecting
the proper traffic flow. the proper traffic flow.
In the 1:1 architecture, a protection transport path is dedicated to In the 1:1 architecture, a protection transport path is dedicated to
the working transport path of a single service and the traffic is the working transport path of a single service, and the traffic is
only transmitted either on the working or the protection path, by only transmitted on either the working or the protection path, by
using a selector at the source of the protection domain. A selector using a selector at the source of the protection domain. A selector
at the sink of the protection domain then selects the path that at the sink of the protection domain then selects the path that
carries the normal traffic. Since the source and sink need to be carries the normal traffic. Since the source and sink need to be
coordinated to ensure that the selector at both ends select the same coordinated to ensure that the selector at both ends select the same
path, this architecture must support a PSC protocol. path, this architecture must support a PSC protocol.
The 1:n protection architecture extends the 1:1 architecture above by The 1:n protection architecture extends the 1:1 architecture above by
sharing the protection path among n services. Again, the protection sharing the protection path among n services. Again, the protection
path is fully allocated and disjoint from any of the n working path is fully allocated and disjoint from any of the n working
transport paths that it is being used to protect. The normal data transport paths that it is being used to protect. The normal data
traffic for each service is transmitted either on the normal working traffic for each service is transmitted either on the normal working
path for that service or, in cases that trigger protection switching path for that service or, in cases that trigger protection switching
(as listed in [SurvivFwk]), may be sent on the protection path. The (as listed in [RFC6372]), may be sent on the protection path. The
switching action is similar to the 1:1 case where a selector is used switching action is similar to the 1:1 case where a selector is used
at the source. It should be noted that in cases where multiple at the source. In cases where multiple working path services have
working path services have triggered protection switching that some triggered protection switching, it should be noted that some
services, dependent upon their Service Level Agreement (SLA), may not services, dependent upon their Service Level Agreement (SLA), may not
be transmitted as a result of limited resources on the protection be transmitted as a result of limited resources on the protection
path. In this architecture there may be a need for coordination of path. In this architecture, there may be a need for coordination of
the protection switching, and also for resource allocation the protection switching and for resource allocation negotiation.
negotiation. The procedures for this are for further study and may The procedures for this are for further study and may be addressed in
be addressed in future documents. future documents.
1.2. Scope of the document 1.2. Scope of the Document
As was pointed out in the Survivability Framework [SurvivFwk] and As was pointed out in the Survivability Framework [RFC6372] and
highlighted above, there is a need for coordination between the end highlighted above, there is a need for coordination between the end
points of the protection domain when employing bidirectional points of the protection domain when employing bidirectional
protection schemes. This is especially true when there is a need to protection schemes. This is especially true when there is a need to
verify that the traffic continues to be transported on a bi- verify that the traffic continues to be transported on a
directional LSP that is co-routed. bidirectional LSP that is co-routed.
The scope of this draft is to present a protocol for the Protection The scope of this document is to present a protocol for the
State Coordination of Linear Protection. The protocol addresses the Protection State Coordination of Linear Protection. The protocol
protection of LSPs in an MPLS-TP network as required by [RFC5654] (in addresses the protection of LSPs in an MPLS-TP network as required by
particular requirements 63-65 and 74-79) and described in [RFC5654] (in particular, requirements 63-65 and 74-79) and described
[SurvivFwk]. The basic protocol is designed for use in conjunction in [RFC6372]. The basic protocol is designed for use in conjunction
with the 1:1 protection architecture bidirectional protection and for with the 1:1 protection architecture, bidirectional protection, and
1+1 protection of a bidirectional path (for both unidirectional and for 1+1 protection of a bidirectional path (for both unidirectional
bidirectional protection switching). Applicability of the protocol and bidirectional protection switching). Applicability of the
for 1:1 unidirectional protection and for 1:n protection schemes may protocol for 1:1 unidirectional protection and for 1:n protection
be documented in a future document and are out of scope for this schemes may be documented in a future document and is out of scope
document. The applicability of this protocol to additional MPLS-TP for this document. The applicability of this protocol to additional
constructs and topologies may be documented in future documents. MPLS-TP constructs and topologies may be documented in future
documents.
While the unidirectional 1+1 protection architecture does not require While the unidirectional 1+1 protection architecture does not require
the use of a coordination protocol, the protocol may be used by the 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 ingress node of the path to notify the far-side end point that a
switching condition has occurred and verify the consistency of the switching condition has occurred and verify the consistency of the
end point configuration. This use may be especially useful for end-point configuration. This use may be especially useful for
point-to-multipoint transport paths, that are unidirectional by point-to-multipoint transport paths, that are unidirectional by
definition of [RFC5654]. The use of this protocol for point-to- definition of [RFC5654]. The use of this protocol for point-to-
multipoint paths is out of scope for this document and may be multipoint paths is out of scope for this document and may be
addressed in a future applicability document. addressed in a future applicability document.
1.3. Contributing authors 2. Conventions Used in This Document
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", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2.1. Acronyms 2.1. Acronyms
This draft uses the following acronyms: This document uses the following acronyms:
DNR Do not revert CT Channel Type
DNR Do-not-Revert
FS Forced Switch FS Forced Switch
G-ACh Generic Associated Channel G-ACh Generic Associated Channel
LER Label Edge Router LER Label Edge Router
LO Lockout of protection LO Lockout of protection
LSR Label Switching Router
MEG Managed Entity Group
MEP MEG End Point
MPLS-TP Transport Profile for MPLS MPLS-TP Transport Profile for MPLS
MS Manual Switch MS Manual Switch
NR No Request NR No Request
OAM Operations, Administration, and Maintenance
PSC Protection State Coordination Protocol PSC Protection State Coordination Protocol
S-PE Switching Provider Edge
SD Signal Degrade SD Signal Degrade
SF Signal Fail SF Signal Fail
SFc Clear Signal Fail
SLA Service Level Agreement SLA Service Level Agreement
T-PE Terminating Provider Edge
WTR Wait-to-Restore WTR Wait-to-Restore
2.2. Definitions and Terminology 2.2. Definitions and Terminology
The terminology used in this document is based on the terminology The terminology used in this document is based on the terminology
defined in [RFC4427] and further adapted for MPLS-TP in [SurvivFwk]. defined in [RFC4427] and further adapted for MPLS-TP in [RFC6372].
In addition, we use the term LER to refer to a MPLS-TP Network In addition, we use the term "LER" to refer to an MPLS-TP Network
Element, whether it is a LSR, LER, T-PE, or S-PE. Element, whether it is an LSR, LER, T-PE, or S-PE.
3. Protection switching control logic 3. Protection State Control Logic
Protection switching processes the local triggers described in Protection switching processes the local triggers described in
requirements 74-79 of [RFC5654] together with inputs received from requirements 74-79 of [RFC5654] together with inputs received from
the far-end LER. Based on these inputs the LER will take certain the far-end LER. Based on these inputs, the LER will take certain
protection switching actions, e.g. switching the selector to transmit protection switching actions, e.g., switching the selector to
on the working or protection path for 1:1 protection or switching the transmit on the working or protection path for 1:1 protection or
selector to receive the traffic for either 1:1 or 1+1 protection, and switching the selector to receive the traffic for either 1:1 or 1+1
transmit different protocol messages. protection and transmit different protocol messages.
The following figure shows the logical decomposition of the The following figure shows the logical decomposition of the
Protection Switching Control Logic into different logical processing Protection State Control logic into different logical processing
units. These processing units are presented in subsequent units. These processing units are presented in subsequent
subsections of this document. This logical decomposition is only subsections of this document. This logical decomposition is only
intended for descriptive purposes, any implementation that produces intended for descriptive purposes; any implementation that produces
the external behavior described in section 4 is acceptable. the external behavior described in Section 4 is acceptable.
Server Indication Control Plane Indication Server Indication Control-Plane Indication
-----------------+ +------------- -----------------+ +-------------
Operator Command | | OAM Indication Operator Command | | OAM Indication
----------------+ | | +--------------- ----------------+ | | +---------------
| | | | | | | |
V V V V V V V V
+---------------+ +-------+ +---------------+ +-------+
| Local Request |<--------| WTR | | Local Request |<--------| WTR |
| logic |WTR Exps | Timer | | logic |WTR Exps | Timer |
+---------------+ +-------+ +---------------+ +-------+
| ^ | ^
skipping to change at page 8, line 31 skipping to change at page 8, line 31
Request +-----------------+ Request +-----------------+
| |
| Action +------------+ | Action +------------+
+---------------->| Message | +---------------->| Message |
| Generator | | Generator |
+------------+ +------------+
| |
Output PSC | Message Output PSC | Message
V V
Figure 1: Protection switching control logic Figure 1: Protection State Control Logic
Figure 1 describes the logical architecture of the protection Figure 1 describes the logical architecture of the protection
switching control. The Local Request logic unit accepts the triggers switching control. The Local Request logic unit accepts the triggers
from the OAM, external operator commands, from the local control from the OAM, server layer, external operator commands, local control
plane (when present), and the Wait-to-Restore timer. By considering plane (when present), and the Wait-to-Restore timer. By considering
all of these local request sources it determines the highest priority all of these local request sources, it determines the highest
local request. This high-priority request is passed to the PSC priority local request. This high-priority request is passed to the
Control logic, that will cross-check this local request with the PSC Control logic, that will cross-check this local request with the
information received from the far-end LER. The PSC Control logic information received from the far-end LER. The PSC Control logic
uses this input to determine what actions need to be taken, e.g. 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- local actions at the LER, or what message should be sent to the far-
end LER, and the current status of the protection domain. end LER, and the current status of the protection domain.
3.1. Local Request Logic 3.1. Local Request Logic
The Local Request logic processes input triggers from five sources: The Local Request logic processes input triggers from five sources.
o Operator command - the network operator may issue local o Operator command - the network operator may issue local
administrative commands on the LER that trigger protection administrative commands on the LER that trigger protection
switching. The commands Forced Switch, Manual Switch, Clear, switching. The commands Forced Switch, Manual Switch, Clear,
Lockout of Protection (see definitions in [RFC4427]) MUST be Lockout of protection (defined in [RFC4427] as Forced switch-over,
supported. An implementation MAY provide additional commands for Manual switch-over, Clear, and Lockout of recovery LSP/span,
operator use; providing that these commands do not introduce respectively) MUST be supported. An implementation MAY provide
incompatable behavior between two arbitrary implementations, they additional commands for operator use; providing that these
are outside the scope of this document. For example, an commands do not introduce incompatible behavior between two
implementation could provide a command to manually trigger a "WTR arbitrary implementations, they are outside the scope of this
expires" trigger (see below) input without waiting for the document. For example, an implementation could provide a command
duration of the WTR timer; as this merely hastens the transition to manually set off a "WTR Expires" trigger (see below) input
from one state to another and has no impact on the state machine without waiting for the duration of the WTR timer; as this merely
itself, it would be perfectly valid. hastens the transition from one state to another and has no impact
on the state machine itself, it would be perfectly valid.
o Server layer alarm indication - the underlying server layer of the o Server-layer alarm indication - the underlying server layer of the
network detects failure conditions at the underlying layer and may network detects failure conditions at the underlying layer and may
issue an indication to the MPLS-TP layer. The server layer may issue an indication to the MPLS-TP layer. The server layer may
employ its own protection switching mechanism, and therefore this employ its own protection switching mechanism; therefore, this
input MAY be controlled by a holdoff-timer that SHOULD be input MAY be controlled by a hold-off timer that SHOULD be
configurable by the network operator. The holdoff-timer is configurable by the network operator. The hold-off timer is
described in greater detail in [SurvivFwk]. described in greater detail in [RFC6372].
o Control plane - if there is a control plane active in the network o Control-Plane Indication - if there is a control plane active in
(either signaling or routing), it MAY trigger protection switching the network (either signaling or routing), it MAY trigger
based on conditions detected by the control plane. If the control protection switching based on conditions detected by the control
plane is based on GMPLS [RFC3945] then the recovery process SHALL plane. If the control plane is based on GMPLS [RFC3945], then the
comply with the process described in [RFC4872] and [RFC4873]. recovery process SHALL comply with the process described in
[RFC4872] and [RFC4873].
o OAM indication - OAM fault management or performance measurement o OAM indication - OAM fault management or performance measurement
tools may detect a failure or degrade condition on either the tools may detect a failure or degrade condition on either the
working or protection transport path and this MUST input an working or protection transport path, and this MUST input an
indication to the Local Request Logic. indication to the Local Request logic.
o WTR expires - The Wait-to-Restore timer is used in conjunction o WTR Expires - The Wait-to-Restore timer is used in conjunction
with recovery from failure conditions on the working path in with recovery from failure conditions on the working path in
revertive mode. The timer SHALL signal the PSC control process revertive mode. The timer SHALL signal the PSC control process
when it expires and the end point SHALL revert to the normal when it expires, and the end point SHALL revert to the normal
transmission of the user data traffic. transmission of the user data traffic.
The input from these sources SHOULD be retained persistently for the The input from these sources SHOULD be retained persistently for the
duration of condition that initiated the trigger. The Local request duration of the condition that initiated the trigger. The Local
logic processes these different input sources and, based on the Request logic processes these different input sources and, based on
priorities between them (see section 4.3.2), produces a current local the priorities between them (see Section 4.3.2), produces a current
request. If more than one local input source generates a trigger, local request. If more than one local input source generates a
then the Local request logic selects the higher priority indicator trigger, then the Local Request logic selects the higher priority
and ignores any lower priority indicator. As a result, there is a indicator and ignores any lower priority indicator. As a result,
single current local request that is passed to the PSC Control logic. there is a single current local request that is passed to the PSC
The different local requests that may be output from the Local Control logic. The different local requests that may be output from
Request Logic are: the Local Request logic are as follows:
o Clear - if the operator cancels an active local administrative o Clear - if the operator cancels an active local administrative
command, i.e. LO/FS/MS. command, i.e., LO/FS/MS.
o Lockout of Protection (LO) - if the operator requested to prevent o Lockout of protection (LO) - if the operator requested to prevent
switching data traffic to the protection path, for any purpose. switching data traffic to the protection path, for any purpose.
o Signal Fail (SF) - if any of the Server Layer, Control plane, or o Signal Fail (SF) - if any of the server-layer, control-plane, or
OAM indications signaled a failure condition on either the OAM indications signaled a failure condition on either the
protection path or one of the working paths. protection path or one of the working paths.
o Signal Degrade (SD) - if any of the Server Layer, Control plane, o Signal Degrade (SD) - if any of the server-layer, control-plane,
or OAM indications signaled a degraded transmission condition on or OAM indications signaled a degraded transmission condition on
either the protection path or one of the working paths. The either the protection path or one of the working paths. The
determination and actions for SD are for further study and may determination and actions for SD are for further study and may
appear in a separate document. All references to SD input are appear in a separate document. All references to SD input are
place-holders for this extension. placeholders for this extension.
o Clear Signal Fail (SFc) - if all of the Server Layer, Control o Clear Signal Fail (SFc) - if all of the server-layer, control-
plane, or OAM indications are no longer indicating a failure plane, or OAM indications are no longer indicating a failure
condition on a path that was previously indicating a failure condition on a path that was previously indicating a failure
condition. condition.
o Forced Switch (FS) - if the operator requested that traffic be o Forced Switch (FS) - if the operator requested that traffic be
switched from one of the working paths to the protection path. switched from one of the working paths to the protection path.
o Manual Switch (MS) - if the operator requested that traffic be o Manual Switch (MS) - if the operator requested that traffic be
switched from the working path to the protection path. This is switched from the working path to the protection path. This is
only relevant if there is no currently active fault condition or only relevant if there is no currently active fault condition or
Operator command. operator command.
o WTR Expires - generated by the WTR timer completing its period. o WTR Expires (WTRExp) - generated by the WTR timer completing its
period.
If none of the input sources have generated any input then the Local If none of the input sources have generated any triggers, then the
request logic should generate a No Request (NR) request as the Local Request logic should generate a No Request (NR) as the current
current local request . local request.
3.2. Remote Requests 3.2. Remote Requests
In addition to the local requests, generated as a result of the local In addition to the local requests, generated as a result of the local
triggers, indicated in the previous subsection, the PSC Control Logic triggers, indicated in the previous subsection, the PSC Control logic
SHALL accept PSC messages from the far-end LER of the transport path. SHALL accept PSC messages from the far-end LER of the transport path.
Remote messages indicate the status of the transport path from the Remote messages indicate the status of the transport path from the
viewpoint of the far-end LER. These messages may drive state changes viewpoint of the far-end LER. These messages may drive state changes
on the local MEP, as defined later in this document. When using 1+1 on the local MEP, as defined later in this document. When using 1+1
unidirectional protection, an LER that receives a remote request unidirectional protection, an LER that receives a remote request
SHALL NOT perform any protection switching action, i.e. will continue SHALL NOT perform any protection switching action, i.e., will
to select traffic from the working path and transport traffic on both continue to select traffic from the working path and transport
paths. traffic on both paths.
The following remote requests may be received by the PSC process: The following remote requests may be received by the PSC process:
o Remote LO - indicates that the remote end point is in Unavailable o Remote LO - indicates that the remote end point is in Unavailable
state due to a Lockout of Protection operator command. state due to a Lockout of protection operator command.
o Remote SF - indicates that the remote end point has detected a o Remote SF - indicates that the remote end point has detected a
Signal Fail condition on one of the transport paths in the Signal Fail condition on one of the transport paths in the
protection domain. This remote message includes an indication of protection domain. This remote message includes an indication of
which transport path is affected by the SF condition. In which transport path is affected by the SF condition. In
addition, it should be noted that the SF condition may be either a addition, it should be noted that the SF condition may be either a
unidirectional or a bidirectional failure, even if the transport unidirectional or a bidirectional failure, even if the transport
path is bidirectional. path is bidirectional.
o Remote SD - indicates that the remote end point has detected a o Remote SD - indicates that the remote end point has detected a
skipping to change at page 11, line 48 skipping to change at page 12, line 16
that the failure condition has recovered and will continue that the failure condition has recovered and will continue
transporting traffic on the protection path due to operator transporting traffic on the protection path due to operator
configuration that prevents automatic reversion to the Normal configuration that prevents automatic reversion to the Normal
state. state.
o Remote NR - indicates that the remote end point has no abnormal o Remote NR - indicates that the remote end point has no abnormal
condition to report. condition to report.
3.3. PSC Control Logic 3.3. PSC Control Logic
The PSC Control Logic accepts the following input - The PSC Control logic accepts the following input:
a. the current local request output from the Local Request Logic a. the current local request output from the Local Request logic
(see Section 3.1), (see Section 3.1),
b. the remote request message from the remote end point of the b. the remote request message from the remote end point of the
transport path (see Section 3.2), and transport path (see Section 3.2), and
c. the current state of the PSC Control Logic (maintained internally c. the current state of the PSC Control logic (maintained internally
by the PSC Control Logic). by the PSC Control logic).
Based on the priorities between the different inputs, the PSC Control Based on the priorities between the different inputs, the PSC Control
Logic determines the new state of the PSC Control Logic and what logic determines the new state of the PSC Control logic and what
actions need to be taken. actions need to be taken.
The new state information is retained by the PSC Control Logic, while The new state information is retained by the PSC Control logic, while
the requested action should be sent to the PSC Message Generator (see the requested action should be sent to the PSC Message Generator (see
Section 3.4) to generate and transmit the proper PSC message to be Section 3.4) to generate and transmit the proper PSC message to be
transmitted to the remote end point of the protection domain. transmitted to the remote end point of the protection domain.
3.4. PSC Message Generator 3.4. PSC Message Generator
Based on the action output from the PSC Control Logic this unit Based on the action output from the PSC Control logic, this unit
formats the PSC protocol message that is transmitted to the remote formats the PSC protocol message that is transmitted to the remote
end point of the protection domain. This message may either be the end point of the protection domain. This message may either be the
same as the previously transmitted message or change when the PSC same as the previously transmitted message or change when the PSC
control state (see section 3.6) has changed. The messages are control state (see Section 3.6) has changed. The messages are
transmitted as described in section 4.1 of this document. transmitted as described in Section 4.1 of this document.
3.5. Wait-to-Restore (WTR) timer 3.5. Wait-to-Restore (WTR) Timer
The WTR timer is used to delay reversion to Normal state when The WTR timer is used to delay reversion to Normal state when
recovering from a failure condition on the working path and the recovering from a failure condition on the working path and the
protection domain is configured for revertive behavior. The length protection domain is configured for revertive behavior. The length
of the timer may be provisioned by the operator. The WTR may be in of the timer may be provisioned by the operator. The WTR may be in
one of two states - either Running or Stopped. The control of the one of two states: Running or Stopped. The control of the WTR timer
WTR timer is managed by the PSC Control Logic, by use of internal is managed by the PSC Control logic, by use of internal signals to
signals to start and stop, i.e. reset, the WTR timer. start and stop, i.e., reset, the WTR timer.
If the WTR timer expires prior to being stopped it SHALL generate a If the WTR timer expires prior to being stopped, it SHALL generate a
WTR Expires local signal that is processed by the Local Request WTR Expires local signal that is processed by the Local Request
Logic. If the WTR timer is running, sending a Stop command SHALL logic. If the WTR timer is running, sending a Stop command SHALL
reset the timer, and put the WTR timer into Stopped state, but SHALL reset the timer, and put the WTR timer into Stopped state, but SHALL
NOT generate a WTR Expires local signal. If the WTR timer is NOT generate a WTR Expires local signal. If the WTR timer is
stopped, a Stop command SHALL be ignored. stopped, a Stop command SHALL be ignored.
3.6. PSC Control States 3.6. PSC Control States
The PSC Control Logic should maintain information on the current The PSC Control logic should maintain information on the current
state of the protection domain. Information on the state of the state of the protection domain. Information on the state of the
domain is maintained by each LER within the protection domain. The domain is maintained by each LER within the protection domain. The
state information would include information of the current state of state information would include information of the current state of
the protection domain, an indication of the cause for the current the protection domain, an indication of the cause for the current
state (e.g. unavailable due to local LO command, protecting due to state (e.g., unavailable due to local LO command, protecting due to
remote FS), and, for each LER, should include an indication if the remote FS), and, for each LER, should include an indication if the
state is related to a remote or local condition. state is related to a remote or local condition.
It should be noted that when referring to the "transport" of the data It should be noted that when referring to the "transport" of the data
traffic, in the following descriptions and later in the document that traffic, in the following descriptions and later in the document that
the data will be transmitted on both the working and the protection the data will be transmitted on both the working and the protection
paths when using 1+1 protection, and on either the working or the paths when using 1+1 protection, and on either the working or the
protection path exclusively when using 1:1 protection. When using protection path exclusively when using 1:1 protection. When using
1+1 protection, the receiving LER should select the proper 1+1 protection, the receiving LER should select the proper
transmission, according to the state of the protection domain. transmission, according to the state of the protection domain.
The protection domain states that are supported by the PSC Control The protection domain states that are supported by the PSC Control
Logic are: logic are as follows:
o Normal state - Both the protection and working paths are fully o Normal state - Both the protection and working paths are fully
allocated and active, data traffic is being transported over (or allocated and active, data traffic is being transported over (or
selected from) the working path, and no trigger events are selected from) the working path, and no trigger events are
reported within the domain. reported within the domain.
o Unavailable state - The protection path is unavailable - either as o Unavailable state - The protection path is unavailable -- either
a result of an operator Lockout command or a failure condition as a result of an operator Lockout command or a failure condition
detected on the protection path. detected on the protection path.
o Protecting failure state - The working path has reported a o Protecting failure state - The working path has reported a
failure/degrade condition and the user traffic is being failure/degrade condition and the user traffic is being
transported (or selected) on the protection path. transported (or selected) on the protection path.
o Protecting administrative state - The operator has issued a o Protecting administrative state - The operator has issued a
command switching the user traffic to the protection path. command switching the user traffic to the protection path.
o Wait-to-restore state - The protection domain is recovering from a o Wait-to-Restore state - The protection domain is recovering from
SF/SD condition on the working path that is being controlled by an SF/SD condition on the working path that is being controlled by
the Wait-to-Restore (WTR) timer. the Wait-to-Restore (WTR) timer.
o Do-not-revert state - The protection domain has recovered from a o Do-not-Revert state - The protection domain has recovered from a
Protecting state, but the operator has configured the protection Protecting state, but the operator has configured the protection
domain to not automatically revert to the Normal state upon domain not to automatically revert to the Normal state upon
recovery. The protection domain SHALL remain in this state until recovery. The protection domain SHALL remain in this state until
the operator issues a command to revert to the Normal state or the operator issues a command to revert to the Normal state or
there is a new trigger to switch to a different state. there is a new trigger to switch to a different state.
See section 4.3.3 for details on what actions are taken by the PSC See Section 4.3.3 for details on what actions are taken by the PSC
Process Logic for each state and the relevant input. Process logic for each state and the relevant input.
3.6.1. Local and Remote state 3.6.1. Local and Remote State
An end-point may be in a given state as a result of either a local An end point may be in a given state as a result of either a local
input indicator, e.g. OAM, WTR timer, or as a result of receiving a input indicator (e.g., OAM, WTR timer) or as a result of receiving a
PSC message from the far-end LER. If the state is entered as a PSC message from the far-end LER. If the state is entered as a
result of a local input indicator, then the state is considered a result of a local input indicator, then the state is considered a
local state. If the state is entered as a result of a PSC message, local state. If the state is entered as a result of a PSC message,
in the absence of a local input, then the state is considered a in the absence of a local input, then the state is considered a
remote state. This differentiation affects how the LER reacts to remote state. This differentiation affects how the LER reacts to
different inputs, as described in Section 4.3.3. The PSC Control different inputs, as described in Section 4.3.3. The PSC Control
logic should maintain, together with the current protection domain logic should maintain, together with the current protection domain
state, an indication of whether this is a local or remote state, for state, an indication of whether this is a local or remote state, for
this LER. this LER.
In any instance where the LER has both a local and remote indicators In any instance where the LER has both a local and remote indicator
that cause the protection domain to enter a particular state, then that cause the protection domain to enter a particular state, then
the state is considered a local state, regardless of the order in the state is considered a local state, regardless of the order in
which the indicators were processed. If, however, the LER has local which the indicators were processed. If, however, the LER has local
and remote indicators that would cause the protection domain to enter and remote indicators that would cause the protection domain to enter
different states, e.g. a Local SF on working and a Remote Lockout different states, e.g., a local SF on working and a remote Lockout of
message, then the input with the higher priority (see section 4.3.2) protection message, then the input with the higher priority (see
will be the deciding factor and the source of that indicator will Section 4.3.2) will be the deciding factor and the source of that
determine whether it is local or remote. In the given example the indicator will determine whether it is local or remote. In the given
result would be a Remote Unavailable state transmitting PSC messages example, the result would be a Remote Unavailable state transmitting
that indicate a SF condition on the working path and that the PSC messages that indicate an SF condition on the working path and
protection path is not being used to transport protected traffic (as that the protection path is not being used to transport protected
described in the next section). traffic (as described in the next section).
4. Protection state coordination (PSC) protocol 4. Protection State Coordination (PSC) Protocol
Bidirectional protection switching, as well as unidirectional 1:1 Bidirectional protection switching, as well as unidirectional 1:1
protection, requires coordination between the two end points in protection, requires coordination between the two end points in
determining which of the two possible paths, the working or determining which of the two possible paths, the working or
protection path, is transmitting the data traffic in any given protection path, is transmitting the data traffic in any given
situation. When protection switching is triggered as described in situation. When protection switching is triggered as described in
section 3, the end points must inform each other of the switch-over Section 3, the end points must inform each other of the switchover
from one path to the other in a coordinated fashion. from one path to the other in a coordinated fashion.
There are different possibilities for the type of coordinating There are different possibilities for the type of coordinating
protocol. One possibility is a two-phased coordination in which the protocol. One possibility is a two-phased coordination in which the
LER that is initiating the protection switching sends a protocol LER that is initiating the protection switching sends a protocol
message indicating the switch but the actual switch-over is performed message indicating the switch but the actual switchover is performed
only after receiving an 'Ack' from the far-end LER. The other only after receiving an 'Ack' from the far-end LER. The other
possibility is a single-phased coordination, in which the initiating possibility is a single-phased coordination, in which the initiating
LER performs the protection switchover to the alternate path and LER performs the protection switchover to the alternate path and
informs the far-end LER of the switch, and the far-end LER will informs the far-end LER of the switch, and the far-end LER will
complete the switchover. complete the switchover.
This protocol is a single-phased protocol, as described above. In This protocol is a single-phased protocol, as described above. In
the following subsections we describe the protocol messages that are the following subsections, we describe the protocol messages that are
used between the two end points of the protection domain. used between the two end points of the protection domain.
4.1. Transmission and acceptance of PSC control packets 4.1. Transmission and Acceptance of PSC Control Packets
The PSC control packets SHALL be transmitted over the protection path The PSC control packets SHALL be transmitted over the protection path
only. This allows the transmission of the messages without affecting only. This allows the transmission of the messages without affecting
the normal data traffic in the most prevalent case, i.e. the Normal the normal data traffic in the most prevalent case, i.e., the Normal
state. In addition, limiting the transmission to a single path state. In addition, limiting the transmission to a single path
avoids possible conflicts and race conditions that could develop if avoids possible conflicts and race conditions that could develop if
the PSC messages were sent on both paths. the PSC messages were sent on both paths.
When the protection domain state is changed due to a local input, When the protection domain state is changed due to a local input,
three PSC messages SHALL be transmitted as quickly as possible, to three PSC messages SHALL be transmitted as quickly as possible, to
allow for rapid protection switching. This set of three rapid allow for rapid protection switching. This set of three rapid
messages allows for fast protection switching even if one or two of messages allows for fast protection switching even if one or two of
these packets are lost or corrupted. When the protection domain these packets are lost or corrupted. When the protection domain
state changes due to a remote message the LER SHOULD send the three state changes due to a remote message, the LER SHOULD send the three
rapid messages. However, when the LER tranfers from WTR state to rapid messages. However, when the LER transfers from WTR state to
Normal state as a result of a remote NR message, the three rapid Normal state as a result of a remote NR message, the three rapid
messages SHALL be transmitted. After the transmission of the three messages SHALL be transmitted. After the transmission of the three
rapid messages, the LER MUST retransmit the most recently transmitted rapid messages, the LER MUST retransmit the most recently transmitted
PSC message on a continual basis. PSC message on a continual basis.
Both the default frequency of the three rapid messages as well as the Both the default frequency of the three rapid messages as well as the
default frequency of the continual message transmission SHALL be default frequency of the continual message transmission SHALL be
configurable by the operator. The actual frequencies used MAY be configurable by the operator. The actual frequencies used MAY be
configurable, at the time of establishment, for each individual configurable, at the time of establishment, for each individual
protected LSP. For management purposes, the operator SHOULD be able protected LSP. For management purposes, the operator SHOULD be able
to retrieve the current default frequency values as well as the to retrieve the current default frequency values as well as the
actual values for any specific LSP. For protection switching within actual values for any specific LSP. For protection switching within
50ms, it is RECOMMENDED that the default interval of the first three 50 ms, it is RECOMMENDED that the default interval of the first three
rapid PSC messages SHOULD be no larger than 3.3ms. Using this rapid PSC messages SHOULD be no longer than 3.3 ms. Using this
frequency would allow the far-end to be guaranteed of receiving the frequency would allow the far-end to be guaranteed of receiving the
trigger indication within 10ms and completion of the switching trigger indication within 10 ms and completion of the switching
operation within 50ms. Subsequent messages SHOULD be continuously operation within 50 ms. Subsequent messages SHOULD be continuously
transmitted with a default interval of 5 seconds. The purpose of the transmitted with a default interval of 5 seconds. The purpose of the
continual messages is to verify that the PSC session is still alive. continual messages is to verify that the PSC session is still alive.
If no valid PSC message is received, over a period of several If no valid PSC message is received, over a period of several
continual messages intervals, the last valid received message remains continual messages intervals, the last valid received message remains
applicable. applicable.
4.2. Protocol format 4.2. Protocol Format
The protocol messages SHALL be sent over the G-ACh as described in The protocol messages SHALL be sent over the G-ACh as described in
[RFC5586]. There is a single channel type for the set of PSC [RFC5586]. There is a single channel type for the set of PSC
messages. The actual message function SHALL be identified by the messages. The actual message function SHALL be identified by the
Request field of the ACH payload as described below. Request field of the ACH payload as described below.
The channel type for the PSC messages SHALL be PSC-CT=0xHH (to be The channel type for the PSC messages SHALL be PSC-CT=0x0024.
assigned by IANA)
The following figure shows the format for the complete PSC message: The following figure shows the format for the complete PSC message.
0 1 2 3 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 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 | |0 0 0 1|Version| Reserved | PSC-CT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|Request|PT |R| Reserved1 | FPath | Path | |Ver|Request|PT |R| Reserved1 | FPath | Path |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Length | Reserved2 | | TLV Length | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional TLVs ~ ~ Optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of PSC packet with a G-ACh header Figure 2: Format of PSC Packet with a G-ACh Header
Where: Where:
o Both Reserved1 and Reserved2 fields MUST be set to 0 and ignored o Both Reserved1 and Reserved2 fields MUST be set to 0 and ignored
upon receipt. upon receipt.
o The following subsections describe the remaining fields of the PSC o The following subsections describe the remaining fields of the PSC
payload. payload.
4.2.1. PSC Ver field 4.2.1. PSC Ver Field
The Ver field identifies the version of the protocol. For this The Ver field identifies the version of the protocol. For this
version of the document the value SHALL be 1. version of the document, the value SHALL be 1.
4.2.2. PSC Request field 4.2.2. PSC Request Field
The PSC protocol SHALL support transmission of the following requests The PSC protocol SHALL support transmission of the following requests
between the two end points of the protection domain: between the two end points of the protection domain:
o (14) Lockout of protection - indicates that the end point has o (14) Lockout of protection - indicates that the end point has
disabled the protection path as a result of an administrative disabled the protection path as a result of an administrative
command. Both the FPath and Path fields SHALL be set to 0. command. Both the FPath and Path fields SHALL be set to 0.
o (12) Forced switch - indicates that the transmitting end point has o (12) Forced Switch - indicates that the transmitting end point has
switched traffic to the protection path as a result of an switched traffic to the protection path as a result of an
administrative command. The Fpath field SHALL indicate that the administrative command. The FPath field SHALL indicate that the
working path is being blocked (i.e. Fpath set to 1), and the Path working path is being blocked (i.e., FPath set to 1), and the Path
field SHALL indicate that user data traffic is being transported field SHALL indicate that user data traffic is being transported
on the protection path (i.e. Path set to 1). on the protection path (i.e., Path set to 1).
o (10) Signal Fail - indicates that the transmitting end point has o (10) Signal Fail - indicates that the transmitting end point has
identified a signal fail condition on either the working or identified a signal fail condition on either the working or
protection path. The Fpath field SHALL identify the path that is protection path. The FPath field SHALL identify the path that is
reporting the failure condition (i.e. if protection path then reporting the failure condition (i.e., if protection path, then
Fpath is set to 0 and if working path then Fpath is set to 1), and FPath is set to 0; if working path, then FPath is set to 1), and
the Path field SHALL indicate where the data traffic is being the Path field SHALL indicate where the data traffic is being
transported (i.e. if protection path is blocked then Path is set transported (i.e., if protection path is blocked, then Path is set
to 0 and if working path is blocked then Path is set to 1). to 0; if working path is blocked, then Path is set to 1).
o (7) Signal Degrade - indicates that that the transmitting end o (7) Signal Degrade - indicates that the transmitting end point has
point has identified a degradation of the signal, or integrity of identified a degradation of the signal, or integrity of the packet
the packet transmission on either the working or protection path. transmission on either the working or protection path. This
This request is presented here only as a place-holder. The request is presented here only as a placeholder. The specifics
specifics for the method of identifying this degradation is out- for the method of identifying this degradation is out of scope for
of-scope for this document. The details of the actions to be this document. The details of the actions to be taken for this
taken for this situation is left for future specification. situation are left for future specification.
o (5) Manual switch - indicates that the transmitting end point has o (5) Manual Switch - indicates that the transmitting end point has
switched traffic to the protection path as a result of an switched traffic to the protection path as a result of an
administrative Manual Switch command. The Fpath field SHALL administrative Manual Switch command. The FPath field SHALL
indicate that the working path is being blocked (i.e. Fpath set indicate that the working path is being blocked (i.e., FPath set
to 1), and the Path field SHALL indicate that user data traffic is to 1), and the Path field SHALL indicate that user data traffic is
being transported on the protection path (i.e. Path set to 1). being transported on the protection path (i.e., Path set to 1).
o (4) Wait to restore - indicates that the transmitting end point is o (4) Wait-to-Restore - indicates that the transmitting end point is
recovering from a failure condition of the working path and has recovering from a failure condition of the working path and has
started the Wait-to-Restore timer. Fpath SHALL be set to 0 and started the Wait-to-Restore timer. FPath SHALL be set to 0 and
ignored upon receipt. Path SHALL indicate the working path that ignored upon receipt. Path SHALL indicate the working path that
is currently being protected (i.e. Path set to 1). is currently being protected (i.e., Path set to 1).
o (1) Do not revert - indicates that the transmitting end point has o (1) Do-not-Revert - indicates that the transmitting end point has
recovered from a failure/blocked condition, but due to the local recovered from a failure/blocked condition, but due to the local
settings is is requesting that the protection domain continues to settings, is requesting that the protection domain continues to
transport the data as if it is in a protecting state, rather than transport the data as if it is in a protecting state, rather than
revert to the Normal state. Fpath SHALL be set to 0 and ignored revert to the Normal state. FPath SHALL be set to 0 and ignored
upon receipt. Path SHALL indicate the working path that is upon receipt. Path SHALL indicate the working path that is
currently being protected (i.e. Path set to 1). currently being protected (i.e., Path set to 1).
o (0) No request - indicates that the transmitting end point has o (0) No Request - indicates that the transmitting end point has
nothing to report, Fpath and Path fields SHALL be set to according nothing to report, FPath and Path fields SHALL be set according to
to the state of the end point, see section 4.3.3 for detailed the transmission state of the end point, see Section 4.3.3 for
scenarios. detailed scenarios.
All other values are for future extensions (to be administered by All other values are for future extensions (to be administered by
IANA) and SHALL be ignored upon receipt. IANA) and SHALL be ignored upon receipt.
4.2.3. Protection Type (PT) 4.2.3. Protection Type (PT) Field
The PT field indicates the currently configured protection The PT field indicates the currently configured protection
architecture type, this SHOULD be validated to be consistent for both architecture type, this SHOULD be validated to be consistent for both
ends of the protection domain. If an inconsistency is detected then ends of the protection domain. If an inconsistency is detected, then
an alarm SHALL be sent to the management system. The following are an alarm SHALL be sent to the management system. The following are
the possible values: the possible values:
o 3: bidirectional switching using a permanent bridge o 3: bidirectional switching using a permanent bridge
o 2: bidirectional switching using a selector bridge o 2: bidirectional switching using a selector bridge
o 1: unidirectional switching using a permanent bridge o 1: unidirectional switching using a permanent bridge
o 0: for future extensions o 0: for future extensions
As described in the introduction (section 1.1) a 1+1 protection As described in the Introduction (Section 1.1) a 1+1 protection
architecture is characterized by the use of a permanent bridge at the architecture is characterized by the use of a permanent bridge at the
source node, whereas the 1:1 and 1:n protection architectures are source node, whereas the 1:1 and 1:n protection architectures are
characterized by the use of a selector bridge at the source node. characterized by the use of a selector bridge at the source node.
4.2.4. Revertive (R) field 4.2.4. Revertive (R) Field
This field indicates that the transmitting end point is configured to This field indicates that the transmitting end point is configured to
work in revertive mode. If there is an inconsistency between the two work in revertive mode. If there is an inconsistency between the two
end points, i.e. one end point is configured for revertive action and end points, i.e., one end point is configured for revertive action
the second end point is in non-revertive mode, then the management and the second end point is in non-revertive mode, then the
system SHOULD be notified. Possible values are: management system SHOULD be notified. The following are the possible
values:
o 0 - non-revertive mode o 0 - non-revertive mode
o 1 - revertive mode o 1 - revertive mode
4.2.5. Fault path (FPath) field 4.2.5. Fault Path (FPath) Field
The Fpath field indicates which path (i.e. working or protection) is The FPath field indicates which path (i.e., working or protection) is
identified to be in a fault condition or affected by an identified to be in a fault condition or affected by an
administrative command, when a fault or command is indicated by the administrative command, when a fault or command is indicated by the
Request field to be in effect. The following are the possible Request field to be in effect. The following are the possible
values: values:
o 0: indicates that the anomaly condition is on the protection path o 0: indicates that the anomaly condition is on the protection path
o 1: indicates that the anomaly condition is on the working path o 1: indicates that the anomaly condition is on the working path
o 2-255: for future extensions and SHALL be ignored by this version o 2-255: for future extensions and SHALL be ignored by this version
of the protocol. of the protocol.
4.2.6. Data path (Path) field 4.2.6. Data Path (Path) Field
The Path field indicates which data is being transported on the The Path field indicates which data is being transported on the
protection path. Under normal conditions, the protection path protection path. Under normal conditions, the protection path
(especially in 1:1 or 1:n architecture) does not need to carry any (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 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 the working paths, then that working path's data traffic will be
transported over the protection path. The following are the possible transported over the protection path. The following are the possible
values: values:
o 0: indicates that the protection path is not transporting user o 0: indicates that the protection path is not transporting user
data traffic (in 1:n architecture) or transporting redundant user data traffic (in 1:n architecture) or transporting redundant user
data traffic (in 1+1 architecture). data traffic (in 1+1 architecture).
o 1: indicates that the protection path is transmitting user traffic o 1: indicates that the protection path is transmitting user traffic
replacing the use of the working path. replacing the use of the working path.
o 2-255: for future extensions and SHALL be ignored by this version o 2-255: for future extensions and SHALL be ignored by this version
of the protocol. of the protocol.
4.2.7. Additional TLV information 4.2.7. Additional TLV Information
It may be necessary for future applications of the protocol to It may be necessary for future applications of the protocol to
include additional information for the proper processing of the include additional information for the proper processing of the
requests. For this purpose, we provide for optional additional requests. For this purpose, we provide for optional additional
information to be included in the PSC payload. This information MUST information to be included in the PSC payload. This information MUST
include a header that indicates the total length (in bytes) of the include a header that indicates the total length (in bytes) of the
additional information. additional information.
This information includes the following fields: This information includes the following fields:
o TLV Length -- indicates the number of bytes included in the o TLV Length: indicates the number of bytes included in the optional
optional TLV information. For the basic PSC protocol operation TLV information. For the basic PSC protocol operation described
described in this document this value MUST be 0. in this document, this value MUST be 0.
o Optional TLVs -- this includes any additional information o Optional TLVs: this includes any additional information formatted
formatted as TLV units. There are no TLV units defined for the as TLV units. There are no TLV units defined for the basic PSC
basic PSC operation. operation.
4.3. Principles of Operation 4.3. Principles of Operation
In all of the following subsections, assume a protection domain In all of the following subsections, assume a protection domain
between LER-A and LER-Z, using paths W (working) and P (protection) between LER-A and LER-Z, using paths W (working) and P (protection),
as shown in figure 3. as shown in Figure 3.
+-----+ //=======================\\ +-----+ +-----+ //=======================\\ +-----+
|LER-A|// Working Path \\|LER-Z| |LER-A|// Working Path \\|LER-Z|
| /| |\ | | /| |\ |
| ?< | | >? | | ?< | | >? |
| \|\\ Protection Path //|/ | | \|\\ Protection Path //|/ |
+-----+ \\=======================// +-----+ +-----+ \\=======================// +-----+
|--------Protection Domain--------| |--------Protection Domain--------|
Figure 3: Protection domain Figure 3: Protection Domain
4.3.1. Basic operation 4.3.1. Basic Operation
The purpose of the PSC protocol is to allow an end point of the The purpose of the PSC protocol is to allow an end point of the
protection domain to notify its peer of the status of the domain that protection domain to notify its peer of the status of the domain that
is known at the end point and coordinate the transmission of the data is known at the end point and coordinate the transmission of the data
traffic. The current state of the end point is expressed in the traffic. The current state of the end point is expressed in the
values of the Request field [reflecting the local requests at that values of the Request field (reflecting the local requests at that
end point] and the Fpath field [reflecting knowledge of a blocked end point) and the FPath field (reflecting knowledge of a blocked
path]. The coordination between the end points is expressed by the path). The coordination between the end points is expressed by the
value of the Path field [indicating where the user data traffic is value of the Path field (indicating where the user data traffic is
being transmitted]. Except during a protection switch, the value of being transmitted). Except during a protection switch, the value of
the Path field should be identical for both end points at any the Path field should be identical for both end points at any
particular time. The values of the Request and Fpath fields may not particular time. The values of the Request and FPath fields may not
be identical between the two end points. In particular it should be be identical between the two end points. In particular it should be
noted that a remote message may not cause the end point to change the 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 Request field that is being transmitted while it does affect the Path
field (see details in the following subsections). field (see details in the following subsections).
The protocol is a single-phased protocol. Single-phased implies that The protocol is a single-phased protocol. "Single-phased" implies
each end point notifies its peer of a change in the operation that each end point notifies its peer of a change in the operation
(switching to or from the protection path) and makes the switch (switching to or from the protection path) and makes the switch
without waiting for acknowledgement. As a side-effect of using a without waiting for acknowledgement. As a side effect of using a
single-phased protocol, there will be a short period during state single-phased protocol, there will be a short period during state
transitions of one-sided triggers (e.g. operator commands, or transitions of one-sided triggers (e.g., operator commands or
unidirectional SF) when one LER may be transporting/selecting the unidirectional SF) when one LER may be transporting/selecting the
data from one transport path while the other end point is data from one transport path while the other end point is
transporting/selecting from the other transport path. This should transporting/selecting from the other transport path. This should
become coordinated once the remote message is received and the far- become coordinated once the remote message is received and the far-
end LER performs the protection switching operation. end LER performs the protection switching operation.
The following subsections will identify the messages that will be The following subsections will identify the messages that will be
transmitted by the end point in different scenarios. The messages transmitted by the end point in different scenarios. The messages
are described as REQ(FP, P) - where REQ is the value of the Request 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 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 Path field. All examples assume a protection domain between LER-A
and LER-Z with a single working path and single protection path (as and LER-Z with a single working path and single protection path (as
shown in figure 3). Again it should be noted that when using 1:1 shown in Figure 3). Again, it should be noted that when using 1:1
protection the data traffic will be transmitted exclusively on either protection the data traffic will be transmitted exclusively on either
the protection or working path, while when using 1+1 protection the the protection or working path; whereas when using 1+1 protection,
traffic will be transmitted on both paths and the receiving LER the traffic will be transmitted on both paths and the receiving LER
should select the appropriate signal based on the state. The text should select the appropriate signal based on the state. The text
will refer to this transmission/selection as "transport" of the data will refer to this transmission/selection as "transport" of the data
traffic. For 1+1 unidirectional protection, the state of the traffic. For 1+1 unidirectional protection, the state of the
selector will only be switched in reaction to a local message. When selector will only be switched in reaction to a local message. When
receiving a remote message, a LER that is configured for 1+1 receiving a remote message, a LER that is configured for 1+1
unidirectional protection, will transfer to the new remote state, unidirectional protection, will transfer to the new remote state;
however it will continue to select data according to the latest known however, it will continue to select data according to the latest
local state. When the LER transitions into the Normal state, the PSC known local state. When the LER transitions into the Normal state,
Control Process SHALL check the persistent state of the local the PSC Control Process SHALL check the persistent state of the local
triggers to decide if it should further transition into a new state. triggers to decide if it should further transition into a new state.
4.3.2. Priority of inputs 4.3.2. Priority of Inputs
As noted above (in section 3.1) the PSC Control Process accepts input
from five local input sources. There is a definition of priority
between the different inputs that may be triggered locally. The list
of local requests in order of priority are (from highest to lowest
priority):
1. Clear (Operator command) As noted above (in Section 3.1), the PSC Control Process accepts
input from five local input sources. There is a definition of
priority between the different inputs that may be triggered locally.
The list of local requests in order of priority are (from highest to
lowest priority):
2. Lockout of protection (Operator command) 1. Clear (operator command)
3. Forced switch (Operator command) 2. Lockout of protection (operator command)
4. Signal Fail on protection (OAM/Control Plane/Server Indication) 3. Forced Switch (operator command)
4. Signal Fail on protection (OAM / control-plane / server
indication)
5. Signal Fail on working (OAM/Control Plane/Server Indication) 5. Signal Fail on working (OAM / control-plane / server indication)
6. Signal Degrade on working (OAM/Control Plane/Server Indication) 6. Signal Degrade on working (OAM / control-plane / server
indication)
7. Clear Signal Fail/Degrade (OAM/Control Plane/Server Indication) 7. Clear Signal Fail/Degrade (OAM / control-plane / server
indication)
8. Manual switch (Operator command) 8. Manual Switch (operator command)
9. WTR expires (WTR Timer) 9. WTR Expires (WTR timer)
10. No request (default) 10. No Request (default)
As was noted above, the Local request logic SHALL always select the As was noted above, the Local Request logic SHALL always select the
local input indicator with the highest priority as the current local local input indicator with the highest priority as the current local
request, i.e. only the highest priority local input will be used to request, i.e., only the highest priority local input will be used to
affect the control logic. All local inputs with lower priority than affect the control logic. All local inputs with lower priority than
this current local request will be ignored. this current local request will be ignored.
The remote message from the far-end LER is assigned a priority just The remote message from the far-end LER is assigned a priority just
below the similar local input. For example, a remote Signal Fail on below the similar local input. For example, a remote Forced Switch
protection would have a priority just below a local Signal Fail on would have a priority just below a local Forced Switch but above a
protection but above a local Forced Switch input. As mentioned in local Signal Fail on protection input. As mentioned in
section 3.6.1, the state transition is determined by the higher Section 3.6.1, the state transition is determined by the higher
priority input between the highest priority local input and the priority input between the highest priority local input and the
remote message. This also determines the classification of the state remote message. This also determines the classification of the state
as local or remote. The following subsections detail the transition as local or remote. The following subsections detail the transition
based on the current state and the higher priority of these two based on the current state and the higher priority of these two
inputs. inputs.
4.3.3. Operation of PSC States 4.3.3. Operation of PSC States
The following sub-sections present the operation of the different The following subsections present the operation of the different
states defined in section 3.6. For each state we define the states defined in Section 3.6. For each state, we define the
reaction, i.e. the new state and the message to transmit, to each reaction, i.e., the new state and the message to transmit, to each
possible input - either the highest priority local input or the PSC possible input -- either the highest priority local input or the PSC
message from the remote LER. It should be noted that the new state message from the remote LER. It should be noted that the new state
of the protection domain is described from the point of view of the of the protection domain is described from the point of view of the
LER that is reporting the state, therefore, the language of "the LER LER that is reporting the state; therefore, the language of "the LER
goes into a state" is referring to the LER reporting that the goes into a state" is referring to the LER reporting that the
protection domain is now in this new state. If the definition states protection domain is now in this new state. If the definition states
to "ignore" the message, the intention is that the protection domain to "ignore" the message, the intention is that the protection domain
SHALL remain in its current state and the LER SHALL continue SHALL remain in its current state and the LER SHALL continue
transmitting (as presented in section 4.1) the current PSC message. transmitting (as presented in Section 4.1) the current PSC message.
When a LER is in a remote state, i.e. state transition in reaction to When a LER is in a remote state, i.e., state transition in reaction
a PSC message recieved from the far-end LER, and receives a new PSC to a PSC message received from the far-end LER, and receives a new
message from the far-end LER that indicates a contradictory state, PSC message from the far-end LER that indicates a contradictory
e.g. in remote Unavailable state receiving a remote FS(1,1) message, state, e.g., in remote Unavailable state receiving a remote FS(1,1)
then the PSC Control Logic SHALL reevaluate all inputs (both the message, then the PSC Control logic SHALL reevaluate all inputs (both
local input and the remote message) as if the LER is in the Normal the local input and the remote message) as if the LER is in the
state. Normal state.
4.3.3.1. Normal State 4.3.3.1. Normal State
When the protection domain has no special condition in effect, the When the protection domain has no special condition in effect, the
ingress LER SHALL forward the user data along the working path, and, ingress LER SHALL forward the user data along the working path, and,
in the case of 1+1 protection, the Permanent Bridge will bridge the in the case of 1+1 protection, the Permanent Bridge will bridge the
data to the protection path as well. The receiving LER SHALL read data to the protection path as well. The receiving LER SHALL read
the data from the working path. the data from the working path.
When the LER transitions into the Normal state, the PSC Control When the LER transitions into the Normal state, the PSC Control
Process SHALL check the persistent state of the local triggers to Process SHALL check the persistent state of the local triggers to
decide if it should further transition into a new state. If the decide if it should further transition into a new state. If the
result of this check is a transition into a new state, the LER SHALL result of this check is a transition into a new state, the LER SHALL
transmit the corresponding message described in this section and transmit the corresponding message described in this section and
SHALL use the data path corresponding to the new state. When the SHALL use the data path corresponding to the new state. When the
protection domain remains in Normal State, the end-point SHALL protection domain remains in Normal state, the end point SHALL
transmit a NR(0,0) message, indicating - Nothing to report and data transmit an NR(0,0) message, indicating -- Nothing to report and data
traffic is being transported on the working path. traffic is being transported on the working path.
When the protection domain is in Normal State the following When the protection domain is in Normal state, the following
transitions are relevant in reaction to a local input to the LER: transitions are relevant in reaction to a local input to the LER:
o A local Lockout of protection input SHALL cause the LER to go into o A local Lockout of protection input SHALL cause the LER to go into
local Unavailable State and begin transmission of a LO(0,0) local Unavailable state and begin transmission of an LO(0,0)
message. message.
o A local Forced switch input SHALL cause the LER to go into local o A local Forced Switch input SHALL cause the LER to go into local
Protecting administrative state and begin transmission of a Protecting administrative state and begin transmission of an
FS(1,1) message. FS(1,1) message.
o A local Signal Fail indication on the protection path SHALL cause o A local Signal Fail indication on the protection path SHALL cause
the LER to go into local Unavailable state and begin transmission the LER to go into local Unavailable state and begin transmission
of a SF(0,0) message. of an SF(0,0) message.
o A local Signal Fail indication on the working path SHALL cause the o A local Signal Fail indication on the working path SHALL cause the
LER to go into local Protecting failure state and begin LER to go into local Protecting failure state and begin
transmission of a SF(1,1) message. transmission of an SF(1,1) message.
o A local Manual switch input SHALL cause the LER to go into local o A local Manual Switch input SHALL cause the LER to go into local
Protecting administrative state and begin transmission of a Protecting administrative state and begin transmission of an
MS(1,1) message. MS(1,1) message.
o All other local inputs SHALL be ignored. o All other local inputs SHALL be ignored.
In Normal state, remote messages would cause the following reaction In Normal state, remote messages would cause the following reaction
from the LER: from the LER:
o A remote Lockout of protection message SHALL cause the LER to go o A remote Lockout of protection message SHALL cause the LER to go
into remote Unavailable state, while continuing to transmit the into remote Unavailable state, while continuing to transmit the
NR(0,0) message. NR(0,0) message.
o A remote Forced switch message SHALL cause the LER to go into o A remote Forced Switch message SHALL cause the LER to go into
remote Protecting administrative state, and begin transmitting a remote Protecting administrative state and begin transmitting an
NR(0,1) message. NR(0,1) message.
o A remote Signal Fail message that indicates that the failure is on o A remote Signal Fail message that indicates that the failure is on
the protection path SHALL cause the LER (LER-A) to go into remote the protection path SHALL cause the LER (LER-A) to go into remote
Unavailable state, while continuing to transmit the NR(0,0) Unavailable state, while continuing to transmit the NR(0,0)
message. message.
o A remote Signal Fail message that indicates that the failure is on o A remote Signal Fail message that indicates that the failure is on
the working path SHALL cause the LER to go into remote Protecting the working path SHALL cause the LER to go into remote Protecting
failure state, and transmit a NR(0,1) message. failure state, and transmit an NR(0,1) message.
o A remote Manual switch message SHALL cause the LER to go into o A remote Manual Switch message SHALL cause the LER to go into
remote Protecting administrative state, and transmit a NR(0,1) remote Protecting administrative state, and transmit an NR(0,1)
message. message.
o All other remote messages SHALL be ignored. o All other remote messages SHALL be ignored.
4.3.3.2. Unavailable State 4.3.3.2. Unavailable State
When the protection path is unavailable - either as a result of a When the protection path is unavailable -- either as a result of a
Lockout operator command, or as a result of a SF detected on the Lockout operator command, or as a result of a SF detected on the
protection path - then the protection domain is in the unavailable protection path -- then the protection domain is in the Unavailable
state. In this state, the data traffic SHALL be transported on the state. In this state, the data traffic SHALL be transported on the
working path and is not protected. When the domain is in unavailable working path and is not protected. When the domain is in Unavailable
state the PSC messages may not get through and therefore the state, the PSC messages may not get through: therefore, the
protection is more dependent on the local inputs rather than the protection is more dependent on the local inputs than the remote
remote messages (that may not be received). messages (that may not be received).
The protection domain will exit the unavailable state and revert to The protection domain will exit the Unavailable state and revert to
the Normal state when either the operator clears the Lockout command the Normal state when either the operator clears the Lockout command
or the protection path recovers from the signal fail or degraded or the protection path recovers from the signal fail or degraded
situation. Both ends will continue to send the PSC messages over the situation. Both ends will continue to send the PSC messages over the
protection path, as a result of this recovery. protection path, as a result of this recovery.
When the LER (assume LER-A) is in Unavailable State the following When the LER (assume LER-A) is in Unavailable state, the following
transitions are relevant in reaction to a local input: transitions are relevant in reaction to a local input:
o A local Clear input SHALL be ignored if the LER is in remote o A local Clear input SHALL be ignored if the LER is in remote
Unavailable state. If in local Unavailable state due to a Lockout Unavailable state. If in local Unavailable state due to a Lockout
command, then the input SHALL cause the LER to go to Normal state. command, then the input SHALL cause the LER to go to Normal state.
o A local Lockout of protection input SHALL cause the LER to remain o A local Lockout of protection input SHALL cause the LER to remain
in local Unavailable State and transmit a LO(0,0) message to the in local Unavailable state and transmit an LO(0,0) message to the
far-end LER (LER-Z). far-end LER (LER-Z).
o A local Clear SF of the protection path in local Unavailable state o A local Clear SF of the protection path in local Unavailable state
that is due to a SF on the protection path SHALL cause the LER to that is due to an SF on the protection path SHALL cause the LER to
go to Normal state. If the LER is in remote Unavailable state but go to Normal state. If the LER is in remote Unavailable state but
has an active local SF condition, then the local Clear SF SHALL has an active local SF condition, then the local Clear SF SHALL
clear the SF local condition and the LER SHALL remain in remote clear the SF local condition and the LER SHALL remain in remote
Unavailable state and begin transmitting NR(0,0) messages. In all Unavailable state and begin transmitting NR(0,0) messages. In all
other cases the local Clear SF SHALL be ignored. other cases, the local Clear SF SHALL be ignored.
o A local Forced switch SHALL be ignored by the PSC Control Logic o A local Forced Switch SHALL be ignored by the PSC Control logic
when in Unavailable state as a result of a (local or remote) when in Unavailable state as a result of a (local or remote)
Lockout of protection. If in Unavailable state due to a SF on Lockout of protection. If in Unavailable state due to an SF on
protection, then the FS SHALL cause the LER to go into local protection, then the FS SHALL cause the LER to go into local
Protecting administrative state and begin transmitting a FS(1,1) Protecting administrative state and begin transmitting an FS(1,1)
message. It should be noted that due to the unavailability of the message. It should be noted that due to the unavailability of the
protection path (i.e., due to the SF condition) that this FS may protection path (i.e., due to the SF condition) that this FS may
not be received by the far-end until the SF condition is cleared. not be received by the far-end until the SF condition is cleared.
o A local Signal Fail on the protection path input when in local o A local Signal Fail on the protection path input when in local
Unavailable state [by implication this is due to a local SF on Unavailable state (by implication, this is due to a local SF on
protection] SHALL cause the LER to remain in local Unavailable protection) SHALL cause the LER to remain in local Unavailable
state and transmit a SF(0,0) message. state and transmit an SF(0,0) message.
o A local Signal Fail on the working path input when in remote o A local Signal Fail on the working path input when in remote
Unavailable state SHALL cause the LER to remain in remote Unavailable state SHALL cause the LER to remain in remote
Unavailable state and transmit a SF(1,0) message. Unavailable state and transmit an SF(1,0) message.
o All other local inputs SHALL be ignored. o All other local inputs SHALL be ignored.
If remote messages are being received over the protection path then If remote messages are being received over the protection path, then
they would have the following affect: they would have the following effect:
o A remote Lockout of protection message SHALL cause the LER to o A remote Lockout of protection message SHALL cause the LER to
remain in Unavailable state, (note that if the LER was previously remain in Unavailable state (note that if the LER was previously
in local Unavailable state due to a Signal Fail on the protection in local Unavailable state due to a Signal Fail on the protection
path, then it will now be in remote Unavailable state) and path, then it will now be in remote Unavailable state) and
continue transmission of the current message (either NR(0,0) or continue transmission of the current message (either NR(0,0) or
LO(0,0) or SF(0,0)) LO(0,0) or SF(0,0)).
o A remote Forced switch message SHALL be ignored by the PSC Control o A remote Forced Switch message SHALL be ignored by the PSC Control
Logic when in Unavailable state as a result of a (local or remote) logic when in Unavailable state as a result of a (local or remote)
Lockout of protection. If in Unavailable state due to a SF on Lockout of protection. If in Unavailable state due to a local or
protection, then the FS SHALL cause the LER to go into remote remote SF on protection, then the FS SHALL cause the LER to go
Protecting administrative state and begin transmitting a SF(0,1) into remote Protecting administrative state; if in Unavailable
message. state due to local SF, begin transmitting an SF(0,1) message.
o A remote Signal Fail message that indicates that the failure is on o A remote Signal Fail message that indicates that the failure is on
the protection path SHALL cause the LER to remain in Unavailable the protection path SHALL cause the LER to remain in Unavailable
state and continue transmission of the current message (either state and continue transmission of the current message (either
NR(0,0) or SF(0,0) or LO(0,0)). NR(0,0) or SF(0,0) or LO(0,0)).
o A remote No Request, when the LER is in remote Unavailable state o A remote No Request, when the LER is in remote Unavailable state
and there is no active local Signal Fail SHALL cause the LER to go and there is no active local Signal Fail SHALL cause the LER to go
into Normal state and continue transmission of the current into Normal state and continue transmission of the current
message. If there is a local Signal Fail on the protection path, message. If there is a local Signal Fail on the protection path,
the LER SHALL remain in local Unavailable state and transmit a the LER SHALL remain in local Unavailable state and transmit an
SF(0,0) message. If there is a local Signal Fail on the working SF(0,0) message. If there is a local Signal Fail on the working
path, the LER SHALL go into local Protecting Failure state and path, the LER SHALL go into local Protecting Failure state and
transmit a SF(1,1) message. When in local Unavailable state, the transmit an SF(1,1) message. When in local Unavailable state, the
remote message SHALL be ignored. remote message SHALL be ignored.
o All other remote messages SHALL be ignored. o All other remote messages SHALL be ignored.
4.3.3.3. Protecting administrative state 4.3.3.3. Protecting Administrative State
In the protecting state the user data traffic SHALL be transported on In the Protecting administrative state, the user data traffic SHALL
the protection path, while the working path is blocked due to an be transported on the protection path, while the working path is
operator command, i.e. Forced Switch or Manual Switch. The blocked due to an operator command, i.e., Forced Switch or Manual
difference between a local FS and local MS affects what local Switch. The difference between a local FS and local MS affects what
indicators may be received - the Local request logic will block any local indicators may be received -- the Local Request logic will
local SF when under the influence of a local FS, whereas the SF would block any local SF when under the influence of a local FS, whereas
override a local MS. In general, a MS will be canceled in case of the SF would override a local MS. In general, an MS will be canceled
either a local or remote SF or LO condition. in case of either a local or remote SF or LO condition.
The following describe the reaction to local input: The following describe the reaction to local input:
o A local Clear SHALL be ignored if in remote Protecting o A local Clear SHALL be ignored if in remote Protecting
administrative state. If in local Protecting administrative state administrative state. If in local Protecting administrative
then this input SHALL cause the LER to go into Normal state. state, then this input SHALL cause the LER to go into Normal
state.
o A local Lockout of protection input SHALL cause the LER to go into o A local Lockout of protection input SHALL cause the LER to go into
local Unavailable state and begin transmission of a LO(0,0) local Unavailable state and begin transmission of an LO(0,0)
message. message.
o A local Forced switch input SHALL cause the LER to remain in local o A local Forced Switch input SHALL cause the LER to remain in local
Protecting administrative state and transmit a FS(1,1) message. Protecting administrative state and transmit an FS(1,1) message.
o A local Signal Fail indication on the protection path SHALL cause o A local Signal Fail indication on the protection path SHALL cause
the LER to go into local Unavailable state and begin transmission the LER to go into local Unavailable state and begin transmission
of a SF(0,0) message, if the current state is due to a (local or of an SF(0,0) message, if the current state is due to a (local or
remote) Manual switch operator command. If the LER is in (local remote) Manual Switch operator command. If the LER is in (local
or remote) Protecting administrative state due to a FS situation, or remote) Protecting administrative state due to an FS situation,
then the SF on protection SHALL be ignored. then the SF on protection SHALL be ignored.
o A local Signal Fail indication on the working path SHALL cause the o A local Signal Fail indication on the working path SHALL cause the
LER to go into local Protecting failure state and begin LER to go into local Protecting failure state and begin
transmitting a SF(1,1) message, if the current state is due to a transmitting an SF(1,1) message, if the current state is due to a
(local or remote) Manual switch operator command. If the LER is (local or remote) Manual Switch operator command. If the LER is
in remote Protecting administrative state due to a remote Forced in remote Protecting administrative state due to a remote Forced
Switch command, then this local indication SHALL cause the LER to Switch command, then this local indication SHALL cause the LER to
remain in remote Protecting administrative state and transmit a remain in remote Protecting administrative state and transmit an
SF(1,1) message. If the LER is in local Protecting administrative SF(1,1) message. If the LER is in local Protecting administrative
state due to a local Forced Switch command then this indication state due to a local Forced Switch command, then this indication
SHALL be ignored (i.e. the indication should have been blocked by SHALL be ignored (i.e., the indication should have been blocked by
the Local request logic). the Local Request logic).
o A local Clear SF SHALL clear any local SF condition that may o A local Clear SF SHALL clear any local SF condition that may
exist. If in remote Protecting administrative state, the LER exist. If in remote Protecting administrative state, the LER
SHALL stop transmitting the SF(x,1) message and begin transmitting SHALL stop transmitting the SF(x,1) message and begin transmitting
an NR(0,1) message. an NR(0,1) message.
o A local Manual switch input SHALL be ignored if in remote o A local Manual Switch input SHALL be ignored if in remote
Protecting administrative state is due to a remote Forced switch Protecting administrative state due to a remote Forced Switch
command. If the current state is due to a (local or remote) command. If the current state is due to a (local or remote)
Manual switch operator command, it SHALL cause the LER to remain Manual Switch operator command, it SHALL cause the LER to remain
in local Protecting administrative state and transmit a MS(1,1) in local Protecting administrative state and transmit an MS(1,1)
message. message.
o All other local inputs SHALL be ignored. o All other local inputs SHALL be ignored.
While in Protecting administrative state the LER may receive and While in Protecting administrative state the LER may receive and
react as follows to remote PSC messages: react as follows to remote PSC messages:
o A remote Lockout of protection message SHALL cause the LER to go o A remote Lockout of protection message SHALL cause the LER to go
into remote Unavailable state and begin transmitting a NR(0,0) into remote Unavailable state and begin transmitting an NR(0,0)
message. It should be noted that this automatically cancels the message. It should be noted that this automatically cancels the
current Forced switch or Manual switch command and data traffic is current Forced Switch or Manual Switch command and data traffic is
reverted to the working path. reverted to the working path.
o A remote Forced switch message SHALL be ignored by the PSC Process o A remote Forced Switch message SHALL be ignored by the PSC Process
Logic if there is an active local Forced switch operator command. logic if there is an active local Forced Switch operator command.
If the Protecting administrative state is due to a remote Forced If the Protecting administrative state is due to a remote Forced
switch message then the LER SHALL remain in remote Protecting Switch message, then the LER SHALL remain in remote Protecting
administrative state and continue transmitting the last message. administrative state and continue transmitting the last message.
If the Protecting administrative state is due to either a local or If the Protecting administrative state is due to either a local or
remote Manual switch then the LER SHALL remain in remote remote Manual Switch, then the LER SHALL remain in remote
Protecting administrative state (updating the state information Protecting administrative state (updating the state information
with the proper relevant information) and begin transmitting a with the proper relevant information) and begin transmitting an
NR(0,1) message. NR(0,1) message.
o A remote Signal Fail message indicating a failure on the o A remote Signal Fail message indicating a failure on the
protection path SHALL cause the LER to go into remote Unavailable protection path SHALL cause the LER to go into remote Unavailable
state and begin transmitting a NR(0,0) message, if the Protecting state and begin transmitting an NR(0,0) message, if the Protecting
administrative state is due to a Manual switch command. It should administrative state is due to a Manual Switch command. It should
be noted that this automatically cancels the current Manual switch be noted that this automatically cancels the current Manual Switch
command and data traffic is reverted to the working path. command and data traffic is reverted to the working path.
o A remote Signal Fail message indicating a failure on the working o A remote Signal Fail message indicating a failure on the working
path SHALL be ignored if there is an active local Forced switch path SHALL be ignored if there is an active local Forced Switch
command. If the Protecting state is due to a local or remote command. If the Protecting state is due to a local or remote
Manual switch then the LER SHALL go to remote Protecting failure Manual Switch, then the LER SHALL go to remote Protecting failure
state and begin transmitting a NR(0,1) message. state and begin transmitting an NR(0,1) message.
o A remote Manual switch message SHALL be ignored by the PSC Control o A remote Manual Switch message SHALL be ignored by the PSC Control
Logic if in Protecting administrative state due to a local or logic if in Protecting administrative state due to a local or
remote Forced switch. If in Protecting administrative state due remote Forced Switch. If in Protecting administrative state due
to a remote Manual switch then the LER SHALL remain in remote to a remote Manual Switch, then the LER SHALL remain in remote
Protecting administrative state and continue transmitting the Protecting administrative state and continue transmitting the
current message. If in local Protecting administrative state due current message. If in local Protecting administrative state due
to an active Manual switch then the LER SHALL remain in local to an active Manual Switch, then the LER SHALL remain in local
Protecting administrative state and continue transmission of the Protecting administrative state and continue transmission of the
MS(1,1) message. MS(1,1) message.
o A remote DNR(0,1) message SHALL be ignored if in local Protecting o A remote DNR(0,1) message SHALL be ignored if in local Protecting
administrative state. If in remote Protecting administrative administrative state. If in remote Protecting administrative
state then the LER SHALL go to Do-not-revert state and continue state, then the LER SHALL go to Do-not-Revert state and continue
transmitting the current message. transmitting the current message.
o A remote NR(0,0) message SHALL be ignored if in local Protecting o A remote NR(0,0) message SHALL be ignored if in local Protecting
administrative state. If in remote Protecting administrative administrative state. If in remote Protecting administrative
state and there is no active local Signal Fail indication then the state and there is no active local Signal Fail indication, then
LER SHALL go to Normal state and begin transmitting a NR(0,0) the LER SHALL go to Normal state and begin transmitting an NR(0,0)
message. If there is a local Signal Fail on the working path, the message. If there is a local Signal Fail on the working path, the
LER SHALL go to local Protecting failure state and begin LER SHALL go to local Protecting failure state and begin
transmitting a SF(1,1) message. transmitting an SF(1,1) message.
o All other remote messages SHALL be ignored. o All other remote messages SHALL be ignored.
4.3.3.4. Protecting failure state 4.3.3.4. Protecting Failure State
When the protection mechanism has been triggered and the protection When the protection mechanism has been triggered and the protection
domain has performed a protection switch, the domain is in the domain has performed a protection switch, the domain is in the
protecting failure state. In this state the normal data traffic Protecting failure state. In this state, the normal data traffic
SHALL be transported on the protection path. When an LER is in this SHALL be transported on the protection path. When an LER is in this
state it implies that there was either a local SF condition or state, it implies that there either was a local SF condition or it
received a remote SF PSC message. The SF condition or message received a remote SF PSC message. The SF condition or message
indicated that the failure is on the working path. indicated that the failure is on the working path.
This state may be overridden by the Unavailable state triggers, i.e. This state may be overridden by the Unavailable state triggers, i.e.,
Lockout of Protection or SF on the protection path, or by issuing a Lockout of protection or SF on the protection path, or by issuing an
FS operator command. This state will be cleared when the SF FS operator command. This state will be cleared when the SF
condition is cleared. In order to prevent flapping due to an condition is cleared. In order to prevent flapping due to an
intermittent fault, the LER SHOULD employ a Wait-to-restore timer to intermittent fault, the LER SHOULD employ a Wait-to-Restore timer to
delay return to Normal state until the network has stabilized (see delay return to Normal state until the network has stabilized (see
section 3.5) Section 3.5).
The following describe the reaction to local input: The following describe the reaction to local input:
o A local Clear SF SHALL be ignored if in remote Protecting failure o A local Clear SF SHALL be ignored if in remote Protecting failure
state. If in local Protecting failure state and the LER is state. If in local Protecting failure state and the LER is
configured for revertive behavior then this input SHALL cause the configured for revertive behavior, then this input SHALL cause the
LER to go into Wait-to-restore state, start the WTR timer, and LER to go into Wait-to-Restore state, start the WTR timer, and
begin transmitting a WTR(0,1) message. If in local Protecting begin transmitting a WTR(0,1) message. If in local Protecting
failure state and the LER is configured for non-revertive behavior failure state and the LER is configured for non-revertive
then this input SHALL cause the LER to go into Do-not-revert state behavior, then this input SHALL cause the LER to go into Do-not-
and begin transmitting a DNR(0,1) message. Revert state and begin transmitting a DNR(0,1) message.
o A local Lockout of protection input SHALL cause the LER to go into o A local Lockout of protection input SHALL cause the LER to go into
Unavailable state and begin transmission of a LO(0,0) message. Unavailable state and begin transmission of an LO(0,0) message.
o A local Forced switch input SHALL cause the LER to go into o A local Forced Switch input SHALL cause the LER to go into
Protecting administrative state and begin transmission of a Protecting administrative state and begin transmission of an
FS(1,1) message. FS(1,1) message.
o A local Signal Fail indication on the protection path SHALL cause o A local Signal Fail indication on the protection path SHALL cause
the LER to go into Unavailable state and begin transmission of a the LER to go into Unavailable state and begin transmission of an
SF(0,0) message. SF(0,0) message.
o A local Signal Fail indication on the working path SHALL cause the o A local Signal Fail indication on the working path SHALL cause the
LER to remain in local Protecting failure state and transmit a LER to remain in local Protecting failure state and transmit an
SF(1,1) message. SF(1,1) message.
o All other local inputs SHALL be ignored. o All other local inputs SHALL be ignored.
While in Protecting failure state the LER may receive and react as While in Protecting failure state, the LER may receive and react as
follows to remote PSC messages: follows to remote PSC messages:
o A remote Lockout of protection message SHALL cause the LER to go o A remote Lockout of protection message SHALL cause the LER to go
into remote Unavailable state and if in local Protecting failure into remote Unavailable state, and if in local Protecting failure
state then the LER SHALL transmit a SF(1,0) message, otherwise it state, then the LER SHALL transmit an SF(1,0) message; otherwise,
SHALL transmit a NR(0,0) message. It should be noted that this it SHALL transmit an NR(0,0) message. It should be noted that
may cause loss of user data since the working path is still in a this may cause loss of user data since the working path is still
failure condition. in a failure condition.
o A remote Forced switch message SHALL cause the LER go into remote o A remote Forced Switch message SHALL cause the LER go into remote
Protecting administrative state and if in local Protecting failure Protecting administrative state, and if in local Protecting
state the LER SHALL transmit the SF(1,1) message, otherwise it failure state, the LER SHALL transmit the SF(1,1) message;
SHALL transmit NR(0,1). otherwise, it SHALL transmit NR(0,1).
o A remote Signal Fail message indicating a failure on the o A remote Signal Fail message indicating a failure on the
protection path SHALL cause the LER to go into remote Unavailable protection path SHALL cause the LER to go into remote Unavailable
state and if in local Protecting failure state then the LER SHALL state, and if in local Protecting failure state, then the LER
transmit a SF(1,0) message, otherwise it SHALL transmitting SHALL transmit an SF(1,0) message; otherwise, it SHALL transmit an
NR(0,0) message. It should be noted that this may cause loss of 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. user data since the working path is still in a failure condition.
o If in remote Protecting failure state, a remote Wait-to-Restore o If in remote Protecting failure state, a remote Wait-to-Restore
message SHALL cause the LER to go into remote Wait-to-Restore message SHALL cause the LER to go into remote Wait-to-Restore
state and continue transmission of the current message. state and continue transmission of the current message.
o If in remote Protecting failure state, a remote Do-not-revert o If in remote Protecting failure state, a remote Do-not-Revert
message SHALL cause the LER to go into remote Do-not-revert state message SHALL cause the LER to go into remote Do-not-Revert state
and continue transmission of the current message. and continue transmission of the current message.
o If in remote Protecting failure state, a remote NR(0,0) SHALL o If in remote Protecting failure state, a remote NR(0,0) SHALL
cause the LER to go to Normal state. cause the LER to go to Normal state.
o All other remote messages SHALL be ignored. o All other remote messages SHALL be ignored.
4.3.3.5. Wait-to-restore state 4.3.3.5. Wait-to-Restore State
The Wait-to-Restore state is used by the PSC protocol to delay When recovering from a failure condition on the working path, the
reverting to the Normal state, when recovering from a failure Wait-to-Restore state is used by the PSC protocol to delay reverting
condition on the working path, for the period of the WTR timer to to the Normal state, for the period of the WTR timer to allow the
allow the recovering failure to stabilize. While in the Wait-to- recovering failure to stabilize. While in the Wait-to-Restore state,
Restore state the data traffic SHALL continue to be transported on the data traffic SHALL continue to be transported on the protection
the protection path. The natural transition from the Wait-to-Restore path. The natural transition from the Wait-to-Restore state to
state to Normal state will occur when the WTR timer expires. Normal state will occur when the WTR timer expires.
When in Wait-to-Restore state the following describe the reaction to When in Wait-to-Restore state, the following describe the reaction to
local inputs: local inputs:
o A local Lockout of protection command SHALL cause the LER to Stop o A local Lockout of protection command SHALL send the Stop command
the WTR timer, go into local Unavailable state, and begin to the WTR timer, go into local Unavailable state, and begin
transmitting a LO(0,0) message. transmitting an LO(0,0) message.
o A local Forced switch command SHALL cause the LER to Stop the WTR o A local Forced Switch command SHALL send the Stop command to the
timer, go into local Protecting administrative state, and begin WTR timer, go into local Protecting administrative state, and
transmission of a FS(1,1) message. begin transmission of an FS(1,1) message.
o A local Signal Fail indication on the protection path SHALL cause o A local Signal Fail indication on the protection path SHALL send
the LER to Stop the WTR timer, go into local Unavailable state, the Stop command to the WTR timer, go into local Unavailable
and begin transmission of a SF(0,0) message. state, and begin transmission of an SF(0,0) message.
o A local Signal Fail indication on the working path SHALL cause the o A local Signal Fail indication on the working path SHALL send the
LER to Stop the WTR timer, go into local Protecting failure state, Stop command to the WTR timer, go into local Protecting failure
and begin transmission of a SF(1,1) message. state, and begin transmission of an SF(1,1) message.
o A local Manual switch input SHALL cause the LER to Stop the WTR o A local Manual Switch input SHALL send the Stop command to the WTR
timer, go into local Protecting administrative state and begin timer, go into local Protecting administrative state, and begin
transmission of a MS(1,1) message. transmission of an MS(1,1) message.
o A local WTR expires input SHALL cause the LER to remain in Wait- o A local WTR Expires input SHALL cause the LER to remain in Wait-
to-Restore state and begin transmitting a NR(0,1) message. to-Restore state, and begin transmitting an NR(0,1) message.
o All other local inputs SHALL be ignored. o All other local inputs SHALL be ignored.
When in Wait-to-Restore state the following describe the reaction to When in Wait-to-Restore state, the following describe the reaction to
remote messages: remote messages:
o A remote Lockout of protection message SHALL cause the LER to Stop o A remote Lockout of protection message SHALL send the Stop command
the WTR timer, go into remote Unavailable state, and begin to the WTR timer, go into remote Unavailable state, and begin
transmitting a NR(0,0) message. transmitting an NR(0,0) message.
o A remote Forced switch message SHALL cause the LER to Stop the WTR o A remote Forced Switch message SHALL send the Stop command to the
timer, go into remote Protecting administrative state, and begin WTR timer, go into remote Protecting administrative state, and
transmission of a NR(0,1) message. begin transmission of an NR(0,1) message.
o A remote Signal Fail message for the protection path SHALL cause o A remote Signal Fail message for the protection path SHALL send
the LER to Stop the WTR timer, go into remote Unavailable state, the Stop command to the WTR timer, go into remote Unavailable
and begin transmission of a NR(0,0) message. state, and begin transmission of an NR(0,0) message.
o A remote Signal Fail message for the working path SHALL cause the o A remote Signal Fail message for the working path SHALL send the
LER to Stop the WTR timer, go into remote Protecting failure Stop command to the WTR timer, go into remote Protecting failure
state, and begin transmission of a NR(0,1) message. state, and begin transmission of an NR(0,1) message.
o A remote Manual switch message SHALL cause the LER to Stop the WTR o A remote Manual Switch message SHALL send the Stop command to the
timer, go into remote Protecting administrative state and begin WTR timer, go into remote Protecting administrative state, and
transmission of a NR(0,1) message. begin transmission of an NR(0,1) message.
o If the WTR timer is running then a remote NR message SHALL be o If the WTR timer is running, then a remote NR message SHALL be
ignored. If the WTR timer is stopped then a remote NR message ignored. If the WTR timer is stopped, then a remote NR message
SHALL cause the LER to go into Normal state. SHALL cause the LER to go into Normal state.
o All other remote messages SHALL be ignored. o All other remote messages SHALL be ignored.
4.3.3.6. Do-not-revert state 4.3.3.6. Do-not-Revert State
Do-not-revert state is a continuation of the Protecting failure Do-not-Revert state is a continuation of the Protecting failure state
state. When the protection domain is configured for non-revertive when the protection domain is configured for non-revertive behavior.
behavior. While in Do-not-revert state, data traffic SHALL continue While in Do-not-Revert state, data traffic SHALL continue to be
to be transported on the protection path until the administrator transported on the protection path until the administrator sends a
sends a command to revert to the Normal state. It should be noted command to revert to Normal state. It should be noted that there is
that there is a fundamental difference between this state and Normal a fundamental difference between this state and Normal -- whereas
- whereas Forced Switch in Normal state actually causes a switch in Forced Switch in Normal state actually causes a switch in the
the transport path used, in Do-not-revert state the Forced switch transport path used, in Do-not-Revert state, the Forced Switch just
just switches the state (to Protecting administrative state) but the switches the state (to Protecting administrative state) but the
traffic would continue to be transported on the protection path! To traffic would continue to be transported on the protection path! To
revert back to Normal state the administrator SHALL issue a Lockout revert back to Normal state, the administrator SHALL issue a Lockout
of protection command followed by a Clear command. of protection command followed by a Clear command.
When in Do-not-revert state the following describe the reaction to When in Do-not-Revert state, the following describe the reaction to
local input: local input:
o A local Lockout of protection command SHALL cause the LER to go o A local Lockout of protection command SHALL cause the LER to go
into local Unavailable state and begin transmitting a LO(0,0) into local Unavailable state and begin transmitting an LO(0,0)
message. message.
o A local Forced switch command SHALL cause the LER to go into local o A local Forced Switch command SHALL cause the LER to go into local
Protecting administrative state and begin transmission of a Protecting administrative state and begin transmission of an
FS(1,1) message. FS(1,1) message.
o A local Signal Fail indication on the protection path SHALL cause o A local Signal Fail indication on the protection path SHALL cause
the LER to go into local Unavailable state and begin transmission the LER to go into local Unavailable state and begin transmission
of a SF(0,0) message. of an SF(0,0) message.
o A local Signal Fail indication on the working path SHALL cause the o A local Signal Fail indication on the working path SHALL cause the
LER to go into local Protecting failure state and begin LER to go into local Protecting failure state and begin
transmission of a SF(1,1) message. transmission of an SF(1,1) message.
o A local Manual switch input SHALL cause the LER to go into local o A local Manual Switch input SHALL cause the LER to go into local
Protecting administrative state and begin transmission of a Protecting administrative state and begin transmission of an
MS(1,1) message. MS(1,1) message.
o All other local inputs SHALL be ignored. o All other local inputs SHALL be ignored.
When in Do-not-revert state the following describe the reaction to When in Do-not-Revert state, the following describe the reaction to
remote messages: remote messages:
o A remote Lockout of protection message SHALL cause the LER to go o A remote Lockout of protection message SHALL cause the LER to go
into remote Unavailable state and begin transmitting a NR(0,0) into remote Unavailable state and begin transmitting an NR(0,0)
message. message.
o A remote Forced switch message SHALL cause the LER to go into o A remote Forced Switch message SHALL cause the LER to go into
remote Protecting administrative state and begin transmission of a remote Protecting administrative state and begin transmission of
NR(0,1) message. an NR(0,1) message.
o A remote Signal Fail message for the protection path SHALL cause o A remote Signal Fail message for the protection path SHALL cause
the LER to go into remote Unavailable state and begin transmission the LER to go into remote Unavailable state and begin transmission
of a NR(0,0) message. of an NR(0,0) message.
o A remote Signal Fail message for the working path SHALL cause the o A remote Signal Fail message for the working path SHALL cause the
LER to go into remote Protecting failure state, and begin LER to go into remote Protecting failure state and begin
transmission of a NR(0,1) message. transmission of an NR(0,1) message.
o A remote Manual switch message SHALL cause the LER to go into o A remote Manual Switch message SHALL cause the LER to go into
remote Protecting administrative state and begin transmission of a remote Protecting administrative state and begin transmission of
NR(0,1) message. an NR(0,1) message.
o All other remote messages SHALL be ignored. o All other remote messages SHALL be ignored.
5. IANA Considerations 5. IANA Considerations
5.1. Pseudowire Associated Channel Type 5.1. Pseudowire Associated Channel Type
In the "Pseudowire Name Spaces (PWE3) IANA" maintains the " In the "Pseudowire Name Spaces (PWE3)" registry, IANA maintains the
Pseudowire Associated Channel Types Registry". "Pseudowire Associated Channel Types" registry.
IANA is requested to assign a new code point from this registry. The IANA has assigned a new code point from this registry. The code
code point shall be assigned form the code point space that requires point has been assigned from the code point space that requires "IETF
"IETF Review" as follows: Review" as follows:
Registry: Registry:
Value Description TLV Follows Reference Value Description TLV Follows Reference
----- ----------------------- ----------- --------------- ------ ----------------------- ----------- ---------------
0xHH Protection State no [this document] 0x0024 Protection State no [this document]
Coordination Protocol - Coordination Protocol -
Channel Type (PSC-CT) Channel Type (PSC-CT)
5.2. PSC Request Field 5.2. PSC Request Field
The IANA is instructed to create and maintain a new registry within IANA has created and maintains a new sub-registry within the
the "Multiprotocol Label Switching Architecture (MPLS)" namespace "Multiprotocol Label Switching (MPLS) Operations, Administration, and
called "MPLS PSC Request Registry". All code points within this Management (OAM) Parameters" registry called the "MPLS PSC Request
registry shall be allocated according to the "Standards Action" Registry". All code points within this registry shall be allocated
procedures as specified in [RFC5226]. according to the "Standards Action" procedure as specified in
[RFC5226].
The PSC Request Field is 4 bits and the values shall be allocated as The PSC Request Field is 4 bits, and the values have been allocated
follows: as follows:
Value Description Reference Value Description Reference
----- --------------------- --------------- ----- --------------------- ---------------
0 No Request [this document] 0 No Request [this document]
1 Do not revert [this document] 1 Do-not-Revert [this document]
2 - 3 Unassigned 2 - 3 Unassigned
4 Wait to restore [this document] 4 Wait-to-Restore [this document]
5 Manual switch [this document] 5 Manual Switch [this document]
6 Unassigned 6 Unassigned
7 Signal Degrade [this document] 7 Signal Degrade [this document]
8 - 9 Unassigned 8 - 9 Unassigned
10 Signal Fail [this document] 10 Signal Fail [this document]
11 Unassigned 11 Unassigned
12 Forced switch [this document] 12 Forced Switch [this document]
13 Unassigned 13 Unassigned
14 Lockout of protection [this document] 14 Lockout of protection [this document]
15 Unassigned 15 Unassigned
5.3. Additional TLVs 5.3. Additional TLVs
The IANA is instructed to create and maintain a new registry within The IANA has created and maintains a new sub-registry within the
the "Multiprotocol Label Switching Architecture (MPLS)" namespace "Multiprotocol Label Switching (MPLS) Operations, Administration, and
called "MPLS PSC TLV Registry". All code points within this registry Management (OAM) Parameters" registry called the "MPLS PSC TLV
shall be allocated according to the "IETF Review" procedures as Registry". All code points within this registry shall be allocated
specified in [RFC5226]. according to the "IETF Review" procedure as specified in [RFC5226].
6. Security Considerations 6. Security Considerations
MPLS-TP is a subset of MPLS and so builds upon many of the aspects of MPLS-TP is a subset of MPLS and so builds upon many of the aspects of
the security model of MPLS. MPLS networks make the assumption that the security model of MPLS. MPLS networks make the assumption that
it is very hard to inject traffic into a network, and equally hard to it is very hard to inject traffic into a network and equally hard to
cause traffic to be directed outside the network. The control plane cause traffic to be directed outside the network. The control-plane
protocols utilize hop-by-hop security, and assume a "chain-of-trust" protocols utilize hop-by-hop security and assume a "chain-of-trust"
model such that end-to-end control plane security is not used. For model such that end-to-end control-plane security is not used. For
more information on the generic aspects of MPLS security, see more information on the generic aspects of MPLS security, see
[RFC5920]. [RFC5920].
This document describes a protocol carried in the G-ACh [RFC5586], This document describes a protocol carried in the G-ACh [RFC5586],
and so is dependent on the security of the G-ACh, itself. The G-ACh and so is dependent on the security of the G-ACh, itself. The G-ACh
is a generalization of the Associated Channel defined in [RFC4385]. is a generalization of the Associated Channel defined in [RFC4385].
Thus, this document relies heavily on the security mechanisms Thus, this document relies heavily on the security mechanisms
provided for the Associated Channel and described in those two provided for the Associated Channel and described in those two
documents. documents.
A specific concern for the G-ACh is that is can be used to provide a A specific concern for the G-ACh is that is can be used to provide a
covert channel. This problem is wider than the scope of this covert channel. This problem is wider than the scope of this
document and does not need to be addressed here, but it should be document and does not need to be addressed here, but it should be
noted that the channel provides end-to-end connectivity and SHOULD noted that the channel provides end-to-end connectivity and SHOULD
NOT be policed by transit nodes. Thus, there is no simple way of NOT be policed by transit nodes. Thus, there is no simple way of
preventing any traffic being carried between in the G-ACh consenting preventing any traffic being carried between in the G-ACh consenting
nodes. nodes.
A good discussion of the data plane security of an associated channel A good discussion of the data-plane security of an associated channel
may be found in [RFC5085]. That document also describes some may be found in [RFC5085]. That document also describes some
mitigation techniques. mitigation techniques.
It should be noted that the G-ACh is essentially connection-oriented It should be noted that the G-ACh is essentially connection oriented
so injection or modification of control messages specified in this so injection or modification of control messages specified in this
document require the subversion of a transit node. Such subversion document require the subversion of a transit node. Such subversion
is generally considered hard in MPLS networks, and impossible to is generally considered hard in MPLS networks and impossible to
protect against at the protocol level. Management level techniques protect against at the protocol level. Management level techniques
are more appropriate. are more appropriate.
However, a new concern for this document is the accidental corruption However, a new concern for this document is the accidental corruption
of messages (through faulty implementations, or random corruption). of messages (through faulty implementations or random corruption).
The main concern is around the Request, FPath and Path fields as a The main concern is around the Request, FPath, and Path fields as a
change to these fields would change the behavior of the peer end change to these fields would change the behavior of the peer end
point. Although this document does not define a way to avoid a point. Although this document does not define a way to avoid a
change in network behavior upon receipt of a message indicating a change in network behavior upon receipt of a message indicating a
change in protection status, the transition between states will change in protection status, the transition between states will
converge on a known and stable behavior in the face of messages which converge on a known and stable behavior in the face of messages that
do not match reality. do not match reality.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank all members of the teams (the Joint The authors would like to thank all members of the teams (the Joint
Working Team, the MPLS Interoperability Design Team in IETF and the Working Team, the MPLS Interoperability Design Team in the IETF, and
T-MPLS Ad Hoc Group in ITU-T) involved in the definition and the T-MPLS Ad Hoc Group in ITU-T) involved in the definition and
specification of MPLS Transport Profile. specification of the MPLS Transport Profile.
8. References 8. Contributing Authors
8.1. Normative References Hao Long
Huawei Technologies Co., Ltd.
F3 Building, Huawei Industrial Park
Bantian, Shenzhen, China
EMail: longhao@huawei.com
Davide Chiara
Ericsson
Via Calda 5, 16152 Genova Italy
EMail: davide.chiara@ericsson.com
Dan Frost
Cisco Systems
EMail: danfrost@cisco.com
Francesco Fondelli
Ericsson
via Moruzzi 1
56100, Pisa
Italy
EMail: francesco.fondelli@ericsson.com
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile", and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009. RFC 5654, September 2009.
[RFC5586] Vigoureux,, M., Bocci, M., Swallow, G., Aggarwal, R., and 9.2. Informative References
D. Ward, "MPLS Generic Associated Channel", RFC 5586,
May 2009.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, Feb 2006.
8.2. Informative References
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Jan 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, Jan 2001. Encoding", RFC 3032, January 2001.
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, (GMPLS) Architecture", RFC 3945, October 2004.
October 2009.
[RFC5920] Fang, Luyuan., "Security Framework for MPLS and GMPLS [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Networks", RFC 5920, July 2010. Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] Bryant, S. and P. Pate, "Pseudowire Emulation Edge-to-Edge [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and
(PWE3) Architecture", RFC 3985, March 2005. Restoration) Terminology for Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", RFC 4872,
May 2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007. Pseudowires", RFC 5085, December 2007.
[TPFwk] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks",
RFC 5921, July 2010.
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery Terminology for
Generalized Multi-Protocol Label Switching", RFC 4427,
Mar 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[SurvivFwk] [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-
Sprecher, N., Farrel, A., and H. Shah, "Multi-protocol Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
Label Switching Transport Profile Survivability October 2009.
Framework", ID draft-ietf-mpls-tp-survive-fwk-06.txt,
June 2010.
[RFC4872] Lang, J., Papadimitriou, D., and Y. Rekhter, "RSVP-TE [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Extensions in Support of End-to-End Generalized Multi- Networks", RFC 5920, July 2010.
Protocol Label Switching (GMPLS) Recovery", RFC 4872,
May 2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
"GMPLS Segment Recovery", RFC 4873, May 2007. Berger, "A Framework for MPLS in Transport Networks",
RFC 5921, July 2010.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport
(GMPLS) Architecture", RFC 3945, Oct 2004. Profile (MPLS-TP) Survivability Framework", RFC 6372,
September 2011.
Appendix A. PSC state machine tables Appendix A. PSC State Machine Tables
The PSC state machine is described in section 4.3.3. This appendix The PSC state machine is described in Section 4.3.3. This appendix
provides the same information but in tabular format. In the event of provides the same information but in tabular format. In the event of
a mismatch between these tables and the text in section 4.3.3, the a mismatch between these tables and the text in Section 4.3.3, the
text is authoritative. Note that this appendix is intended to be a text is authoritative. Note that this appendix is intended to be a
functional description, not an implementation specification. functional description, not an implementation specification.
For the sake of clarity of the table the six states listed in the For the sake of clarity of the table, the six states listed in the
text are split into thirteen states. The logic of the split is to text are split into 13 states. The logic of the split is to
differentiate between the different cases given in the conditional differentiate between the different cases given in the conditional
statements in the descriptions of each state in the text. In statements in the descriptions of each state in the text. In
addition, the remote and local states were split for the Unavailable, addition, the remote and local states were split for the Unavailable,
Protecting failure, and Protecting administrative states. Protecting failure, and Protecting administrative states.
There is only one table for the PSC state machine, but it is broken There is only one table for the PSC state machine, but it is broken
into two parts for space reasons. The first part lists the thirteen into two parts for space reasons. The first part lists the 13
possible states, the eight possible local inputs (that is, inputs possible states, the eight possible local inputs (that is, inputs
which are generated by the node in question) and the action taken that are generated by the node in question), and the action taken
when a given input is received when the node is in a particular when a given input is received when the node is in a particular
state. The second part of the table lists the thirteen possible state. The second part of the table lists the 13 possible states and
states and the eight remote inputs (inputs which come from a node the eight remote inputs (inputs that come from a node other than the
other than the one executing the state machine). one executing the state machine).
There are thirteen rows in the table, headers notwithstanding. These There are 13 rows in the table, headers notwithstanding. These rows
rows are the thirteen possible extended states in the state machine. are the 13 possible extended states in the state machine.
The text in the first column is the current state. Those states The text in the first column is the current state. Those states that
which have both source and cause are formatted as State:Cause:Source. have both source and cause are formatted as State:Cause:Source. For
For example, the string UA:LO:L indicates that the current state is example, the string UA:LO:L indicates that the current state is
'Unavailable', that the cause of the current state is a Lockoutof 'Unavailable', that the cause of the current state is a Lockout of
protection that was a Local input. In contrast, the state N simply protection that was a local input. In contrast, the state N simply
is Normal; there is no need to track the cause for entry into Normal is Normal; there is no need to track the cause for entry into Normal
state. state.
The thirteen extended states, as they appear in the table, are: The 13 extended states, as they appear in the table, are as follows:
N Normal state N Normal state
UA:LO:L Unavailable state due to local Lockout UA:LO:L Unavailable state due to local Lockout
UA:P:L Unavailable state due to local SF on protection path UA:P:L Unavailable state due to local SF on protection path
UA:LO:R Unavailable state due to remote Lockout message UA:LO:R Unavailable state due to remote Lockout of protection message
UA:P:R Unavailable state due to remote SF message on protection path UA:P:R Unavailable state due to remote SF message on protection path
PF:W:L Protecting failure state due to local SF on working path PF:W:L Protecting failure state due to local SF on working path
PF:W:R Protecting failure state due to remote SF message on working PF:W:R Protecting failure state due to remote SF message on working
path path
PA:F:L Protecting administrative state due to local FS operator PA:F:L Protecting administrative state due to local FS operator
command command
PA:M:L Protecting administrative state due to local MS operator PA:M:L Protecting administrative state due to local MS operator
command command
PA:F:R Protecting administrative state due to remote FS message PA:F:R Protecting administrative state due to remote FS message
PA:M:R Protecting administrative state due to remote MS message PA:M:R Protecting administrative state due to remote MS message
WTR Wait-to-restore state WTR Wait-to-Restore state
DNR Do-not-revert state DNR Do-not-Revert state
Each state corresponds to the transmission of a particular set of Each state corresponds to the transmission of a particular set of
Request, FPath and Path bits. The table below lists the message that Request, FPath and Path bits. The table below lists the message that
is generally sent in each particular state. If the message to be 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 sent in a particular state deviates from the table below, it is noted
in the footnotes to the state-machine table. in the footnotes to the state-machine table.
State REQ(FP,P) State REQ(FP,P)
------- --------- ------- ---------
N NR(0,0) N NR(0,0)
skipping to change at page 38, line 20 skipping to change at page 41, line 4
UA:LO:R NR(0,0) UA:LO:R NR(0,0)
UA:P:R NR(0,0) UA:P:R NR(0,0)
PF:W:L SF(1,1) PF:W:L SF(1,1)
PF:W:R NR(0,1) PF:W:R NR(0,1)
PA:F:L FS(1,1) PA:F:L FS(1,1)
PA:M:L MS(1,1) PA:M:L MS(1,1)
PA:F:R NR(0,1) PA:F:R NR(0,1)
PA:M:R NR(0,1) PA:M:R NR(0,1)
WTR WTR(0,1) WTR WTR(0,1)
DNR DNR(0,1) DNR DNR(0,1)
The top row in each table is the list of possible inputs. The local The top row in each table is the list of possible inputs. The local
inputs are: inputs are as follows:
NR No Request NR No Request
OC Operator Clear OC Operator Clear
LO Lockout of protection LO Lockout of protection
SF-P Signal Fail on protection path SF-P Signal Fail on protection path
SF-W Signal Fail on working path SF-W Signal Fail on working path
FS Forced Switch FS Forced Switch
SFc Clear Signal Fail SFc Clear Signal Fail
MS Manual Switch MS Manual Switch
WTRExp WTR Expired WTRExp WTR Expired
and the remote inputs are: and the remote inputs are as follows:
LO remote LO message LO remote LO message
SF-P remote SF message indicating protection path SF-P remote SF message indicating protection path
SF-W remote SF message indicating working path SF-W remote SF message indicating working path
FS remote FS message FS remote FS message
MS remote MS message MS remote MS message
WTR remote WTR message WTR remote WTR message
DNR remote DNR message DNR remote DNR message
NR remote NR message NR remote NR message
Section 4.3.3 refers to some states as 'remote' and some as 'local'. 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 By definition, all states listed in the table of local sources are
local states, and all states listed in the table of remote sources 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 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 Lockout of protection input SHALL cause the LER to go into local
Unavailable State". As the trigger for this state change is a local Unavailable state". As the trigger for this state change is a local
one, 'local Unavailable State' is by definition displayed in the one, 'local Unavailable state' is, by definition, displayed in the
table of local sources. Similarly, "A remote Lockout of protection table of local sources. Similarly, Section 4.3.3.1 also states that
message SHALL cause the LER to go into remote Unavailable state"
means that the state represented in the Unavailable rows in the table "A remote Lockout of protection message SHALL cause the LER to go
of remote sources is by definition a remote Unavailable state. 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 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 the letter 'i'. 'i' stands for Ignore, and is an indication to
continue with the current behavior. See section 4.3.3. The continue with the current behavior. See Section 4.3.3. The
footnotes are listed below the table. footnotes are listed below the table.
Part 1: Local input state machine Part 1: Local input state machine
| OC | LO | SF-P | FS | SF-W | SFc | MS | WTRExp | 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 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:LO:L | N | i | i | i | i | i | i | i
UA:P:L | i |UA:LO:L| i |PA:F:L| i | [5] | i | i UA:P:L | i |UA:LO:L| i |PA:F:L| i | [5] | i | i
UA:LO:R | i |UA:LO:L| [1] | i | [2] | [6] | i | i UA:LO:R | i |UA:LO:L| [1] | i | [2] | [6] | i | i
skipping to change at page 39, line 37 skipping to change at page 42, line 29
PA:M:R | i |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i |PA:M:L| 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] 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 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 Part 2: Remote messages state machine
| LO | SF-P | FS | SF-W | MS | WTR | DNR | NR | 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 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:LO:L | i | i | i | i | i | i | i | i
UA:P:L | [10] | i | i |PF:W:R| i | i | i | i UA:P:L | [10] | i | [19] | i | i | i | i | i
UA:LO:R | i | i | i | i | i | i | i | [16] UA:LO:R | i | i | i | i | i | i | i | [16]
UA:P:R |UA:LO:R| i | i |PF:W:R| i | i | i | [16] UA:P:R |UA:LO:R| i |PA:F:R| i | i | i | i | [16]
PF:W:L | [11] | [12] |PA:F:R| i | i | i | i | i PF:W: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 PF:W:R |UA:LO:R|UA:P:R|PA:F:R| i | i | [14] | [15] | N
PA:F:L |UA:LO:R| i | i | i | i | i | i | i PA:F:L |UA:LO:R| i | i | i | i | i | i | i
PA:M:L |UA:LO:R|UA:P:R|PA:F:R| [13] | i | i | i | i PA:M:L |UA:LO:R|UA:P:R|PA:F:R| [13] | i | i | i | i
PA:F:R |UA:LO:R| i | i | i | i | i | i | [17] PA:F:R |UA:LO:R| i | i | i | i | i | DNR | [17]
PA:M:R |UA:LO:R|UA:P:R|PA:F:R| [13] | i | i | i | N PA:M:R |UA:LO:R|UA:P:R|PA:F:R| [13] | i | i | DNR | N
WTR |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i | i | [18] 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 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: The following are the footnotes for the table:
[1] Remain in the current state (UA:LO:R) and transmit SF(0,0) [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) [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) [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) [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, [5] If the SF being cleared is SF-P, transition to N. If it's
ignore the clear. SF-W, ignore the clear.
[6] Remain in current state (UA:x:R), if the SFc corresponds to a [6] Remain in current state (UA:x:R), if the SFc corresponds to a
previous SF then begin transmitting NR(0,0). previous SF, then begin transmitting NR(0,0).
[7] If domain configured for revertive behavior transition to WTR, [7] If domain configured for revertive behavior transition to WTR,
else transition to DNR else transition to DNR.
[8] Remain in PA:F:R and transmit NR(0,1) [8] Remain in PA:F:R and transmit NR(0,1).
[9] Remain in WTR, send NR(0,1) [9] Remain in WTR, send NR(0,1).
[10] Transition to UA:LO:R continue sending SF(0,0) [10] Transition to UA:LO:R continue sending SF(0,0).
[11] Transition to UA:LO:R and send SF(1,0) [11] Transition to UA:LO:R and send SF(1,0).
[12] Transition to UA 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) [13] Transition to PF:W:R and send NR(0,1).
[14] Transition to WTR state and continue to send the current [14] Transition to WTR state and continue to send the current
message. message.
[15] Transition to DNR state and continue to send the current [15] Transition to DNR state and continue to send the current
message. message.
[16] If the local input is SF-P then transition to UA:P:L. If the [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 local input is SF-W, then transition to PF:W:L. Else,
state and continue to send the current message. 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 - [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. transition to N state and continue to send the current message.
[18] If the receiving LER's WTR timer is running, maintain current [18] If the receiving LER's WTR timer is running, maintain current
state and message. If the WTR timer is stopped, transition to N. state and message. If the WTR timer is stopped, transition to
N.
Appendix B. Exercising the protection domain [19] Transition to PA:F:R and send SF (0,1).
Appendix B. Exercising the Protection Domain
There is a requirement in [RFC5654] (number 84) that discusses a There is a requirement in [RFC5654] (number 84) that discusses a
requirement to verify that the protection path is viable. While the requirement to verify that the protection path is viable. While the
PSC protocol does not define a specific operation for this PSC protocol does not define a specific operation for this
functionality, it is possible to perform this operation by combining functionality, it is possible to perform this operation by combining
operations of the PSC and other OAM functionalities. One such operations of the PSC and other OAM functionalities. One such
possible combination would be to issue a Lockout of Protection possible combination would be to issue a Lockout of protection
operation and then use the OAM function for diagnostic testing of the operation and then use the OAM function for diagnostic testing of the
protection path. Similarly, to test the paths when the working path protection path. Similarly, to test the paths when the working path
is not active would involve performing a Forced Switch to protection is not active would involve performing a Forced Switch to protection
and then perform the diagnostic function on either the working or and then perform the diagnostic function on either the working or
protection path. protection path.
Authors' Addresses Authors' Addresses
Yaacov Weingarten (editor)
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon 45241
Israel
EMail: yaacov.weingarten@nsn.com
Stewart Bryant Stewart Bryant
Cisco Cisco
United Kingdom United Kingdom
Email: stbryant@cisco.com EMail: stbryant@cisco.com
Eric Osborne Eric Osborne
Cisco Cisco
United States United States
Email: eosborne@cisco.com EMail: eosborne@cisco.com
Nurit Sprecher Nurit Sprecher
Nokia Siemens Networks Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B 3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241 Hod Hasharon 45241
Israel Israel
Email: nurit.sprecher@nsn.com EMail: nurit.sprecher@nsn.com
Annamaria Fulignoli (editor) Annamaria Fulignoli (editor)
Ericsson Ericsson
Via Moruzzi
Pisa 56100
Italy Italy
Email: annamaria.fulignoli@ericsson.com EMail: annamaria.fulignoli@ericsson.com
Yaacov Weingarten (editor)
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241
Israel
Email: yaacov.weingarten@nsn.com
 End of changes. 347 change blocks. 
707 lines changed or deleted 750 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/