draft-ietf-mpls-tp-linear-protection-02.txt   draft-ietf-mpls-tp-linear-protection-03.txt 
Network Working Group S. Bryant, Ed. Network Working Group S. Bryant, Ed.
Internet-Draft E. Osborne Internet-Draft E. Osborne
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: January 27, 2011 N. Sprecher, Ed. Expires: April 27, 2011 N. Sprecher, Ed.
Nokia Siemens Networks Nokia Siemens Networks
A. Fulignoli, Ed. A. Fulignoli, Ed.
Ericsson Ericsson
Y. Weingarten Y. Weingarten
Nokia Siemens Networks Nokia Siemens Networks
July 26, 2010 October 24, 2010
MPLS-TP Linear Protection MPLS-TP Linear Protection
draft-ietf-mpls-tp-linear-protection-02.txt draft-ietf-mpls-tp-linear-protection-03.txt
Abstract Abstract
The Transport Profile for Multiprotocol Label Switching (MPLS-TP) is The Transport Profile for Multiprotocol Label Switching (MPLS-TP) is
being specified jointly by IETF and ITU-T. This document addresses being specified jointly by IETF and ITU-T. This document addresses
the functionality described in the MPLS-TP Survivability Framework the functionality described in the MPLS-TP Survivability Framework
document [SurvivFwk] and defines a protocol that may be used to document [SurvivFwk] and defines a protocol that may be used to
fulfill the function of the Protection State Coordination for linear fulfill the function of the Protection State Coordination for linear
protection, as described in that document. protection, as described in that document.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 27, 2011. This Internet-Draft will expire on April 27, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 23 skipping to change at page 3, line 23
2.2. Definitions and Terminology . . . . . . . . . . . . . . . 7 2.2. Definitions and Terminology . . . . . . . . . . . . . . . 7
3. Protection switching control logic . . . . . . . . . . . . . . 7 3. Protection switching control logic . . . . . . . . . . . . . . 7
3.1. Protection switching control logical architecture . . . . 7 3.1. Protection switching control logical architecture . . . . 7
3.1.1. Local Request Logic . . . . . . . . . . . . . . . . . 8 3.1.1. Local Request Logic . . . . . . . . . . . . . . . . . 8
3.1.2. Remote Requests . . . . . . . . . . . . . . . . . . . 10 3.1.2. Remote Requests . . . . . . . . . . . . . . . . . . . 10
3.1.3. PSC Process Logic . . . . . . . . . . . . . . . . . . 11 3.1.3. PSC Process Logic . . . . . . . . . . . . . . . . . . 11
3.1.4. PSC Message Generator . . . . . . . . . . . . . . . . 11 3.1.4. PSC Message Generator . . . . . . . . . . . . . . . . 11
3.1.5. Wait-to-Restore (WTR) timer . . . . . . . . . . . . . 12 3.1.5. Wait-to-Restore (WTR) timer . . . . . . . . . . . . . 12
3.1.6. PSC Control States . . . . . . . . . . . . . . . . . . 12 3.1.6. PSC Control States . . . . . . . . . . . . . . . . . . 12
4. Protection state coordination (PSC) protocol . . . . . . . . . 13 4. Protection state coordination (PSC) protocol . . . . . . . . . 13
4.1. Transmission and acceptance of PSC control packets . . . . 13 4.1. Transmission and acceptance of PSC control packets . . . . 14
4.2. Protocol format . . . . . . . . . . . . . . . . . . . . . 14 4.2. Protocol format . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. PSC Ver field . . . . . . . . . . . . . . . . . . . . 15 4.2.1. PSC Ver field . . . . . . . . . . . . . . . . . . . . 15
4.2.2. PSC Request field . . . . . . . . . . . . . . . . . . 15 4.2.2. PSC Request field . . . . . . . . . . . . . . . . . . 15
4.2.3. Protection Type (PT) . . . . . . . . . . . . . . . . . 16 4.2.3. Protection Type (PT) . . . . . . . . . . . . . . . . . 16
4.2.4. Revertive (R) field . . . . . . . . . . . . . . . . . 16 4.2.4. Revertive (R) field . . . . . . . . . . . . . . . . . 17
4.2.5. Fault path (FPath) field . . . . . . . . . . . . . . . 16 4.2.5. Fault path (FPath) field . . . . . . . . . . . . . . . 17
4.2.6. Data path (Path) field . . . . . . . . . . . . . . . . 17 4.2.6. Data path (Path) field . . . . . . . . . . . . . . . . 17
4.3. Principles of Operation . . . . . . . . . . . . . . . . . 17 4.3. Principles of Operation . . . . . . . . . . . . . . . . . 18
4.3.1. Basic operation . . . . . . . . . . . . . . . . . . . 17 4.3.1. Basic operation . . . . . . . . . . . . . . . . . . . 18
4.3.2. Priority of inputs . . . . . . . . . . . . . . . . . . 18 4.3.2. Priority of inputs . . . . . . . . . . . . . . . . . . 19
4.3.3. Operation of PSC States . . . . . . . . . . . . . . . 19 4.3.3. Operation of PSC States . . . . . . . . . . . . . . . 20
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . . 28 8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . . 28 8.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
The MPLS Transport Profile (MPLS-TP) [TPFwk] is a framework for the The MPLS Transport Profile (MPLS-TP) [TPFwk] 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
skipping to change at page 4, line 42 skipping to change at page 4, line 42
It is fully allocated in the sense that the route and bandwidth of It is fully allocated in the sense that the route and bandwidth of
the recovery path is reserved for a selected working path or set of the recovery path is reserved for a selected working path or set of
working paths. It provides a fast and simple survivability 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 state of the network, compared to other survivability active state of the network, compared to other survivability
mechanisms. mechanisms.
As specified in the Survivability Framework document [SurvivFwk], As specified in the Survivability Framework document [SurvivFwk],
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 P2P purposes of this document, we define the protection domain of a P2P
LSP as consisting of two Label Switching Routers (LER) and the LSP as consisting of two Label Edge Routers (LER) and the transport
transport paths that connect them. For a P2MP LSP the protection paths that connect them. For a P2MP LSP the protection domain
domain includes the root (or source) LER, the destination (or sink) includes the root (or source) LER, the destination (or sink) LERs,
LSRs, and the transport paths that connect them. and the transport paths that connect them.
In 1+1 unidirectional architecture as presented in [SurvivFwk], a In 1+1 unidirectional architecture as presented in [SurvivFwk], a
recovery transport path is dedicated to each working transport path. recovery 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 recovery transport entities by a permanent bridge the working and the recovery transport entities by a permanent bridge
at the source of the protection domain. The sink of the protection at the source of the protection domain. The sink of the protection
domain selects which of the working or recovery entities to receive domain selects which of the working or recovery entities to receive
the traffic from, based on a predetermined criteria, e.g. server the traffic from, based on a predetermined criteria, e.g. server
defect indication. When used for bidirectional switching the 1+1 defect indication. When used for bidirectional switching the 1+1
protection architecture must also support a Protection State 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
synchronize the decisions of both ends of the protection domain in coordinate between both ends of the protection domain in selecting
selecting the proper traffic flow. the proper traffic flow.
In the 1:1 architecture, a recovery transport path is dedicated to In the 1:1 architecture, a recovery transport path is dedicated to
the working transport path of a single service. However, the normal the working transport path of a single service and the traffic is
traffic is transmitted only once, on either the working or the only transmitted either on the working or the recovery path, by using
recovery path, by using a selector bridge at the source of the a selector bridge at the source of the protection domain. A selector
protection domain. A selector at the sink of the protection domain at the sink of the protection domain then selects the path that
then selects the path that carries the normal traffic. Since the carries the normal traffic. Since the source and sink need to be
source and sink need to be coordinated to ensure that the selector coordinated to ensure that the selector bridge at both ends select
bridge at both ends select the same path, this architecture must the same path, this architecture must support a PSC protocol.
support a PSC protocol.
The 1:n protection architecture extends this last architecture by The 1:n protection architecture extends the 1:1 architecture above by
sharing the recovery path amongst n services. Again, the recovery sharing the recovery path amongst n services. Again, the recovery
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 only once, similar to the 1:1 traffic for each service is transmitted either on the normal working
case by using a selector bridge at the source, either on the normal path for that service or, in cases that trigger protection switching
working path for that service or, in cases that trigger protection (as defined in [SurvivFwk]), may be sent on the recovery path. The
switching (as defined in [SurvivFwk]), may be sent on the recovery switching action is similar to the 1:1 case where a selector bridge
path. It should be noted that in cases where multiple working path is used at the source. It should be noted that in cases where
services have triggered protection switching that some services, multiple working path services have triggered protection switching
dependent upon their Service Level Agreement (SLA), may not be that some services, dependent upon their Service Level Agreement
transmitted as a result of limited resources on the recovery path. (SLA), may not be transmitted as a result of limited resources on the
In this architecture there may be a need for coordination of the recovery path. In this architecture there may be a need for
protection switching, and in addition there is need for resource coordination of the protection switching, and also for resource
allocation negotiation. Due to the added complexity of this allocation negotiation. The procedures for this are for further
architecture, the procedures for this will be delayed to a different study and may be addressed in future documents.
document and further study.
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 [SurvivFwk] 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
maintain traffic over a co-routed bidirectional LSP. maintain traffic over a co-routed bidirectional LSP.
The scope of this draft is to present a protocol for the Protection The scope of this draft is to present a protocol for the Protection
State Coordination of Linear Protection. The protocol addresses the State Coordination of Linear Protection. The protocol addresses the
protection of LSPs in an MPLS-TP network as required by [RFC5654] (in protection of LSPs in an MPLS-TP network as required by [RFC5654] (in
particular requirements 63-67 and 74-79) and described in particular requirements 63-67 and 74-79) and described in
[SurvivFwk]. The basic protocol is designed for use in conjunction [SurvivFwk]. The basic protocol is designed for use in conjunction
with the 1:1 protection architecture (for both unidirectional and with the 1:1 protection architecture (for both unidirectional and
skipping to change at page 6, line 16 skipping to change at page 6, line 14
path (for both unidirectional and bidirectional protection path (for both unidirectional and bidirectional protection
switching). Applicability of the protocol for 1:n protection schemes switching). Applicability of the protocol for 1:n protection schemes
may be documented in a future document. The applicability of this may be documented in a future document. The applicability of this
protocol to additional MPLS-TP constructs and topologies may be protocol to additional MPLS-TP constructs and topologies may be
documented in future documents. 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]. definition of [RFC5654].
1.3. Contributing authors 1.3. Contributing authors
Hao Long (Huawei), Dan Frost (Cisco), Davide Chiara (Ericsson), Hao Long (Huawei), Dan Frost (Cisco), Davide Chiara (Ericsson),
Francesco Fondelli (Ericsson), Francesco Fondelli (Ericsson),
2. Conventions used in this document 2. Conventions used in this document
skipping to change at page 7, line 17 skipping to change at page 7, line 17
This draft uses the following acronyms: This draft uses the following acronyms:
DNR Do not revert DNR Do not revert
FS Forced Switch FS Forced Switch
G-ACh Generic Associated Channel Header G-ACh Generic Associated Channel Header
LER Label Switching Router LER Label Switching Router
MPLS-TP Transport Profile for MPLS MPLS-TP Transport Profile for MPLS
MS Manual Switch MS Manual Switch
P2P Point-to-point P2P Point-to-point
P2MP Point-to-multipoint P2MP Point-to-multipoint
PDU Packet Data Unit
PSC Protection State Coordination Protocol PSC Protection State Coordination Protocol
PST Path Segment Tunnel PST Path Segment Tunnel
SD Signal Degrade SD Signal Degrade
SF Signal Fail SF Signal Fail
SLA Service Level Agreement SLA Service Level Agreement
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 [SurvivFwk].
In addition, we use the term LER to refer to a MPLS-TP Network In addition, we use the term LER to refer to a MPLS-TP Network
Element, whether it is a LER, LER, T-PE, or S-PE. Element, whether it is a LSR, LER, T-PE, or S-PE.
3. Protection switching control logic 3. Protection switching control logic
3.1. Protection switching control logical architecture 3.1. Protection switching control logical architecture
Protection switching processes the local triggers described in Protection switching processes the local triggers described in
[RFC5654] requirements 74-79 together with inputs received from the requirements 74-79 of [RFC5654] together with inputs received from
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 Bridge to protection switching actions, e.g. switching the Selector Bridge to
select the working or protection path, and transmit different select the working or protection path, and transmit different
protocol messages. protocol messages.
The following figure shows the logical decomposition of the PSC The following figure shows the logical decomposition of the PSC
Control Logic into different logical processing units. These Control Logic into different logical processing units. These
processing units are presented in subsequent sub-sections of this processing units are presented in subsequent subsections of this
document. document.
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 |
skipping to change at page 9, line 6 skipping to change at page 9, line 6
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.1. Local Request Logic 3.1.1. Local Request Logic
The protection switching logic processes input triggers from five The protection switching logic processes input triggers from five
sources: sources:
o Operator command - the network operator may issue commands that o Operator command - the network operator may issue commands that
trigger protection switching. The commands that are supported trigger protection switching. The supported commands are Forced
include - Forced Switch, Manual Switch, Clear, Lockout of Switch, Manual Switch, Clear, Lockout of Protection, (see
Protection, (see definitions in [RFC4427]). definitions in [RFC4427]).
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, and therefore this
input MAY be controlled by a holdoff-timer that SHOULD be input MAY be controlled by a holdoff-timer that SHOULD be
configurable by the network operator. configurable by the network operator.
o Control plane - if there is a control plane active in the network o Control plane - if there is a control plane active in the network
(either signaling or routing), it MAY trigger protection switching (either signaling or routing), it MAY trigger protection switching
based on conditions detected by the control plane. If the based on conditions detected by the control plane. If the control
control-plane is based on GMPLS [RFC3945] then the recovery plane is based on GMPLS [RFC3945] then the recovery process SHALL
process SHALL comply with the process described in [RFC4872]. comply with the process described in [RFC4872].
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 the MPLS-TP tools may detect a failure or degrade condition on the MPLS-TP
transport path and this SHOULD input an indication to the Local transport path and this SHOULD input an indication to the Local
Request Logic. 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 SHOULD revert to the normal when it expires and the end point SHOULD revert to the normal
transmission of the user data traffic. transmission of the user data traffic.
The Local request logic SHALL process these different input sources The Local request logic SHALL process these different input sources
and, based on the priorities between them, SHOULD produce a current and, based on the priorities between them, SHOULD produce a current
local request. The different local requests that may be output from local request. The different local requests that may be output from
the Local Request Logic are: the Local Request Logic are:
o Clear - if the opeartor 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 disable o Lockout of Protection (LO) - if the operator requested to disable
the protection path. the protection path.
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,
skipping to change at page 10, line 25 skipping to change at page 10, line 25
Operator command. Operator command.
o WTR Expires - generated by the WTR timer completing its period. o WTR Expires - generated by the WTR timer completing its period.
If none of the input sources have generated any input then the If none of the input sources have generated any input then the
current local request SHALL be a No Request (NR) request. current local request SHALL be a No Request (NR) request.
3.1.2. Remote Requests 3.1.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 sub-section, 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.
These remote messages indicate the status of the transport path from These remote messages indicate the status of the transport path from
the viewpoint of the far-end LER, and may indicate if the local MEP the viewpoint of the far-end LER, and may indicate if the local MEP
SHOULD initiate a protection switch operation. SHOULD initiate a protection switch operation.
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 SHALL include an protection domain. This remote message SHALL include an
indication of which transport path is affected by the SF indication of which transport path is affected by the SF
condition. In addition, it should be noted that the SF condition condition. In addition, it should be noted that the SF condition
may be either unidirectional or bidirectional failure, even if the may be either a unidirectional or a bidirectional failure, even if
transport path is bidirectional. the transport 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
Signal Degrade condition on one of the transport paths in the Signal Degrade condition on one of the transport paths in the
protection domain. This remote message SHALL include an protection domain. This remote message SHALL include an
indication of which transport path is affected by the SD indication of which transport path is affected by the SD
condition. In addition, it should be noted that the SD condition condition. In addition, it should be noted that the SD condition
may be either unidirectional or bidirectional failure, even if the may be either a unidirectional or a bidirectional failure, even if
transport path is bidirectional. the transport path is bidirectional.
o Remote FS - indicates that the remote end point is operating under o Remote FS - indicates that the remote end point is operating under
an operator command to switch the traffic to the protection path. an operator command to switch the traffic to the protection path.
o Remote MS - indicates that the remote end point is operating under o Remote MS - indicates that the remote end point is operating under
an operator command to switch the traffic to the path that was not an operator command to switch the traffic to the path that was not
being used previously. being used previously.
o Remote WTR - indicates that the remote end-point has determined o Remote WTR - indicates that the remote end point has determined
that the failure condition has recovered and has started its WTR that the failure condition has recovered and has started its WTR
timer in preparation for reverting to the Normal state. timer in preparation for reverting to the Normal state.
o Remote DNR - indicates that the remote end-point has determined o Remote DNR - indicates that the remote end point has determined
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.1.3. PSC Process Logic 3.1.3. PSC Process Logic
The PSC Process Logic SHALL accept as input - a. the Local request The PSC Process Logic SHALL accept as input -
output from the Local Request Logic, b. the remote request message
from the remote end-point of the transport path, and c. the current
state of the PSC Control Logic (maintained internally by the PSC
Control Logic). Based on the priorities between the different
inputs, the PSC Process Logic SHALL determine the new state of the
PSC Control Logic and what actions need to be taken.
The new state information SHALL be sent for retention by the State a. the Local request output from the Local Request Logic,
Manager, while the requested action SHALL be sent to the PSC Message
b. the remote request message from the remote end point of the
transport path, and
c. the current state of the PSC Control Logic (maintained internally
by the PSC Control Logic).
Based on the priorities between the different inputs, the PSC Process
Logic SHALL determine the new state of the PSC Control Logic and what
actions need to be taken.
The new state information should be retained by the PSC Process
Logic, while the requested action SHALL be sent to the PSC Message
Generator (see subsection 3.1.4) to generate and transmit the proper Generator (see subsection 3.1.4) to generate and transmit the proper
PSC message to be transmitted to the remote end-point of the PSC message to be transmitted to the remote end point of the
protection domain. protection domain.
3.1.4. PSC Message Generator 3.1.4. PSC Message Generator
Based on the action output from the Process Logic this unit formats Based on the action output from the Process Logic this unit formats
the PSC protocol message that is transmitted to the remote end-point the PSC protocol message that is transmitted to the remote end point
of the protection domain. When the PSC information has changed three of the protection domain. When the PSC information has changed,
PSC messages SHOULD be transmitted in quick succession, and three PSC messages SHOULD be transmitted in quick succession, and
subsequent messages should be transmitted continually at a slower subsequent messages should be transmitted continually at a lower
rate. rate.
The transmission of three rapid packets allows for fast protection The transmission of three rapid packets allows for fast protection
switching even if one or two PSC messages are lost or corrupted. For switching even if one or two PSC messages are lost or corrupted. For
protection switching within 50ms, it is RECOMMENDED that the default protection switching within 50ms, it is RECOMMENDED that the default
interval of the first three PSC messages SHOULD be no larger than interval of the first three PSC messages SHOULD be no larger than
3.3ms. The subsequent messages SHOULD be transmitted with an 3.3ms. The subsequent messages SHOULD be transmitted with an
interval of 5 sec, to avoid traffic congestion. interval of 5 sec, to avoid traffic congestion.
3.1.5. Wait-to-Restore (WTR) timer 3.1.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 WTR protection domain is configured for revertive behavior. The WTR may
timer MAY be started, stopped, or expire. If the WTR timer is be in one of two states - either Running or Stopped. The WTR timer
running, sending a Stop command SHALL reset the timer but SHALL NOT MAY be started or stopped by the PSC Process Logic.
generate a WTR Expires local signal. If the WTR timer is not
running, a Stop command SHALL be ignored. If the WTR timer expires prior to being stopped it SHALL generate a
WTR Expires local signal that shall be processed by the Local Request
Logic. If the WTR timer is running, sending a Stop command SHALL
reset the timer but SHALL NOT generate a WTR Expires local signal.
If the WTR timer is not running, a Stop command SHALL be ignored.
3.1.6. PSC Control States 3.1.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. The state information SHALL include state of the protection domain. The state information SHALL include
information of the current state and an indication of the cause for information of the current state and an indication of the cause for
the current state (e.g. unavailable due to local LO command, the current state (e.g. unavailable due to local LO command,
protecting due to remote FS). In particular, the state information protecting due to remote FS). In particular, the state information
SHOULD include an indication if the state is related to a remote or SHOULD include an indication if the state is related to a remote or
local condition. local condition.
The states that are supported by the PSC Control Logic include: It should be noted that when referring to the "transport" of the data
traffic, in the following descriptions and later in the document that
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
protection path exclusively when using 1:1 protection. When using
1+1 protection, the receiving LER should select the proper
transmission, according to the state of the protection domain.
The states that are supported by the PSC Control Logic are:
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 transmitted over the allocated and active, data traffic is being transported over (or
working path, and no trigger events are reported within the selected from) the working path, and no trigger events are
domain. reported within the domain.
o Unavailable state - The protection path is unavailable - either as o Unavailable state - The protection path is unavailable - either as
a result of an operator Lockout command or a failure/degrade a result of an operator Lockout command or a failure/degrade
condition detected on the protection path. condition 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
transmitted 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 a
SF/SD condition on the working path that is being controlled by 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 is recovering from a o Do-not-revert state - The protection domain is recovering from a
Protecting state, but the operator has configured the protection Protecting state, but the operator has configured the protection
skipping to change at page 13, line 15 skipping to change at page 13, line 33
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.1 for details on what actions are taken by the PSC See section 4.3.1 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.
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 recovery determining which of the two possible paths, the working or recovery
path, is transmitting the data traffic in any given situation. When path, is transmitting the data traffic in any given situation. When
protection switching is triggered as described in section 3.1, the protection switching is triggered as described in section 3.1, the
end-points must inform each other of the switch-over from one path to end points must inform each other of the switch-over from one path to
the other in a coordinated fashion. 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 switch-over 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 must informs the far-end LER of the switch, and the far-end LER MUST
complete the switchover. complete the switchover.
For the sake of simplicity of the protocol, this protocol is based on This protocol is a single-phase protocol, as described above. In the
the single-phase approach described above. In the following sub- following subsections we describe the protocol messages that SHALL be
sections we describe the protocol messages that SHALL be used between used between the two end points of the protection domain.
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 PSC information is changed due to a local input, three PSC When the PSC information is changed due to a local input, three PSC
messages SHOULD be transmitted as quickly as possible, to allow for messages SHOULD be transmitted as quickly as possible, to allow for
rapid protection switching. This set of three rapid messages allows rapid protection switching. This set of three rapid messages allows
for fast protection switching even if one or two of these packets are for fast protection switching even if one or two of these packets are
lost or corrupted. When the PSC information changes due to a remote lost or corrupted. When the PSC information changes due to a remote
message there is no need for the rapid transmission of three messages message there is no need for the aforementioned rapid transmission of
with the following exception - When going from Wait-to-Restore state three messages. The exception (e.g. when the rapid tranmission is
to Normal state as a result of a remote NR message. still required) is when going from WTR state to Normal state as a
result of a remote NR message.
The frequency of the three rapid messages and the separate frequency The frequency of the three rapid messages and the separate frequency
of the continual transmission SHOULD be configurable by the operator. of the continual transmission SHOULD be configurable by the operator.
For protection switching within 50ms, the default interval of the For protection switching within 50ms, the default interval of the
first three PSC messages is RECOMMENDED to be no larger than 3.3ms. first three PSC messages is RECOMMENDED to be no larger than 3.3ms.
The continuous transmission interval is RECOMMENDED to be 5 seconds. The continuous transmission interval is RECOMMENDED to be 5 seconds.
If no valid PSC specific information is received, the last valid If no valid PSC specific information is received, the last valid
received information remains applicable. In the event a signal fail received information remains applicable. In the event a signal fail
condition is detected on the protection path, the received PSC condition is detected on the protection path, the received PSC
skipping to change at page 14, line 49 skipping to change at page 15, line 26
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 MPLS-TP PSC Channel Code is the G-ACh channel number assigned to o MPLS-TP PSC Channel Code is the G-ACh channel number assigned to
the PSC = TBD the PSC = TBD
o The ACH TLV Header is described in [RFC5586] o The ACH TLV Header is described in [RFC5586]
o The following subsections will describe the fields of the PSC o The following subsections describe the 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 the value SHALL be 0. version the value SHALL be 0.
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 (1110) Lockout of protection - indicates that the endpoint has o (1110) 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 SHOULD be set to 0. command. Both the FPath and Path fields SHALL be set to 0.
o (1101) Forced switch - indicates that the transmitting end-point o (1101) Forced switch - indicates that the transmitting end point
has switched traffic to the protection path as a result of an has switched traffic to the protection path as a result of an
administrative command. The Fpath field SHOULD indicate that the administrative command. The Fpath field SHALL indicate that the
working path is being blocked, and the Path field SHOULD indicate working path is being blocked (i.e. Fpath set to 1), and the Path
that user data traffic is being transmitted on the protection field SHALL indicate that user data traffic is being transported
path. on the protection path (i.e. Path set to 1).
o (0110) Signal Fail - indicates that the transmitting end-point has o (0110) 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, and the Path field SHALL indicate reporting the failure condition (i.e. if protection path then
where the data traffic is being transmitted. Fpath set to 0 and if working path then Fpath set to 1), and the
Path field SHALL indicate where the data traffic is being
transported (i.e. if protection path is blocked then Path set to 0
and if working path is blocked then Path set to 1).
o (0100) Manual switch - indicates that the transmitting end-point o (0101) Signal Defect - indicates that that the transmitting end
point has identified a degradation of the signal, or integrity of
the packet transmission on either the working or protection path.
The specifics for the method of identifying this degradation is
out-of-scope for this document. The details of the actions to be
taken for this situation is left for future specification.
o (0100) Manual switch - indicates that the transmitting end point
has switched traffic as a result of an administrative Manual has switched traffic as a result of an administrative Manual
Switch command. The Fpath field SHALL indicate the path that is Switch command. The Fpath field SHALL indicate that the working
the manual switch is being applied to and the Path field SHALL path is being blocked (i.e. Fpath set to 1), and the Path field
indicate the path being utilized by the endpoint to transmit user SHALL indicate that user data traffic is being transported on the
data traffic. protection path (i.e. Path set to 1).
o (0011) Wait to restore - indicates that the transmitting endpoint o (0011) Wait to restore - indicates that the transmitting end point
is recovering from a failure condition of the working path and has is recovering from a failure condition of the working path and has
started the Wait-to-Restore timer. Fpath SHOULD be set to 0 and started the Wait-to-Restore timer. Fpath SHALL be set to 0 and
ignored upon receipt. Path SHOULD indicate the working path that ignored upon receipt. Path SHALL indicate the working path that
is currently being protected. is currently being protected (i.e. Path set to 1).
o (0010) Do not revert - indicates that the transmitting endpoint is o (0010) Do not revert - indicates that the transmitting end point
recovering from a failure/blocked condition, but due to the local is recovering from a failure/blocked condition, but due to the
settings is requesting that the protection domain continues to local settings is requesting that the protection domain continues
transmit data over the protection path, rather than revert to the to transmit data over the protection path, rather than revert to
Normal state. Fpath SHOULD be set to 0 and ignored upon receipt. the Normal state. Fpath SHALL be set to 0 and ignored upon
Path SHOULD indicate the working path that is currently being receipt. Path SHALL indicate the working path that is currently
protected. being protected (i.e. Path set to 1).
o (0000) No request - indicates that the transmitting end-point has o (0000) No request - indicates that the transmitting end point has
nothing to report, Fpath and Path fields SHOULD be set to nothing to report, Fpath and Path fields SHALL be set to according
according to the state of the end-point. to the state of the end point, see section 4.3.3 for detailed
scenarios.
4.2.3. Protection Type (PT) 4.2.3. Protection Type (PT)
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 11: bidirectional switching using a permanent bridge o 11: bidirectional switching using a permanent bridge
skipping to change at page 16, line 32 skipping to change at page 17, line 20
o 00: unidirectional switching using a selector bridge o 00: unidirectional switching using a selector bridge
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 endpoint 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
endpoints, i.e. one end-point is configured for revertive action and end points, i.e. one end point is configured for revertive action and
the second end-point is in non-revertive mode, then the management the second end point is in non-revertive mode, then the management
system SHOULD be notified. Possible values are: system SHOULD be notified. Possible values are:
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
skipping to change at page 17, line 27 skipping to change at page 18, line 16
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 o 2-255: for future extensions
4.3. Principles of Operation 4.3. Principles of Operation
In all of the following sub-sections, 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 basic operation of the coordination protocol is to allow the end- The purpose of the PSC protocol is to allow the end points of the
points to notify their peer of the status that is known to that end- protection domain to notify their peer of the status of the domain
point. The parameters that are notified between the end-points - the that is known at the end point and coordinate the transmission of the
local condition of the protection domain, the blocked path (if there data traffic. The current state of the end point is expressed in the
is a blockage within the protection domain), and the current usage of values of the Request field [reflecting the local requests at that
the protection path. It should be noted that the messages exchanged end point] and the Fpath field [reflecting knowledge of a blocked
between the two end-points may not be the same at a given point in path]. The coordination between the end points is expressed by the
time, although the states of the end-points are coordinated. In value of the Path field [indicating where the data traffic is being
transmitted]. The value of the Path field SHOULD be identical for
both end points at any particular time. The values of the Request
and Fpath fields may not be identical between the two end points.In
particular it should be noted that a remote message MAY not cause the particular it should be noted that a remote message MAY not cause the
end-point to change the Request field that is being transmitted while end point to change the Request field that is being transmitted while
it does affect the Path field (see details in the following it does affect the Path field (see details in the following
subsections). subsections).
The protocol is a single-phase protocol, although it includes a The protocol is a single-phase protocol. Single-phase implies that
possibility to extend the protocol for multiple-phased operation. each end point notifies its peer of a change in the operation
Single-phase implies that each end-point notifies its peer of a (switching to or from the protection path) and makes the switch
change in the operation (switching to or from the protection path) without waiting for acknowledgement.
and makes the switch without waiting for acknowledgement.
The following subsections will identify the messages that are The following subsections will identify the messages that SHALL 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). shown in figure 3). Again it should be noted that when using 1:1
protection the data traffic will be transmitted exclusively on either
the protection or working path, while when using 1+1 protection the
traffic will be transmitted on both paths and the receiving LER
should select the appropriate signal based on the state. The text
will refer to this transmission/selection as "transport" of the data
traffic.
4.3.2. Priority of inputs 4.3.2. Priority of inputs
As noted above (in section 3.1.1) the PSC Control Process accepts As noted above (in section 3.1.1) the PSC Control Process accepts
input from five local input sources. There is a definition of input from five local input sources. There is a definition of
priority between the different inputs that may be triggered locally. priority between the different inputs that may be triggered locally.
The list of local requests in order of priority are (from highest to The list of local requests in order of priority are (from highest to
lowest priority): lowest priority):
1. Clear (Operator command) 1. Clear (Operator command)
2. Lockout of protection (Operator command) 2. Lockout of protection (Operator command)
3. Signal Fail on protection (OAM/Control Plane/Server Indication) 3. Signal Fail on protection (OAM/Control Plane/Server Indication)
4. Forced switch (Operator command) 4. Forced switch (Operator command)
5. Signal Fail on working (OAM/Control Plane/Server Indication) 5. Signal Fail on working (OAM/Control Plane/Server Indication)
6. Clear Signal Fail (OAM/Control Plane/Server Indication) 6. Signal Degrade on working (OAM/Control Plane/Server Indication)
7. Manual switch (Operator command) 7. Clear Signal Fail/Degrade (OAM/Control Plane/Server Indication)
8. WTR expires (WTR Timer) 8. Manual switch (Operator command)
9. WTR expires (WTR Timer)
The determination of whether a remote message is accepted or ignored The determination of whether a remote message is accepted or ignored
is a function of the current state of the local LER and the current is a function of the current state of the local LER and the current
local request (see section 3.1.3). Part of this consideration will local request (see section 3.1.3). Part of this consideration will
be included in the following subsections describing the operation in be included in the following subsections describing the operation in
the different states. the different states.
4.3.3. Operation of PSC States 4.3.3. Operation of PSC States
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 SHOULD 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 recovery path as well. The receiving LER SHOULD read the data to the recovery path as well. The receiving LER SHALL read the
data from the working path. data from the working path.
When the end-point is in Normal State it SHOULD transmit a NR(0,0) When the end point is in Normal State it SHALL transmit a NR(0,0)
message - indicating - Nothing to report and data traffic is being message, indicating - Nothing to report and data traffic is being
transmitted on the working path. transported on the working path.
When the LER (assume LER-A) is in Normal State the following When the LER (assume LER-A) is in Normal State the following
transitions are relevant in reaction to a local input (new state transitions are relevant in reaction to a local input (new state
SHOULD be marked as local): SHOULD be marked as local):
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 to Unavailable State and begin transmission of a LO(0,0) message to
the far-end LER (LER-Z). the far-end LER (LER-Z).
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
skipping to change at page 20, line 29 skipping to change at page 21, line 29
into Protecting administrative state, and transmit a NR(0,1) into Protecting administrative state, and transmit a NR(0,1)
message. message.
o All other remote messages SHOULD be ignored. o All other remote messages SHOULD 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 or SD detected on Lockout operator command, or as a result of a SF or SD detected on
the protection path - then the protection domain is in the the protection path - then the protection domain is in the
unavailable state. In this state, the data traffic is transmitted unavailable state. In this state, the data traffic is transported on
and received on the working path. the working path.
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 resume sending the PSC packets over the situation. Both ends will resume sending the PSC packets over the
protection path, as a result of this recovery. protection path, as a result of this recovery.
When in unavailable state the data traffic is being transmitted on When in unavailable state the data traffic is being transported on
the working path and is not protected. In many cases the remote the working path and is not protected. When the domain is in
messages will not be received (since the protection path is blocked) unavailable state the PSC messages may not get through and therefore
and the main effect will be as a result of local inputs. the protection is more dependent on the local inputs rather than the
remote messages (that may not be received).
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 (new state transitions are relevant in reaction to a local input (new state
SHOULD be marked as local): SHOULD be marked as local):
o A local Clear input SHOULD be ignored if the LER is in remote o A local Clear input SHOULD 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
and begin transmitting a NR(0,0) message. and begin transmitting a NR(0,0) message.
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 Unavailable State and begin transmission of a LO(0,0) message in Unavailable State and begin transmission of a LO(0,0) message
to the far-end LER (LER-Z). to the far-end LER (LER-Z).
o A local Clear SF indication SHOULD be ignored if the LER is in o A local Clear SF in local Unavailable state due to a Signal Fail
remote Unavailable state. If in local Unavailable state due to a on the protection path and the Clear SF indicates that the
Signal Fail on the protection path and the Clear SF indicates that protection path is now cleared, then the input SHALL cause the LER
the protection path is now cleared, then the input SHALL cause the to go to Normal state and begin transmitting a NR(0,0) message.
LER to go to Normal state and begin transmitting a NR(0,0) If the LER is in remote Unavailable state but is under a local SF
message. condition, then the local Clear SF SHALL clear the SF local
condition and the LER SHALL begin transmitting NR(0,0) messages,
maintaining the remote Unavailable state. In all other cases the
local Clear SF SHOULD be ignored.
o A local Forced switch input when in Unavailable state due to a o A local Forced switch SHOULD be ignored by the PSC Process Logic.
local or remote failure condition on the protection path SHALL
cause the LER to go into Protecting administrative state and begin
transmission of a FS(1,1) message. When in Unavailable state due
to local Lockout input - this message SHOULD be filtered out by
the Local Request Logic. If Unavailable due to remote Lockout
input, then this message SHOULD be ignored by the PSC Process
Logic.
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 remain in Unavailable state and begin transmission of a the LER to remain in Unavailable state and begin transmission of a
SF(0,0) message. SF(0,0) message.
o All other local inputs SHOULD be ignored. o All other local inputs SHOULD 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 affect:
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, and continue transmission of the remain in Unavailable state, and continue transmission of the
current message (either NR(0,0) or LO(0,0)) current message (either NR(0,0) or LO(0,0) or SF(0,0))
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)). NR(0,0) or SF(0,0) or LO(0,0)).
o A remote No Report, when the LER is remote Unavailable state SHALL o A remote No Request, when the LER is remote Unavailable state
cause the LER to go into Normal state and begin transmission of a SHALL cause the LER to go into Normal state and begin transmission
NR(0,0) message. When in local Unavailable state, the message of a NR(0,0) message. When in local Unavailable state, the
SHALL be ignored. message SHALL be ignored.
o All other remote messages SHOULD be ignored. o All other remote messages SHOULD be ignored.
4.3.3.3. Protecting administrative state 4.3.3.3. Protecting administrative state
In the protecting state the user data traffic is being transported on In the protecting state the user data traffic is being transported on
the protection path, while the working path is blocked due to an the protection path, while the working path is blocked due to an
operator command, i.e. Forced Switch or Manual Switch. operator command, i.e. Forced Switch or Manual Switch.
The following describe the reaction to local input: The following describe the reaction to local input:
skipping to change at page 22, line 35 skipping to change at page 23, line 27
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 a
SF(0,0) message. SF(0,0) message.
o A local Signal Fail indication on the working path SHOULD be o A local Signal Fail indication on the working path SHOULD be
filtered by the Local Request Logic if the protecting state was filtered by the Local Request Logic if the protecting state was
entered due to an active local Forced switch operator command. If entered due to an active local Forced switch operator command. If
the protecting state is due to a remote Forced switch message, the protecting state is due to a remote Forced switch message,
then this local indication SHOULD be filtered by the PSC Process then this local indication SHOULD be filtered by the PSC Process
Logic. If the current state is due to a (local or remote) Manual Logic. If the current state is due to a (local or remote) Manual
switch operator command, it shall cause the LER to go into switch operator command, it SHALL cause the LER to go into
Protecting failure state and begin transmitting a SF(1,1) message. Protecting failure state and begin transmitting a SF(1,1) message.
o A local Clear SF when in remote Protecting administrative state
SHOULD clear any local SF condition that may exist. The LER SHALL
stop transmitting the SF(1,1) message and begin transmitting an
NR(0,1) message.
o A local Manual switch input SHALL be filtered by the Local Request o A local Manual switch input SHALL be filtered by the Local Request
Logic if there is an active local Forced switch. If the Logic if there is an active local Forced switch. If the
protecting state is due to a remote Forced switch command, then protecting state is due to a remote Forced switch command, then
this local indication SHOULD be filtered by the PSC Process Logic. this local indication SHOULD be filtered by the PSC Process Logic.
If the current state is due to a (local or remote) Manual switch If the current state is due to a (local or remote) Manual switch
operator command, it shall cause the LER to remain in Protecting operator command, it SHALL cause the LER to remain in Protecting
administrative state and begin transmission of a MS(1,1) message. administrative state and begin transmission of a MS(1,1) message.
o All other local inputs SHOULD be ignored. o All other local inputs SHOULD 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 Unavailable state and begin transmitting a NR(0,0) message. into Unavailable state and begin transmitting a NR(0,0) message.
It should be noted that this automatically cancels the current It should be noted that this automatically cancels the current
Forced switch or Manual switch command and data traffic is 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 SHOULD be ignored by the PSC o A remote Forced switch message SHOULD be ignored by the PSC
Process Logic if there is an active local Forced switch operator Process Logic if there is an active local Forced switch operator
command. If the Protecting state is due to a remote Forced switch command. If the Protecting state is due to a remote Forced switch
message then the LER SHALL remain in Protecting administrative message then the LER SHALL remain in Protecting administrative
state and continue transmission of the last message. If the state and continue transmission of the last message. If the
Protecting state is due to either a local or remote Manual switch Protecting state is due to either a local or remote Manual switch
skipping to change at page 23, line 50 skipping to change at page 24, line 46
o A remote DNR(0,0) message SHALL be ignored if in Protecting state o A remote DNR(0,0) message SHALL be ignored if in Protecting state
due to a local input. If in Protecting state due to a remote due to a local input. If in Protecting state due to a remote
message then the LER SHALL go to Do-not-revert state and begin message then the LER SHALL go to Do-not-revert state and begin
transmitting a NR(0,0) message. transmitting a NR(0,0) message.
o A remote NR(0,0) message SHALL be ignored if in Protecting state o A remote NR(0,0) message SHALL be ignored if in Protecting state
due to a local input. If in Protecting state due to a remote due to a local input. If in Protecting state due to a remote
message then the LER SHALL go to Normal state and begin message then the LER SHALL go to Normal state and begin
transmitting a NR(0,0) message. transmitting a NR(0,0) message.
o All other remote messages SHALL be ignored. o All other remote messages SHOULD 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 is protecting failure state. In this state the normal data traffic is
transmitted and received on the protection path. transported on the protection path.
The following describe the reaction to local input: The following describe the reaction to local input:
o A local Clear SF SHOULD be ignored if in remote Protecting state. o A local Clear SF SHOULD be ignored if in remote Protecting state.
If the Clear SF indicates that the protection path is now cleared If the Clear SF indicates that the protection path is now cleared
(but working is still in SF condition) then the indicateion SHOULD (but working is still in SF condition) then the indicateion SHOULD
be ignored. If in local Protecting failure state and the LER is be ignored. 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
skipping to change at page 24, line 47 skipping to change at page 25, line 41
LER to remain in Protecting failure state and begin transmitting a LER to remain in Protecting failure state and begin transmitting a
SF(1,1) message. SF(1,1) message.
o All other local inputs SHOULD be ignored. o All other local inputs SHOULD 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 Unavailable state and if in protecting failure state due to a into Unavailable state and if in protecting failure state due to a
local SF condition begin transmitting a SF(1,0) message, otherwise local SF condition then the LER SHALL begin transmitting a SF(1,0)
transmit a NR(0,0) message. It should be noted that this may message, otherwise it SHALL transmit a NR(0,0) message. It should
cause loss of user data since the working path is still in a be noted that this may cause loss of user data since the working
failure condition. path is still in a failure condition.
o A remote Forced switch message SHALL cause the LER go into o A remote Forced switch message SHALL cause the LER go into
Protecting administrative state and if in protecting failure state Protecting administrative state and if in protecting failure state
due to a local SF condition begin transmitting the SF(1,1) due to a local SF condition the LER SHALL begin transmitting the
message, otherwise begin transmitting NR(0,0). SF(1,1) message, otherwise it SHALL begin transmitting NR(0,0).
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 Unavailable state protection path SHALL cause the LER to go into Unavailable state
and if in protecting failure state due to a local SF condition and if in protecting failure state due to a local SF condition
begin transmitting a SF(1,0) message, otherwise begin transmitting then the LER SHALL begin transmitting a SF(1,0) message, otherwise
NR(0,0) message. It should be noted that this may cause loss of it SHALL begin transmitting NR(0,0) message. It should be noted
user data since the working path is still in a failure condition. that this may cause loss of user data since the working path is
still in a failure condition.
o If in Protecting state due to a remote message, a remote Wait-to- o If in Protecting state due to a remote message, a remote Wait-to-
Restore message SHOULD cause the LER to go into Wait-to-Restore Restore message SHALL cause the LER to go into Wait-to-Restore
state and continue transmission of the current message. state and continue transmission of the current message.
o If in Protecting state due to a remote message, a remote Do-not- o If in Protecting state due to a remote message, a remote Do-not-
revert message SHOULD cause the LER to go into Do-not-revert state revert message SHALL cause the LER to go into Do-not-revert state
and continue transmission of the current message. and continue transmission of the current message.
o All other remote messages SHALL be ignored. o All other remote messages SHOULD 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 The Wait-to-Restore state is used by the PSC protocol to delay
reverting to the normal state, when recovering from a failure reverting to the normal state, when recovering from a failure
condition on the working path, for the period of the WTR timer to condition on the working path, for the period of the WTR timer to
allow the recovering failure to stabilize. While in the Wait-to- allow the recovering failure to stabilize. While in the Wait-to-
Restore state the data traffic SHALL continue to be transmitted on Restore state the data traffic SHALL continue to be transported on
the protection path. The natural transition from the Wait-to-Restore the protection path. The natural transition from the Wait-to-Restore
state to Normal state will occur when the WTR timer expires. state to 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 cause the LER to Stop
the WTR timer, go into Unavailable state, and begin transmitting a the WTR timer, go into Unavailable state, and begin transmitting a
LO(0,0) message. LO(0,0) message.
skipping to change at page 26, line 52 skipping to change at page 27, line 48
ignored. If the WTR timer is no longer running then a remote NR ignored. If the WTR timer is no longer running then a remote NR
message SHALL cause the LER to go into Normal state and begin message SHALL cause the LER to go into Normal state and begin
transmitting a NR(0,0) message. transmitting a NR(0,0) message.
o All other remote messages SHOULD be ignored. o All other remote messages SHOULD 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 state when Do-not-revert state is a continuation of the protecting state when
the protection domain is configured for non-revertive behavior. the protection domain is configured for non-revertive behavior.
While in Do-not-revert state data traffic continues to be transmitted While in Do-not-revert state, data traffic continues to be
on the protection path until the administrator sends a command to transported on the protection path until the administrator sends a
revert to the Normal state. It should be noted that there is a command to revert to the Normal state. It should be noted that there
fundemental difference between this state and Normal - whereas Forced is a fundemental difference between this state and Normal - whereas
Switch in Normal state actually causes a switch in the transport path Forced Switch in Normal state actually causes a switch in the
used, in Do-not-revert state the Forced switch just switches the transport path used, in Do-not-revert state the Forced switch just
state but the traffic would continue to be transmitted on the switches the state (to Protecting administrative state) but the
protection path! The command to revert back to Normal state could traffic would continue to be transported on the protection path! The
either be a Lockout of protection (followed be a Clear command), a command to revert back to Normal state could either be a Lockout of
Clear command, or a new form of the Manual switch command [note: This protection (followed be a Clear command), a Clear command, or a new
would also require some kind of agreement, although it seems to have form of the Manual switch command [note: This would also require some
been adopted by ITU-T in G.8031 for Ethernet]. The following kind of agreement, although it seems to have been adopted by ITU-T in
description of operation is based on the Lockout/Clear option G.8031 for Ethernet]. The following description of operation is
mentioned! based on the Lockout/Clear option mentioned!
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 Unavailable state and begin transmitting a LO(0,0) message. into Unavailable state and begin transmitting a LO(0,0) message.
o A local Forced switch command SHALL cause the LER to go into o A local Forced switch command SHALL cause the LER to go into
Protecting administrative state and begin transmission of a Protecting administrative state and begin transmission of a
FS(1,1) message. FS(1,1) message.
 End of changes. 94 change blocks. 
226 lines changed or deleted 263 lines changed or added

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