draft-ietf-mpls-tp-psc-itu-02.txt   draft-ietf-mpls-tp-psc-itu-03.txt 
MPLS Working Group J. Ryoo, Ed. MPLS Working Group J. Ryoo, Ed.
Internet-Draft ETRI Internet-Draft ETRI
Updates: 6378 (if approved) E. Gray, Ed. Updates: 6378 (if approved) E. Gray, Ed.
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: August 12, 2014 H. van Helvoort Expires: August 28, 2014 H. van Helvoort
Huawei Technologies Huawei Technologies
A. D'Alessandro A. D'Alessandro
Telecom Italia Telecom Italia
T. Cheung T. Cheung
ETRI ETRI
E. Osborne E. Osborne
Cisco Systems, Inc. Cisco Systems, Inc.
February 8, 2014 February 24, 2014
MPLS Transport Profile (MPLS-TP) Linear Protection to Match the MPLS Transport Profile (MPLS-TP) Linear Protection to Match the
Operational Expectations of SDH, OTN and Ethernet Transport Network Operational Expectations of SDH, OTN and Ethernet Transport Network
Operators Operators
draft-ietf-mpls-tp-psc-itu-02.txt draft-ietf-mpls-tp-psc-itu-03.txt
Abstract Abstract
This document describes alternate mechanisms to perform some of the This document describes alternate mechanisms to perform some of the
sub-functions of MPLS Transport Profile (MPLS-TP) linear protection functions of MPLS Transport Profile (MPLS-TP) linear protection
defined in RFC 6378, and also defines additional mechanisms. The defined in RFC 6378, and also defines additional mechanisms. The
purpose of these alternate and additional mechanisms is to provide purpose of these alternate and additional mechanisms is to provide
operator control and experience that more closely models the behavior operator control and experience that more closely models the behavior
of linear protection seen in other transport networks. of linear protection seen in other transport networks.
This document also introduces capabilities and modes for linear This document also introduces capabilities and modes for linear
protection. A capability is an individual behavior, and a mode is a protection. A capability is an individual behavior, and a mode is a
particular combination of capabilities. Two modes are defined in particular combination of capabilities. Two modes are defined in
this document: Protection State Coordination (PSC) mode and Automatic this document: Protection State Coordination (PSC) mode and Automatic
Protection Switching (APS) mode. Protection Switching (APS) mode.
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 August 12, 2014. This Internet-Draft will expire on August 28, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 2, line 38 skipping to change at page 2, line 38
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 5 2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Capability 1: Priority Modification . . . . . . . . . . . . . 6 4. Capability 1: Priority Modification . . . . . . . . . . . . . 6
4.1. Motivations for swapping priorities of FS and SF-P . . . 6 4.1. Motivation for swapping priorities of FS and SF-P . . . . 6
4.2. Motivation for raising the priority of SFc . . . . . . . 7 4.2. Motivation for raising the priority of SFc . . . . . . . 6
4.3. Motivation for introducing Freeze command . . . . . . . . 7 4.3. Motivation for introducing Freeze command . . . . . . . . 7
4.4. Procedures in support of Capability 1 . . . . . . . . . . 7 4.4. Procedures in support of Capability 1 . . . . . . . . . . 7
5. Capability 2: Non-revertive Behavior Modification . . . . . . 8 5. Capability 2: Non-revertive Behavior Modification . . . . . . 7
6. Capability 3: Support of MS-W Command . . . . . . . . . . . . 8 6. Capability 3: Support of MS-W Command . . . . . . . . . . . . 8
6.1. Motivation for adding MS-W . . . . . . . . . . . . . . . 8 6.1. Motivation for adding MS-W . . . . . . . . . . . . . . . 8
6.2. Terminology to support MS-W . . . . . . . . . . . . . . . 9 6.2. Terminology to support MS-W . . . . . . . . . . . . . . . 8
6.3. Behavior of MS-P and MS-W . . . . . . . . . . . . . . . . 9 6.3. Behavior of MS-P and MS-W . . . . . . . . . . . . . . . . 8
6.4. Equal priority resolution for MS . . . . . . . . . . . . 9 6.4. Equal priority resolution for MS . . . . . . . . . . . . 9
7. Capability 4: Support of Protection against SD . . . . . . . 10 7. Capability 4: Support of Protection against SD . . . . . . . 9
7.1. Motivation for supporting protection against SD . . . . . 10 7.1. Motivation for supporting protection against SD . . . . . 9
7.2. Terminology to support SD . . . . . . . . . . . . . . . . 10 7.2. Terminology to support SD . . . . . . . . . . . . . . . . 10
7.3. Behavior of protection against SD . . . . . . . . . . . . 11 7.3. Behavior of protection against SD . . . . . . . . . . . . 10
7.4. Equal priority resolution . . . . . . . . . . . . . . . . 12 7.4. Equal priority resolution . . . . . . . . . . . . . . . . 11
8. Capability 5: Support of EXER Command . . . . . . . . . . . . 13 8. Capability 5: Support of EXER Command . . . . . . . . . . . . 13
9. Capabilities and Modes . . . . . . . . . . . . . . . . . . . 14 9. Capabilities and Modes . . . . . . . . . . . . . . . . . . . 13
9.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 14
9.1.1. Sending and receiving the Capabilities TLV . . . . . 15 9.1.1. Sending and receiving the Capabilities TLV . . . . . 15
9.2. Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.2. Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.2.1. PSC mode . . . . . . . . . . . . . . . . . . . . . . 16 9.2.1. PSC mode . . . . . . . . . . . . . . . . . . . . . . 15
9.2.2. APS mode . . . . . . . . . . . . . . . . . . . . . . 16 9.2.2. APS mode . . . . . . . . . . . . . . . . . . . . . . 16
10. PSC Protocol in APS Mode . . . . . . . . . . . . . . . . . . 16 10. PSC Protocol in APS Mode . . . . . . . . . . . . . . . . . . 16
10.1. Request field in PSC protocol message . . . . . . . . . 16 10.1. Request field in PSC protocol message . . . . . . . . . 16
10.2. Priorities of local inputs and remote requests . . . . . 16 10.2. Priorities of local inputs and remote requests . . . . . 16
10.2.1. Equal priority requests . . . . . . . . . . . . . . 18
10.3. Acceptance and retention of local inputs . . . . . . . . 19 10.3. Acceptance and retention of local inputs . . . . . . . . 19
11. State Transition Tables in APS Mode . . . . . . . . . . . . . 19 11. State Transition Tables in APS Mode . . . . . . . . . . . . . 19
11.1. State transition by local inputs . . . . . . . . . . . . 22 11.1. State transition by local inputs . . . . . . . . . . . . 21
11.2. State transition by remote messages . . . . . . . . . . 24 11.2. State transition by remote messages . . . . . . . . . . 23
11.3. State transition for 1+1 unidirectional 11.3. State transition for 1+1 unidirectional
protection . . . . . . . . . . . . . . . . . . . . . . . 26 protection . . . . . . . . . . . . . . . . . . . . . . . 25
12. Provisioning Mismatch and Protocol Failure in the APS Mode . 27 12. Provisioning Mismatch and Protocol Failure in APS Mode . . . 26
13. Security Considerations . . . . . . . . . . . . . . . . . . . 28 13. Security Considerations . . . . . . . . . . . . . . . . . . . 27
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
14.1. MPLS PSC Request Registry . . . . . . . . . . . . . . . 28 14.1. MPLS PSC Request Registry . . . . . . . . . . . . . . . 27
14.2. MPLS PSC TLV Registry . . . . . . . . . . . . . . . . . 28 14.2. MPLS PSC TLV Registry . . . . . . . . . . . . . . . . . 27
14.3. MPLS PSC Capability Flag Registry . . . . . . . . . . . 28 14.3. MPLS PSC Capability Flag Registry . . . . . . . . . . . 27
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
16.1. Normative References . . . . . . . . . . . . . . . . . . 29 16.1. Normative References . . . . . . . . . . . . . . . . . . 28
16.2. Informative References . . . . . . . . . . . . . . . . . 29 16.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. An Example of Out-of-service Ccenarios . . . . . . . 30 Appendix A. An Example of Out-of-service Scenarios . . . . . . . 29
Appendix B. An Example of Sequence Diagram Showing Appendix B. An Example of Sequence Diagram Showing
the Problem with the Priority Level of SFc . . . . . 31 the Problem with the Priority Level of SFc . . . . . 30
Appendix C. Freeze Command . . . . . . . . . . . . . . . . . . . 33 Appendix C. Freeze Command . . . . . . . . . . . . . . . . . . . 32
Appendix D. Operation Examples of the APS Mode . . . . . . . . . 33 Appendix D. Operation Examples of the APS Mode . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
Linear protection mechanisms for the MPLS Transport Profile (MPLS-TP) Linear protection mechanisms for the MPLS Transport Profile (MPLS-TP)
are described in RFC 6378 [RFC6378] to meet the requirements are described in RFC 6378 [RFC6378] to meet the requirements
described in RFC 5654 [RFC5654]. described in RFC 5654 [RFC5654].
This document describes alternate mechanisms to perform some of the This document describes alternate mechanisms to perform some of the
sub-functions of linear protection, and also defines additional functions of linear protection, and also defines additional
mechanisms. The purpose of these alternate and additional mechanisms mechanisms. The purpose of these alternate and additional mechanisms
is to provide operator control and experience that more closely is to provide operator control and experience that more closely
models the behavior of linear protection seen in other transport models the behavior of linear protection seen in other transport
networks, such as Synchronous Digital Hierarchy (SDH), Optical networks, such as Synchronous Digital Hierarchy (SDH), Optical
Transport Network (OTN) and Ethernet transport networks. Linear Transport Network (OTN) and Ethernet transport networks. Linear
protection for SDH, OTN, and Ethernet transport networks are defined protection for SDH, OTN, and Ethernet transport networks are defined
in ITU-T Recommendations G.841 [G841], G.873.1 [G873.1] and G.8031 in ITU-T Recommendations G.841 [G841], G.873.1 [G873.1] and G.8031
[G8031], respectively. [G8031], respectively.
The reader of this document is assumed to be familiar with RFC 6378. The reader of this document is assumed to be familiar with [RFC6378].
The alternative mechanisms described in this document are for the The alternative mechanisms described in this document are for the
following capabilities: following capabilities:
1. Priority modification, 1. Priority modification,
2. non-revertive behavior modification, 2. non-revertive behavior modification,
and the following capabilities have been added to define additional and the following capabilities have been added to define additional
mechanisms: mechanisms:
3. support of Manual Switch to Working path (MS-W) command, 3. support of Manual Switch to Working path (MS-W) command,
4. support of protection against Signal Degrade (SD), and 4. support of protection against Signal Degrade (SD), and
5. support of Exercise (EXER) command. 5. support of Exercise (EXER) command.
Priority modification includes priority swapping between Signal Fail The priority modification includes raising the priority of Signal
on Protection path (SF-P) and Forced Switch (FS), and raising the Fail on Protection path (SF-P) relative to Forced Switch (FS), and
priority level of Clear Signal Fail (SFc). raising the priority level of Clear Signal Fail (SFc) above SF-P.
Non-revertive behavior is modified to align with the behavior defined Non-revertive behavior is modified to align with the behavior defined
in RFC 4427 [RFC4427] as well as to follow the behavior of linear in RFC 4427 [RFC4427] as well as to follow the behavior of linear
protection seen in other transport networks. protection seen in other transport networks.
Support of MS-W command to revert traffic to the working path in non- Support of MS-W command to revert traffic to the working path in non-
revertive operation is covered in this document. revertive operation is covered in this document.
Support of protection switching protocol against SD is covered in Support of protection switching protocol against SD is covered in
this document. The specifics for the method of identifying SD is out this document. The specifics for the method of identifying SD is out
of the scope of this document similarly to Signal Fail (SF) for RFC of the scope for this document and is treated similarly to Signal
6378. Fail (SF) in [RFC6378].
Support of EXER command to test if the Protection State Coordination Support of EXER command to test if the Protection State Coordination
(PSC) communication is operating correctly is also covered in this (PSC) communication is operating correctly is also covered in this
document. More specifically, EXER command tests and validates the document. EXER command tests and validates the linear protection
linear protection mechanism and PSC protocol including the aliveness mechanism and PSC protocol including the aliveness of the priority
of the priority logic, the PSC state machine and the PSC message logic, the PSC state machine and the PSC message generation and
generation and reception, and the integrity of the protection path, reception, and the integrity of the protection path, without
without triggering the actual traffic switching. triggering the actual traffic switching.
This document introduces capabilities and modes. A capability is an This document introduces capabilities and modes. A capability is an
individual behavior. The capabilities of a node are advertised using individual behavior. The capabilities of a node are advertised using
the method given in this document. A mode is a particular the method given in this document. A mode is a particular
combination of capabilities. Two modes are defined in this document: combination of capabilities. Two modes are defined in this document:
PSC mode and Automatic Protection Switching (APS) mode. PSC mode and Automatic Protection Switching (APS) mode.
This document describes the behavior of the PSC protocol including This document describes the behavior, the priority logic, and the
the priority logic and the state machine when all the capabilities state machine of the PSC protocol when all the capabilities
associated with the APS mode are enabled. The PSC protocol behavior associated with the APS mode are enabled. The PSC protocol behavior
for the PSC mode is as defined in RFC 6378. for the PSC mode is as defined in [RFC6378].
This document updates RFC 6378 by adding a capability advertisement This document updates [RFC6378] by adding a capability advertisement
mechanism. It is recommended that existing implementations of RFC mechanism. It is recommended that existing implementations of the
6378 should be updated to support this capability. The backward PSC protocol be updated to support this capability. Backward
compatibility with existing implementations is described in compatibility with existing implementations is described in
Section 9.2.1. Section 9.2.1.
2. Conventions Used in This Document 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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Acronyms 3. Acronyms
skipping to change at page 6, line 4 skipping to change at page 5, line 25
compatibility with existing implementations is described in compatibility with existing implementations is described in
Section 9.2.1. Section 9.2.1.
2. Conventions Used in This Document 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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Acronyms 3. Acronyms
This document uses the following acronyms: This document uses the following acronyms:
APS Automatic Protection Switching APS Automatic Protection Switching
DNR Do-not-Revert DNR Do-not-Revert
EXER Exercise EXER Exercise
FS Forced Switch FS Forced Switch
LER Label Edge Router
LO Lockout of protection LO Lockout of protection
MS Manual Switch MS Manual Switch
MS-P Manual Switch to Protection path MS-P Manual Switch to Protection path
MS-W Manual Switch to Working path MS-W Manual Switch to Working path
MPLS-TP MPLS Transport Profile MPLS-TP MPLS Transport Profile
NR No Request NR No Request
OC Operator Clear OC Operator Clear
OTN Optical Transport Network OTN Optical Transport Network
PSC Protection State Coordination PSC Protection State Coordination
RR Reverse Request RR Reverse Request
skipping to change at page 6, line 34 skipping to change at page 6, line 7
SD-W Signal Degrade on Working path SD-W Signal Degrade on Working path
SF Signal Fail SF Signal Fail
SFc Clear Signal Fail SFc Clear Signal Fail
SFDc Clear Signal Fail or Degrade SFDc Clear Signal Fail or Degrade
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
WTR Wait-to-Restore WTR Wait-to-Restore
4. Capability 1: Priority Modification 4. Capability 1: Priority Modification
RFC 6378 [RFC6378] defines the priority of FS to be higher than that [RFC6378] defines the priority of FS to be higher than that of SF-P.
of SF-P. That document also defines the priority of Clear SF (SFc) That document also defines the priority of Clear SF (SFc) to be low.
to be low. This document defines the priority modification This document defines the priority modification capability whereby
capability whereby the priorities of FS and SF-P are swapped and the the relative priorities of FS and SF-P are swapped and the priority
priority of Clear SF (SFc) is raised. In addition, this capability of Clear SF (SFc) is raised. In addition, this capability introduces
introduces the use of Freeze command as described in Appendix C. The the Freeze command as described in Appendix C. The rationale for
reasons for these changes are explained in the following sub-sections these changes is detailed in the following sub-sections from both the
from technical and network operational aspects. technical and network operational aspects.
4.1. Motivations for swapping priorities of FS and SF-P 4.1. Motivation for swapping priorities of FS and SF-P
Defining the priority of FS higher than that of SF-P can result in a Defining the priority of FS higher than that of SF-P can result in a
situation where the protected traffic is taken out-of-service. When situation where the protected traffic is taken out-of-service. When
the protection path fails PSC communication may stop as a result. In the protection path fails PSC communication may stop as a result. In
this case, if any input that is supposed to be signaled to the other this case, if any input that is supposed to be signaled to the other
end has a higher priority than SF-P then this can result in end has a higher priority than SF-P then this can result in
unpredictable protection switching state. An example of the out-of- unpredictable protection switching state. An example scenario that
service scenarios is shown in Appendix A. may result in an out-of-service situation is presented in Appendix A
of this document.
According to Section 2.4 of RFC 5654 [RFC5654] it MUST be possible to According to Section 2.4 of [RFC5654] it MUST be possible to operate
operate an MPLS-TP network without using a control plane. This means an MPLS-TP network without using a control plane. This means that
that the PSC communication channel is very important for the transfer the PSC communication channel is very important for the transfer of
of external switch commands (e.g., FS), and these commands should not external switching commands (e.g., FS), and these commands should not
rely on the presence of a control plane. In consequence, the failure rely on the presence of a control plane. In consequence, the failure
of the PSC communication channel has higher priority than FS. of the PSC communication channel has higher priority than FS.
In other transport networks (such as SDH, OTN, and Ethernet transport In other transport networks (such as SDH, OTN, and Ethernet transport
networks) the priority of SF-P has been higher than that of FS. It networks) the priority of SF-P has been higher than that of FS. It
is therefore important to offer network operators the option of is therefore important to offer network operators the option of
having the same behavior in their MPLS-TP network so that they can having the same behavior in their MPLS-TP networks so that they can
have the same operational protection switching behavior to which they have the same operational protection switching behavior to which they
have become accustomed. Typically, FS command is issued before have become accustomed. Typically, FS command is issued before
network maintenance jobs, (e.g., replacing optical cables or other network maintenance jobs, (e.g., replacing optical cables or other
network components). When an operator pulls out a cable on the network components). When an operator pulls out a cable on the
protection path by mistake, the traffic should be protected and the protection path, by mistake, the traffic should continue to be
operator expects this behavior based on his/her experience on the protected and the operator expects this behavior based on his/her
traditional transport network operations. experience on the traditional transport network operations.
4.2. Motivation for raising the priority of SFc 4.2. Motivation for raising the priority of SFc
The priority level of SFc defined in RFC 6378 can cause traffic The priority level of SFc defined in [RFC6378] can cause traffic
disruption when a node that has experienced local signal fails on disruption when a node that has experienced local signal fails on
both the working and the protection paths is recovering from these both the working and the protection paths is recovering from these
failures. failures.
An example of sequence diagram showing the problem with the priority An example of sequence diagram highlighting the problem with the
level of SFc as defined in RFC 6378 is shown in Appendix B. priority level of SFc as defined in [RFC6378] is presented in
Appendix B.
4.3. Motivation for introducing Freeze command 4.3. Motivation for introducing Freeze command
With the priority swapping between FS and SF-P, the traffic is always With the priority swapping between FS and SF-P, the traffic is always
moved back to the working path when SF-P occurs in Protecting moved back to the working path when SF-P occurs in Protecting
administrative state. In the case that network operators need an Administrative state. In case network operators need an option to
option to control their networks so that the traffic can remain on control their networks so that the traffic can remain on the
the protection path even when the PSC communication channel is protection path even when the PSC communication channel is broken,
broken, the Freeze command, which is a local command (i.e., not the Freeze command can be used. Freeze is defined to be a "local"
signaled to the other end) can be used. The use of the Freeze command that is not signaled to the remote node. The use of the
command is described in Appendix C. Freeze command is described in Appendix C.
4.4. Procedures in support of Capability 1 4.4. Procedures in support of Capability 1
When this capability is in use the list of local requests in order of When the modified priorities specified in this document is in use,
priority SHALL be as follows: the list of local requests in order of priority SHALL be as follows:
(from higher to lower) (from highest to lowest)
o Clear Signal Fail o Clear Signal Fail
o Signal Fail on Protection path o Signal Fail on Protection path
o Forced Switch o Forced Switch
o Signal Fail on Working path o Signal Fail on Working path
This requires different PSC Control logic (including the state This requires modification to the PSC Control Logic (including the
machine) compared to that described in RFC 6378. Section 10 and state machine) relative to that described in [RFC6378]. Sections 10
Section 11 show the PSC Control logic when all of the capabilities in and 11 present the PSC Control Logic when all capabilities of APS
APS mode are enabled. mode are enabled.
5. Capability 2: Non-revertive Behavior Modification 5. Capability 2: Non-revertive Behavior Modification
Non-revertive mode of protection switching is defined in RFC 4427 Non-revertive operation of protection switching is defined in
[RFC4427]. In this mode, the traffic does not return to the working [RFC4427]. In this operation, the traffic does not return to the
path when switch-over requests are terminated. working path when switch-over requests are terminated.
However, the PSC protocol defined in RFC 6378 [RFC6378] supports this However, the PSC protocol defined in [RFC6378] supports this
operation only when recovering from a defect condition: it does not operation only when recovering from a defect condition: it does not
support the non-revertive function when an operator's switch-over support the non-revertive function when an operator's switch-over
command, such as FS or Manual Switch (MS), is cleared. To be aligned command, such as FS or Manual Switch (MS), is cleared. To be aligned
with the behavior in other transport networks and to be consistent with the behavior in other transport networks and to be consistent
with RFC 4427, a node should go into the Do-not-Revert (DNR) state with [RFC4427], a node should go into the Do-not-Revert (DNR) state
not only when a failure condition on the working path is cleared, but not only when a failure condition on the working path is cleared, but
also when an operator command that requested switch-over is cleared. also when an operator command that requested switch-over is cleared.
This requires different PSC Control logic (including the state This requires modification to the PSC Control Logic (including the
machine) compared to that described in RFC 6378. Section 10 and state machine) relative to that described in [RFC6378]. Sections 10
Section 11 show the PSC Control logic when all of the capabilities in and 11 present the PSC Control Logic when all capabilities of APS
APS mode are enabled. mode are enabled.
6. Capability 3: Support of MS-W Command 6. Capability 3: Support of MS-W Command
6.1. Motivation for adding MS-W 6.1. Motivation for adding MS-W
Changing the non-revertive operation as described in Section 5 Changing the non-revertive operation as described in Section 5
introduces necessity of a new operator command to revert traffic to introduces necessity of a new operator command to revert traffic to
the working path when in the DNR state. When the traffic is on the the working path when in the DNR state. When the traffic is on the
protection path in the DNR state, a Manual Switch to Working (MS-W) protection path in the DNR state, a Manual Switch to Working (MS-W)
command is issued to switch the normal traffic back to working path. command is issued to switch the normal traffic back to the working
According to Section 4.3.3.6 (Do-not-Revert State) in RFC 6378 path. According to Section 4.3.3.6 (Do-not-Revert State) in
[RFC6378], "to revert back to Normal state, the administrator SHALL [RFC6378], "to revert back to the Normal state, the administrator
issue a Lockout of protection (LO) command followed by a Clear SHALL issue a Lockout of protection (LO) command followed by a Clear
command." However, using LO command introduces the potential risk of command." However, using LO command introduces the potential risk of
an unprotected situation while the LO is in effect. an unprotected situation while the LO is in effect.
Manual Switch-over for recovery LSP/span command is defined in RFC Manual Switch-over for recovery LSP/span command is defined in
4427 [RFC4427]. Requirement 83 in RFC 5654 [RFC5654] states that the [RFC4427]. Requirement 83 in [RFC5654] states that the external
external commands defined in RFC 4427 must be supported. No such commands defined in [RFC4427] MUST be supported. Since there is no
command is supported in PSC as defined in RFC 6378 so there is a need support for this external command in [RFC6378], this functionality
to provide support for that feature. Note that the "Manual Switch- should be added to PSC. This support is provided by introducing the
over for recovery LSP/span" command is the same as the MS-W command. MS-W command. The MS-W command, as described here, corresponds to
the "Manual Switch- over for recovery LSP/span" command.
6.2. Terminology to support MS-W 6.2. Terminology to support MS-W
RFC 6378 uses the term "Manual Switch" and its acronym "MS". This [RFC6378] uses the term "Manual Switch" and its acronym "MS". This
document uses the term "Manual Switch to Protection path" and "MS-P" document uses the term "Manual Switch to Protection path" and "MS-P"
to have the same meaning, but avoid confusion with "Manual Switch to to have the same meaning, while avoiding confusion with "Manual
Working path" and its acronym "MS-W". Switch to Working path" and its acronym "MS-W".
Similarly, RFC 6378 uses the term "Protecting administrative state", Similarly, we modify the name of "Protecting Administrative" state
and this document uses "Switching administrative state" to cover the (as defined in [RFC6378]) to be "Switching Administrative" state to
same concept but also include the case where traffic is switched back include the case where traffic is switched to the working path as a
to the working path by administrative MS-W command. result of the external MS-W command.
6.3. Behavior of MS-P and MS-W 6.3. Behavior of MS-P and MS-W
If one of the MS-P and MS-W commands is received and processed after MS-P and MS-W SHALL have the same priority. We consider different
the other, the two commands SHALL have the same priority such that if instances of determining the priority of the commands when they are
one of the commands is already issued and accepted, the command that received either in succession or simultaneously.
is issued afterwards SHALL be ignored. However, if two Label Edge
Routers (LERs) request opposite operations simultaneously (i.e., one
LER sends MS-P and the other sends MS-W), the MS-W SHALL be
considered to have a higher priority than MS-P, and MS-P SHALL NOT be
accepted and SHALL be cancelled.
Two commands, MS-P and MS-W are represented by the same Request field o When two commands are received in succession, the command that is
value, but differentiated by the FPath value. When traffic is received after the initial command is accepted SHALL be cancelled.
switched to the protection path, the FPath field SHALL 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 being transported
on the protection path (i.e., Path set to 1). When traffic is
switched to the working path, the FPath field SHALL indicate that the
protection path is being blocked (i.e., FPath set to 0), and the Path
field SHALL indicate that user data traffic is being transported on
the working path (i.e., Path set to 0).
When an MS command is in effect at an LER, any subsequent MS or EXER o If two nodes simultaneously receive commands that indicate
opposite operations (i.e., one node receives MS-P and the other
node receives MS-W) and transmit the indications to the remote
node, the MS-W SHALL be considered to have a higher priority, and
the MS-P SHALL be cancelled and discarded.
Two commands, MS-P and MS-W are transmitted using the same Request
field value, but SHALL indicate in the Fault Path (FPath) value the
path that the traffic is being diverted from. When traffic is
switched to the protection path, the FPath field value SHALL be set
to 1, indicating that traffic is being diverted from the working
path. When traffic is switched to the working path, the FPath field
value SHALL be set to 0, indicating that traffic is being diverted
from the protection path. The Data Path (Path) field SHALL indicate
where user data traffic is being transported (i.e., if the working
path is selected, then Path is set to 0; if the protection path is
selected, then Path is set to 1).
When an MS command is in effect at a node, any subsequent MS or EXER
command and any other lower priority requests SHALL be ignored. command and any other lower priority requests SHALL be ignored.
6.4. Equal priority resolution for MS 6.4. Equal priority resolution for MS
RFC 6378 defines only one rule for equal priority condition in [RFC6378] defines only one rule for equal priority condition in
Section 4.3.2 as "The remote message from the remote LER is assigned Section 4.3.2 as "The remote message from the remote LER is assigned
a priority just below the similar local input." In order to support a priority just below the similar local input." In order to support
the manual switch behavior described in Section 6.3, additional rules the manual switch behavior described in Section 6.3, additional rules
for equal priority resolution are required. Since the support of for equal priority resolution are required. Since the support of
protection against signal degrade also requires a similar equal protection against signal degrade also requires a similar equal
priority resolution, the rules are described in Section 7.4. priority resolution, the rules are described in Section 7.4.
Support of this function requires changes to the PSC Control logic Support of this function requires changes to the PSC Control Logic
(including the state machine) compared to that shown in RFC 6378. (including the state machine) relative to that shown in [RFC6378].
Section 10 and Section 11 show the PSC Control logic when all of the Sections 10 and 11 present the PSC Control Logic when all
capabilities in APS mode are enabled. capabilities of APS mode are enabled.
7. Capability 4: Support of Protection against SD 7. Capability 4: Support of Protection against SD
7.1. Motivation for supporting protection against SD 7.1. Motivation for supporting protection against SD
In MPLS-TP survivability framework [RFC6372], fault conditions In the MPLS-TP Survivability Framework [RFC6372], both SF and SD
include both SF and SD that can be used to trigger protection fault conditions can be used to trigger protection switching.
switching.
RFC 6378 [RFC6378], which defines the protection switching protocol [RFC6378], which defines the protection switching protocol for MPLS-
for MPLS-TP does not specify how the SF and SD are detected, and TP, does not specify how the SF and SD are detected, and specifies
specifies the protection switching protocol associated with SF only. the protection switching protocol associated with SF only.
The PSC protocol associated with SD is covered in this document, but The PSC protocol associated with SD is covered in this document, but
the specifics for the method of identifying SD is out of the scope of the specifics for the method of identifying SD is out of scope for
the protection protocol similar to the facts that how SF is detect the protection protocol in the same way that SF detection and MS or
and how MS and FS commands are initiated in a management system and FS command initiation are out of scope.
signaled to protection switching are out of its scope.
7.2. Terminology to support SD 7.2. Terminology to support SD
In this document the term Clear Signal Fail or Degrade (SFDc) is used In this document the term Clear Signal Fail or Degrade (SFDc) is used
to indicate the clearance of either a degraded condition or a failure to indicate the clearance of either a degraded condition or a failure
condition. condition.
The second paragraph of Section 4.3.3.2 Unavailable state in RFC 6378 The second paragraph of Section 4.3.3.2 Unavailable state in
shows the intention of including Signal Degrade on Protection path [RFC6378] shows the intention of including Signal Degrade on
(SD-P) in the Unavailable state. Even though the protection path can Protection path (SD-P) in the Unavailable state. Even though the
be partially available under the condition of SD-P, this document protection path can be partially available under the condition of
follows the same state grouping as RFC 6378 for SD-P. SD-P, this document follows the same state grouping as [RFC6378] for
SD-P.
The bullet item "Protecting failure state" in Section 3.6 in RFC 6378 The bullet item on the Protecting Failure state in Section 3.6 of
includes the degraded condition in Protecting failure state. This [RFC6378] includes the degraded condition in the Protecting Failure
document follows the same state grouping as RFC 6378 for Signal state. This document follows the same state grouping as [RFC6378]
Degrade on Working path (SD-W). for Signal Degrade on Working path (SD-W).
7.3. Behavior of protection against SD 7.3. Behavior of protection against SD
In order to make the behavior of MPLS-TP networks consistent with To better align the behavior of MPLS-TP networks with that of other
that of other transport networks (such as SDH, OTN and Ethernet transport networks (such as SDH, OTN, and Ethernet transport
transport networks), the priorities of SD-P and SD-W are defined to networks) we define the followings:
be equal. Once a switch has been completed due to SD on one path, it
will not be overridden by SD on the other path (first come, first
served behavior), to avoid protection switching that cannot improve
signal quality.
SD indicates that the transmitting end point has identified a o The priorities of SD-P and SD-W SHALL be equal.
o Once a switch has been completed due to SD on one path, it will
not be overridden by SD on the other path (first come, first
served behavior), to avoid protection switching that cannot
improve signal quality.
The SD message indicates that the transmitting node has identified a
degradation of the signal, or integrity of the packet transmission on degradation of the signal, or integrity of the packet transmission on
either the working path or the protection path. The FPath field either the working path or the protection path. The FPath field
SHALL identify the path that is reporting the degrade condition SHALL identify the path that is reporting the degraded condition
(i.e., if the protection path, then FPath is set to 0; if the working (i.e., if the protection path, then FPath is set to 0; if the working
path, then FPath is set to 1), and the Path field SHALL indicate path, then FPath is set to 1), and the Path field SHALL indicate
where the data traffic is being transported (i.e., if the working where the data traffic is being transported (i.e., if the working
path is selected, then Path is set to 0; if the protection path is path is selected, then Path is set to 0; if the protection path is
selected, then Path is set to 1). selected, then Path is set to 1).
The Wait-to-Restore (WTR) timer is used when the protected domain is When the SD condition is cleared and the protected domain is
configured for revertive behavior and started at the node that recovering from the situation, the Wait-to-Restore (WTR) timer SHALL
recovers from a local degraded condition on the working path. be used if the protected domain is configured for revertive behavior.
The WTR timer SHALL be started at the node that recovers from a local
degraded condition on the working path.
Protection switching against SD is always provided by a selector Protection switching against SD is always provided by a selector
bridge duplicating user data traffic and feeding it to both the bridge duplicating user data traffic and feeding it to both the
working path and the protection path under SD condition. When a working path and the protection path under SD condition. When a
local or remote SD occurs on either the working path or the local or remote SD occurs on either the working path or the
protection path, the LER SHALL duplicate user data traffic and SHALL protection path, the node SHALL duplicate user data traffic and SHALL
feed to both the working path and the protection path. The packet feed to both the working path and the protection path. The packet
duplication SHALL continue as long as any SD condition exists in the duplication SHALL continue as long as any SD condition exists in the
protected domain, and SHALL stop when there is no SD condition. protected domain. The packet duplication SHALL continue in the WTR
Additionally, the packet duplication SHALL continue in the WTR state state in revertive operation and SHALL stop when the node leaves the
in revertive mode. In non-revertive mode, the packet duplication WTR state. In non-revertive operation, the packet duplication SHALL
SHALL stop when there is no SD condition. stop when the SD condition is cleared.
The selector bridge with the packet duplication under SD condition, The selector bridge with the packet duplication under SD condition,
which is a non-permanent bridge, is considered to be a 1:1 protection which is a non-permanent bridge, is considered to be a 1:1 protection
architecture. architecture.
Protection switching against SD does not introduce any modification Protection switching against SD does not introduce any modification
to the operation of the selector at the sink LER described in RFC to the operation of the selector at the sink node described in
6378. The selector chooses either the working or protection path [RFC6378]. The selector chooses either the working or protection
from which to receive the normal traffic in both 1:1 and 1+1 path from which to receive the normal traffic in both 1:1 and 1+1
architectures. The position of the selector, i.e., which path to architectures. The position of the selector, i.e., which path to
receive the traffic, is determined by the PSC protocol in receive the traffic, is determined by the PSC protocol in
bidirectional switching or by the local input in unidirectional bidirectional switching or by the local input in unidirectional
switching. switching.
7.4. Equal priority resolution 7.4. Equal priority resolution
In order to support the manual switch behavior described in In order to support the MS behavior described in Section 6.3 and the
Section 6.3 and the protection against Signal Degrade described in protection against SD described in Section 7.3, it is necessary to
Section 7.3, the rules to resolve the equal priority requests are expand the rules for treating equal priority inputs.
required.
For the equal priority local inputs, such as MS and SD, first-come, For equal priority local inputs, such as MS and SD, apply a simple
first-served rule is applied. Once a local input is determined as first-come, first-served rule. Once a local input is determined as
the highest priority local input, then a subsequent equal priority the highest priority local input, then a subsequent equal priority
local input requesting a different action, i.e., the action results local input requesting a different action, i.e., the action results
in the same PSC Request field but different FPath value, will not be in the same PSC Request field but different FPath value, will not be
presented to the PSC Control logic as the highest local request. presented to the PSC Control Logic as the highest local request.
Furthermore, in the case of MS command, the subsequent local MS Furthermore, in the case of MS command, the subsequent local MS
command requesting a different action will be cancelled. command requesting a different action will be cancelled.
If the LER is in a remote state due to a remote SD (or MS) message, a If a node is in a remote state due to a remote SD (or MS) message, a
subsequent local input having the same priority but requesting subsequent local input having the same priority but requesting a
different action to the PSC Control logic, will be considered as different action to the PSC Control Logic, will be considered as
having lower priority than the remote message, and will be ignored. having lower priority than the remote message, and will be ignored.
If the LER is in remote Switching administrative state due to a For examples, if a node is in remote Switching Administrative state
remote MS-P, then subsequent local MS-W SHALL be ignored and due to a remote MS-P, then any subsequent local MS-W SHALL be ignored
automatically cancelled. If the LER is in remote Unavailable state and automatically cancelled. If a node is in remote Unavailable
due to a remote SD-P, then subsequent local SD-W input will be state due to a remote SD-P, then any subsequent local SD-W input will
ignored. However, the local SD-W SHALL appear in the Local Request be ignored. However, the local SD-W SHALL continue to appear in the
logic as long as the SD condition exists, but SHALL NOT be the top Local Request Logic as long as the SD condition exists, but SHALL NOT
priority global request, which determines the state transition at the be the top priority global request, which determines the state
PSC Control logic. transition at the PSC Control Logic.
There is a case where one LER receives a local input and the other Cases where two end-points of the protected domain simultaneously
LER receives, simultaneously, a local input with the same priority receive local triggers of the same priority that request different
but requesting different action. In this case, each of the two LERs actions (for example, one node receives SD-P and the other receives
receives a subsequent remote message having the same priority but SD-W) may occur. Subsequently, each node will receive a remote
requesting different action, while the LER is in a local state due to message with the opposing action indication. To address these cases,
the local input. When this case happens, a priority must be set for we define the following priority resolution rules:
the inputs with the same priority regardless of its origin (local
input or remote message).
o When MS-W and MS-P occur simultaneously at both LERs, MS-W SHALL o When MS-W and MS-P occur simultaneously at both nodes, MS-W SHALL
be considered as having higher priority than MS-P at both LERs. be considered as having higher priority than MS-P at both nodes.
o When SD-W and SD-P occur simultaneously at both LERs, the SD on o When SD-W and SD-P occur simultaneously at both nodes, the SD on
the standby path (the path from which the selector does not select the standby path (the path from which the selector does not select
the user data traffic) is considered as having higher priority the user data traffic) is considered as having higher priority
than the SD on the active path (the path from which the selector than the SD on the active path (the path from which the selector
selects the user data traffic) regardless of its origin (local or selects the user data traffic) regardless of its origin (local or
remote message). Therefore, no unnecessary protection switching remote message). Therefore, no unnecessary protection switching
is performed and the user data traffic continues to be selected is performed and the user data traffic continues to be selected
from the active path. from the active path.
In the preceding paragraphs, the "simultaneously" refers to the case In the preceding paragraphs, the "simultaneously" refers to the case
a sent SD (or MS) request has not been confirmed by the remote end in a sent SD (or MS) request has not been confirmed by the remote end in
bidirectional protection switching. When a local node that has bidirectional protection switching. When a local node that has
transmitted a SD message receives a SD (or MS) message that indicates transmitted a SD message receives a SD (or MS) message that indicates
a different value of data path (Path) field than the value of the a different value of Path field from the value of Path field in the
Path field in the transmitted SD (or MS) message, both the local and transmitted SD (or MS) message, both the local and remote SD requests
the remote SD requests are considered to occur simultaneously. are considered to occur simultaneously.
The addition of support for protection against SD requires different The addition of support for protection against SD requires
PSC Control logic (including the state machine) compared to that modification to the PSC Control Logic (including the state machine)
shown in RFC 6378. Section 10 and Section 11 show the PSC Control relative to that described in [RFC6378]. Sections 10 and 11 present
logic when all of the capabilities in APS mode are enabled. the PSC Control Logic when all capabilities of APS mode are enabled.
8. Capability 5: Support of EXER Command 8. Capability 5: Support of EXER Command
EXER is a command to test if the PSC communication is operating The EXER command is used to verify the correct operation of the PSC
correctly. More specifically, EXER is to test and validate the communication, such as the aliveness of the Local Request Logic, the
linear protection mechanism and PSC protocol including the aliveness integrity of the PSC Control Logic, the PSC message generation and
of the Local Request logic, the PSC state machine and the PSC message reception mechanism, and the integrity of the protection path. EXER
generation and reception, and the integrity of the protection path, does not trigger any actual traffic switching.
without triggering the actual traffic switching. It is used while
the working path is either carrying the traffic or not. It has lower
priority than any "real" switch request. It is only valid in
bidirectional switching, since this is the only place where one can
get a meaningful test by looking for a response.
This command is documented in R84 of RFC 5654 [RFC5654]. The command is only relevant for bidirectional protection switching,
since it is dependent upon receiving a response from the remote node.
The EXER command is assigned lower priority than any switching
message. It may be used regardless of the traffic usage of the
working path.
A received EXER message indicates that the remote end point is When a node receives a remote EXER message, it SHOULD respond with a
operating under an operator command to validate the protection Reverse Request (RR) message with the FPath and Path fields set
mechanism and PSC protocol including the aliveness of the Local according to the current condition of the node. The RR message SHALL
Request logic, the PSC state machine and the PSC message generation be generated only in response to a remote EXER message.
and reception, and the integrity of the protection path, without
triggering the actual traffic switching. The valid response to EXER This command is documented in R84 of [RFC5654].
message is an Reverse Request (RR) with the corresponding FPath and
Path numbers. The local LER SHALL signal a RR only in response to an
EXER command from the remote LER.
If EXER commands are input at both ends, then a race condition may If EXER commands are input at both ends, then a race condition may
arise. This is resolved as follows: arise. This is resolved as follows:
o If an LER has issued EXER and receives EXER before receiving RR, o If a node has issued EXER and receives EXER before receiving RR,
it it MUST treat the received EXER as it would an RR, and SHOULD NOT
respond with RR.
o MUST treat the received EXER as it would an RR, and
o SHOULD NOT respond with RR.
The following PSC Requests are added to the PSC Request field to The following PSC Requests are added to the PSC Request field to
support the Exercise command (see also Section 14.1): support the Exercise command (see also Section 14.1):
(3) Exercise - indicates that the transmitting end point is (3) Exercise - indicates that the transmitting end point is
exercising the protection channel and mechanism. FPath and Path exercising the protection channel and mechanism. FPath and Path
are set to the same value of the No Request (NR), RR or DNR are set to the same value of the No Request (NR), RR or DNR
request that EXER replaces. request that EXER replaces.
(2) Reverse Request - indicates that the transmitting end point is (2) Reverse Request - indicates that the transmitting end point is
responding to an EXER command from the remote LER. FPath and Path responding to an EXER command from the remote node. FPath and
are set to the same value of the NR or DNR request that RR Path are set to the same value of the NR or DNR request that RR
replaces. replaces.
The relative priorities of EXER and RR are shown in Section 10.2. The relative priorities of EXER and RR are defined in Section 10.2.
9. Capabilities and Modes 9. Capabilities and Modes
9.1. Capabilities 9.1. Capabilities
A Capability is an individual behavior whose use is signaled in a A Capability is an individual behavior whose use is signaled in a
Capabilities TLV, which is placed in Optional TLVs field inside the Capabilities TLV, which is placed in Optional TLVs field inside the
PSC message shown in Figure 2 of RFC 6378 [RFC6378]. The format of PSC message shown in Figure 2 of [RFC6378]. The format of the
the Capabilities TLV is: Capabilities TLV is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Capabilities | Length | | Type = Capabilities | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value = Flags | | Value = Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of Capabilities TLV Figure 1: Format of Capabilities TLV
skipping to change at page 15, line 16 skipping to change at page 14, line 44
If the bit assigned for an individual capability is set to 1, it If the bit assigned for an individual capability is set to 1, it
indicates the sending node's intent to use that capability in the indicates the sending node's intent to use that capability in the
protected domain. If a bit is set to 0, the sending node does not protected domain. If a bit is set to 0, the sending node does not
intend to use the indicated capability in the protected domain. Note intend to use the indicated capability in the protected domain. Note
that it is not possible to distinguish between the intent not to use that it is not possible to distinguish between the intent not to use
a capability and a node's complete non-support (i.e., lack of a capability and a node's complete non-support (i.e., lack of
implementation) of a given capability. implementation) of a given capability.
This document defines five specific capabilities that are described This document defines five specific capabilities that are described
from Section 4 to Section 8. Each capability is assigned bit as in Section 4 to Section 8. Each capability is assigned bit as
follows: follows:
0x80000000: priority modification 0x80000000: priority modification
0x40000000: non-revertive behavior modification 0x40000000: non-revertive behavior modification
0x20000000: support of MS-W command 0x20000000: support of MS-W command
0x10000000: support of protection against SD 0x10000000: support of protection against SD
0x08000000: support of EXER command 0x08000000: support of EXER command
If all the five capabilities should be used, an LER SHALL set If all the five capabilities should be used, a node SHALL set the
0xF8000000 in the Flags field. Flags field to 0xF8000000.
9.1.1. Sending and receiving the Capabilities TLV 9.1.1. Sending and receiving the Capabilities TLV
A node MUST include its Capabilities TLV in every PSC message that it A node MUST include its Capabilities TLV in every PSC message that it
sends. The transmission and acceptance of the PSC message is transmits. The transmission and acceptance of the PSC message is
described in Section 4.1 of RFC 6378. described in Section 4.1 of [RFC6378].
When a node receives a Capabilities TLV it MUST compare it to its When a node receives a Capabilities TLV it MUST compare the Flags
most recent transmitted Capabilities TLV. If the two are equal, the value to its most recent Flags value transmitted by the node. If the
protected domain is said to be running in the mode indicated by that two are equal, the protected domain is said to be running in the mode
set of capabilities (see Section 9.2). If the sent and received indicated by that set of capabilities (see Section 9.2). If the sent
Capabilities TLVs are not equal, this indicates a capabilities and received Capabilities TLVs are not equal, this indicates a
mismatch. When this happens, the node MUST alert the operator and capabilities TLV mismatch. When this happens, the node MUST alert
MUST NOT perform any protection switching until the operator resolves the operator and MUST NOT perform any protection switching until the
the mismatch in the Capabilities TLV. operator resolves the mismatch between the two end-points.
9.2. Modes 9.2. Modes
A mode is a given set of Capabilities. Modes are shorthand; A mode is a given set of Capabilities. Modes are shorthand;
referring to a set of capabilities by their individual values or by referring to a set of capabilities by their individual values or by
the name of their mode does not change the protocol behavior. This the name of their mode does not change the protocol behavior. This
document defines two modes - PSC and APS. document defines two modes - PSC and APS.
9.2.1. PSC mode 9.2.1. PSC mode
PSC mode is defined as the lack of any Capabilities - that is, a PSC mode is defined as the lack of support for any of the additional
Capabilities set of 0x0. It is the behavior specified in RFC 6378. capabilities defined in this document - that is, a Capabilities set
of 0x0. It is the behavior specified in [RFC6378].
There are two ways to declare PSC mode. A node can send no There are two ways to declare PSC mode. A node can send no
Capabilities TLV at all since there are no TLV units defined in RFC Capabilities TLV at all since there are no TLV units defined in
6378, or it can send a Capabilities TLV with Flags value set to 0x0. [RFC6378], or it can send a Capabilities TLV with Flags value set to
In order to allow backward compatibility between two nodes - one 0x0. In order to allow backward compatibility between two end-points
which can send the Capabilities TLV, and one which cannot, a node - one which supports sending the Capabilities TLV, and one which does
which has the ability to send and receive the PSC mode Capabilities not, the node that has the ability to send and process the PSC mode
TLV MUST be able to both send the PSC mode Capabilities TLV and send Capabilities TLV MUST be able to both send the PSC mode Capabilities
no Capabilities TLV at all. An implementation MUST be configurable TLV and send no Capabilities TLV at all. An implementation MUST be
between these two choices. configurable between these two options.
9.2.2. APS mode 9.2.2. APS mode
APS mode is defined as the use of all the five specific capabilities, APS mode is defined as the use of all the five specific capabilities,
which are described from Section 4 to Section 8 in this document. which are described in Section 4 to Section 8 in this document. APS
APS mode is indicated with the Flags value of 0xF8000000. mode is indicated with the Flags value of 0xF8000000.
10. PSC Protocol in APS Mode 10. PSC Protocol in APS Mode
This section and Section 11 define the behavior of PSC protocol when This section and the following section define the behavior of PSC
all of the aforementioned capabilities are enabled, i.e., APS mode. protocol when all of the aforementioned capabilities are enabled,
i.e., APS mode.
10.1. Request field in PSC protocol message 10.1. Request field in PSC protocol message
This document defines two new values for the "Request" field in the This document defines two new values for the "Request" field in the
PSC protocol message that is shown in Figure 2 of RFC 6378 [RFC6378] PSC protocol message that is shown in Figure 2 of [RFC6378] as
as follows: follows:
(3) Exercise (3) Exercise
(2) Reverse Request (2) Reverse Request
See also Section 14.1 of this document. See also Section 14.1 of this document.
10.2. Priorities of local inputs and remote requests 10.2. Priorities of local inputs and remote requests
Based on the description in Section 3 and Section 4.3.2 in RFC 6378, Based on the description in Sections 3 and 4.3.2 in [RFC6378], the
the priorities of multiple outstanding local inputs are evaluated in priorities of multiple outstanding local inputs are evaluated in the
the Local Request logic, where the highest priority local input Local Request Logic, where the highest priority local input (highest
(highest local request) is determined. This highest local request is local request) is determined. This highest local request is passed
passed to the PSC Control logic, that will determine the higher to the PSC Control Logic, that will determine the higher priority
priority input (top priority global request) between the highest input (top priority global request) between the highest local request
local request and the last received remote message. When a remote and the last received remote message. When a remote message comes to
message comes to the PSC Control logic, the top priority global the PSC Control Logic, the top priority global request is determined
request is determined between this remote message and the highest between this remote message and the highest local request which is
local request which is present. The top priority global request is present. The top priority global request is used to determine the
used to determine the state transition, which is described in state transition, which is described in Section 11. In this
Section 11. In this document, in order to simplify the description document, in order to simplify the description on the PSC Control
on the PSC Control logic, we strictly decouple the priority Logic, we strictly decouple the priority evaluation from the state
evaluation from the state transition table lookup. transition table lookup.
The priorities for both local and remote requests are defined as The priorities for both local and remote requests are defined as
follows from highest to lowest: follows from highest to lowest:
o Operator Clear (Local only) o Operator Clear (Local only)
o Lockout of protection (Local and Remote) o Lockout of protection (Local and Remote)
o Clear Signal Fail or Degrade (Local only) o Clear Signal Fail or Degrade (Local only)
o Signal Fail on Protection path (Local and Remote) o Signal Fail on Protection path (Local and Remote)
o Forced Switch (Local and Remote) o Forced Switch (Local and Remote)
o Signal Fail on Working path (Local and Remote) o Signal Fail on Working path (Local and Remote)
o Signal Degrade on either Protection path or Working path (Local o Signal Degrade on either Protection path or Working path (Local
and Remote) and Remote)
skipping to change at page 17, line 35 skipping to change at page 17, line 18
o Forced Switch (Local and Remote) o Forced Switch (Local and Remote)
o Signal Fail on Working path (Local and Remote) o Signal Fail on Working path (Local and Remote)
o Signal Degrade on either Protection path or Working path (Local o Signal Degrade on either Protection path or Working path (Local
and Remote) and Remote)
o Manual Switch to either Protection path or Working path (Local and o Manual Switch to either Protection path or Working path (Local and
Remote) Remote)
o WTR Timer Expires (Local only) o WTR Timer Expiry (Local only)
o WTR (Remote only) o WTR (Remote only)
o Exercise (Local and Remote) o Exercise (Local and Remote)
o Reverse Request (Remote only) o Reverse Request (Remote only)
o Do-Not-Revert (Remote only) o Do-Not-Revert (Remote only)
o No Request (Remote and Local) o No Request (Remote and Local)
Note that the "Local only" requests are not signaled to the remote Note that the "Local only" requests are not tranmitted to the remote
LER. Likewise, the "Remote only" requests do not exist in the Local node. Likewise, the "Remote only" requests do not exist in the Local
Request logic as local inputs. For example, the priority of WTR only Request Logic as local inputs. For example, the priority of WTR only
applies to the received WTR message, which is generated from the applies to the received WTR message, which is generated from the
remote LER. The remote LER that is running the WTR timer in the WTR remote node. The remote node that is running the WTR timer in the
state has no local request. WTR state has no local request.
The remote request from the remote LER is assigned a priority just The remote SF and SD on either the working path or the protection
below the same local request. However, for the equal priority path and the remote MS to either the working path or the protection
requests, such as SD and MS, the following equal priority resolution path are indicated by the values of the Request and FPath fields in
rules are defined: the PSC message.
o If two local inputs having the same priority but requesting The remote request from the remote node is assigned a priority just
different action come to the Local Request logic, then the input below the same local request except NR and equal priority requests,
coming first SHALL be considered to have a higher priority than such as SD and MS. Since a received NR message needs to be used in
the other coming later (first-come, first-served). the state transition table lookup when there is no outstanding local
request, the remote NR request SHALL have a higher priority than the
local NR. For the equal priority requests, see Section 10.2.1.
o If the PSC Control logic has both the highest local request and a 10.2.1. Equal priority requests
remote message with the same priority and requesting the same
action, i.e., the same PSC Request field and the same FPath value,
then the local input SHALL be considered to have a higher priority
than the remote message.
o If the PSC Control logic has both the highest local request and a As stated in Section 10.2, the remote request from the remote node is
remote message with the same priority but requesting different assigned a priority just below the same local request. However, for
action and the remote message exists when the highest local equal priority requests, such as SD and MS, the priority SHALL be
request comes to the PSC Control logic, the highest local request evaluated as described in this section.
is ignored and the remote Request SHALL be the top priority global
request.
o If the PSC Control logic has both the highest local request and a For equal priority local requests, first-come, first-served rule
remote message with the same priority but requesting different SHALL be applied. Once a local request appears in the Local Request
action and the highest local request exists when the remote Logic, a subsequent equal priority local request requesting a
message comes to the PSC Control logic, the top priority global different action, i.e., the action results in the same Request value
request SHALL be determined by the following rules for each but a different FPath value, SHALL be considered to have a lower
simultaneous condition: priority. Furthermore, in the case of MS command, the subsequent
local MS command requesting a different action SHALL be rejected and
cleared.
o For simultaneous MS requests, the MS-W request SHALL be considered When the priority is evaluated in the PSC Control Logic between the
to have a higher priority than the MS-P request. The LER that has highest local request and a remote request, the following equal
local MS-W request SHALL maintain the local MS-W request as the priority resolution rules SHALL be applied:
top priority global request, but the other LER that has local MS-P
request SHALL clear the MS-P command and internally generate
"Operator Clear" request.
o For simultaneous SD requests, the SD on the standby path (the path o If two requests request the same action, i.e., the same Request
from which the selector does not select the user data traffic) and FPath values, then the local request SHALL be considered to
SHALL be considered as having higher priority than the SD on the have a higher priority than the remote request.
active path (the path from which the selector selects the user
data traffic) regardless of its origin (local or remote message).
The LER that has the SD on the standby path SHALL maintain the
local SD on the standby path request as the top priority global
request. The other LER that has local SD on the active path SHALL
use the remote SD on the standby path as the top priority global
request to lookup the state transition table. The differentiation
of the active and standby paths is based upon which path had been
used for the user data traffic at the time just before an LER
selected its local SD as the top priority global request.
No Request is another exception to the rule of assigning a remote o When the highest local request comes to the PSC Control Logic, if
request a priority just below the same local request. Since a the remote request that requests a different action exists, then
received NR message needs to be used in the state transition table the highest local request SHALL be ignored and the remote request
lookup when there is no outstanding local request, the received SHALL remain to be the top priority global request. In the case
remote NR request SHALL be the top priority global request when there of MS command, the local MS command requesting a different action
is no request in the local LER. SHALL be cancelled.
o When the remote request comes to the PSC Control Logic, if the
highest local request that requests a different action exists,
then the top priority global request SHALL be determined by the
following rules:
* For MS requests, the MS-W request SHALL be considered to have a
higher priority than the MS-P request. The node that has local
MS-W request SHALL maintain the local MS-W request as the top
priority global request. The other node that has local MS-P
request SHALL cancel the MS-P command and SHALL generate
"Operator Clear" internally as the top priority global request.
* For SD requests, the SD on the standby path (the path from
which the selector does not select the user data traffic) SHALL
be considered to have a higher priority than the SD on the
active path (the path from which the selector selects the user
data traffic) regardless of its origin (local or remote
message). The node that has the SD on the standby path SHALL
maintain the local SD on the standby path request as the top
priority global request. The other node that has local SD on
the active path SHALL use the remote SD on the standby path as
the top priority global request to lookup the state transition
table. The differentiation of the active and standby paths is
based upon which path had been selected for the user data
traffic "when each node detected its local SD".
10.3. Acceptance and retention of local inputs 10.3. Acceptance and retention of local inputs
A local input indicating a defect, such as SF-P, SF-W, SD-P and SD-W, A local input indicating a defect, such as SF-P, SF-W, SD-P and SD-W,
SHALL be accepted and retained persistently in the Local Request SHALL be accepted and retained persistently in the Local Request
logic as long as the defect condition exists. If there is any higher Logic as long as the defect condition exists. If there is any higher
priority local input than the local defect input, the higher priority priority local input than the local defect input, the higher priority
local input is passed to the PSC Control logic as the highest local local input is passed to the PSC Control Logic as the highest local
request, but the local defect input cannot be removed but remains in request, but the local defect input cannot be removed but remains in
the Local Request logic. When the higher priority local input the Local Request Logic. When the higher priority local input is
disappears, the local defect will become the highest local request if cleared, the local defect will become the highest local request if
the defect condition still exists. the defect condition still exists.
Operator Clear command, SFDc and WTR Timer Expires are not Operator Clear (OC) command, SFDc and WTR Timer Expiry are not
persistent. Once they appear to the Local Request logic and complete persistent. Once they appear to the Local Request Logic and complete
the operation, they SHALL be disappeared. all the operations in the protection switching control, they SHALL
disappear.
Operator LO, FS, MS, and EXER commands SHALL be rejected if there is LO, FS, MS, and EXER commands SHALL be rejected if there is any
any higher priority local input in the Local Request logic. If a new higher priority local input in the Local Request Logic. If a new
higher-priority local request (including an operator command) is higher-priority local request (including an operator command) is
accepted, any previous lower-priority local operator command SHALL be accepted, any previous lower-priority local operator command SHALL be
cancelled. When any higher-priority remote request is received, a cancelled. When any higher-priority remote request is received, a
lower-priority local operator command SHALL be cancelled. The lower-priority local operator command SHALL be cancelled. The
cancelled operator command is forgotten and will never return, unless cancelled operator command is cleared. If the operators wish to
the operator reissues the command. renew the cancelled command then they should reissue the command.
11. State Transition Tables in APS Mode 11. State Transition Tables in APS Mode
When there is a change in the highest local request or in remote PSC When there is a change in the highest local request or in remote PSC
messages, the top priority global request SHALL be evaluated and the messages, the top priority global request SHALL be evaluated and the
state transition tables SHALL be looked up in the PSC Control logic. state transition tables SHALL be looked up in the PSC Control Logic.
The following rules are applied to the operation related to the state The following rules are applied to the operation related to the state
transition table lookup. transition table lookup.
o If the top priority global request, which determines the state o If the top priority global request, which determines the state
transition, is the highest local request, the local state transition, is the highest local request, the local state
transition table in Section 11.1 SHALL be used to decide the next transition table in Section 11.1 SHALL be used to decide the next
state of the LER. Otherwise, remote messages state transition state of the node. Otherwise, the remote state transition table
table in Section 11.2 SHALL be used. in Section 11.2 SHALL be used.
o If in remote state, the highest local defect condition (SF-P, o If in remote state, the highest local defect condition (SF-P,
SF-W, SD-P or SD-W) SHALL always be reflected in the Request field SF-W, SD-P or SD-W) SHALL always be reflected in the Request and
and Fpath. Fpath fields.
o For the LER currently in the local state, if the top priority o For the node currently in the local state, if the top priority
global request is changed to Operator Clear (OC) or SFDc causing global request is changed to OC or SFDc causing the next state to
the next state to be Normal, WTR or DNR, then all the local and be Normal, WTR or DNR, then all the local and remote requests
remote requests SHALL be re-evaluated as if the LER is in the SHALL be re-evaluated as if the node is in the state specified in
state specified in the footnotes to the state transition tables, the footnotes to the state transition tables, before deciding the
before deciding the final state. If there are no active requests, final state. If there are no active requests, the node enters the
the LER enters the state specified in the footnotes to the state state specified in the footnotes to the state transition tables.
transition tables. This re-evaluation is an internal operation This re-evaluation is an internal operation confined within the
confined within the local LER, and the PSC messages are generated local node, and the PSC messages are generated according to the
according to the final state. final state.
o The WTR timer is started only when the LER which has recovered o The WTR timer is started only when the node which has recovered
from a local failure/degradation enters the WTR state. An LER from a local failure or degradation enters the WTR state. A node
which is entering into the WTR state due to a remote WTR message which is entering into the WTR state due to a remote WTR message
does not start the WTR timer. The WTR timer SHALL be stopped when does not start the WTR timer. The WTR timer SHALL be stopped when
any local or remote request triggers the state change out of the any local or remote request triggers the state change out of the
WTR state. WTR state.
The extended states, as they appear in the table, are as follows: The 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 LO command UA:LO:L Unavailable state due to local LO command
UA:P:L Unavailable state due to local SF-P UA:P:L Unavailable state due to local SF-P
UA:DP:L Unavailable state due to local SD-P UA:DP:L Unavailable state due to local SD-P
UA:LO:R Unavailable state due to remote LO message UA:LO:R Unavailable state due to remote LO message
UA:P:R Unavailable state due to remote SF-P message UA:P:R Unavailable state due to remote SF-P message
UA:DP:R Unavailable state due to remote SD-P message UA:DP:R Unavailable state due to remote SD-P message
PF:W:L Protecting failure state due to local SF-W PF:W:L Protecting Failure state due to local SF-W
PF:DW:L Protecting failure state due to local SD-W PF:DW:L Protecting Failure state due to local SD-W
PF:W:R Protecting failure state due to remote SF-W message PF:W:R Protecting Failure state due to remote SF-W message
PF:DW:R Protecting failure state due to remote SD-W message PF:DW:R Protecting Failure state due to remote SD-W message
SA:F:L Switching administrative state due to local FS command SA:F:L Switching Administrative state due to local FS command
SA:MW:L Switching administrative state due to local MS-W command SA:MW:L Switching Administrative state due to local MS-W command
SA:MP:L Switching administrative state due to local MS-P command SA:MP:L Switching Administrative state due to local MS-P command
SA:F:R Switching administrative state due to remote FS message SA:F:R Switching Administrative state due to remote FS message
SA:MW:R Switching administrative state due to remote MS-W message SA:MW:R Switching Administrative state due to remote MS-W message
SA:MP:R Switching administrative state due to remote MS-P message SA:MP:R Switching Administrative state due to remote MS-P message
E::L Exercise state due to local EXER command
E::R Exercise state due to remote EXER message
WTR Wait-to-Restore state WTR Wait-to-Restore state
DNR Do-not-Revert state DNR Do-not-Revert state
E::L Exercise state due to local EXER command
E::R Exercise state due to remote EXER message
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 fields. The table below lists the message
is generally sent in each particular state. If the message to be that is generally sent in each particular state. If the message to
sent in a particular state deviates from the table below, it is noted be sent in a particular state deviates from the table below, it is
in the footnotes to the state transition tables. noted in the footnotes to the state transition tables.
State REQ(FP,P) State Request(FPath,Path)
------- --------- ------- ------------------------------------
N NR(0,0) N NR(0,0)
UA:LO:L LO(0,0) UA:LO:L LO(0,0)
UA:P:L SF(0,0) UA:P:L SF(0,0)
UA:DP:L SD(0,0) UA:DP:L SD(0,0)
UA:LO:R highest local request(local FPath,0) UA:LO:R highest local request(local FPath,0)
UA:P:R highest local request(local FPath,0) UA:P:R highest local request(local FPath,0)
UA:DP:R highest local request(local FPath,0) UA:DP:R highest local request(local FPath,0)
PF:W:L SF(1,1) PF:W:L SF(1,1)
PF:DW:L SD(1,1) PF:DW:L SD(1,1)
PF:W:R highest local request(local FPath,1) PF:W:R highest local request(local FPath,1)
skipping to change at page 24, line 6 skipping to change at page 23, line 6
SA:MP:L | UA:DP:L | PF:DW:L | i | i | i | i SA:MP:L | UA:DP:L | PF:DW:L | i | i | i | i
SA:F:R | UA:DP:L | PF:DW:L | i | i | i | i SA:F:R | UA:DP:L | PF:DW:L | i | i | i | i
SA:MW:R | UA:DP:L | PF:DW:L | SA:MW:L | i | i | i SA:MW:R | UA:DP:L | PF:DW:L | SA:MW:L | i | i | i
SA:MP:R | UA:DP:L | PF:DW:L | i | SA:MP:L | i | i SA:MP:R | UA:DP:L | PF:DW:L | i | SA:MP:L | i | i
WTR | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | (6) | i WTR | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | (6) | i
DNR | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L DNR | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L
E::L | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | i E::L | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | i
E::R | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L E::R | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L
NOTES: NOTES:
(1) Re-evaluate to determine final state as if the LER is in the (1) Re-evaluate to determine final state as if the node is in the
Normal state. If there are no active requests, the LER enters Normal state. If there are no active requests, the node enters
the Normal State. the Normal State.
(2) In the case that both local input after SFDc and the last (2) In the case that both local input after SFDc and the last
received remote message are no requests, the LER enters into the received remote message are no requests, the node enters into
WTR state when the domain is configured for revertive behavior, the WTR state when the domain is configured for revertive
or the LER enters into the DNR state when the domain is behavior, or the node enters into the DNR state when the domain
configured for non-revertive behavior. In all the other cases, is configured for non-revertive behavior. In all the other
where one or more active requests exist, re-evaluate to cases, where one or more active requests exist, re-evaluate to
determine the final state as if the LER is in the Normal state. determine the final state as if the node is in the Normal state.
(3) Re-evaluate to determine final state as if the LER is in the (3) Re-evaluate to determine final state as if the node is in the
Normal state when the domain is configured for revertive Normal state when the domain is configured for revertive
behavior, or as if the LER is in the DNR state when the domain behavior, or as if the node is in the DNR state when the domain
is configured for non-revertive behavior. If there are no is configured for non-revertive behavior. If there are no
active requests, the LER enters either the Normal state when the active requests, the node enters either the Normal state when
domain is configured for revertive behavior or the DNR state the domain is configured for revertive behavior or the DNR state
when the domain is configured for non-revertive behavior. when the domain is configured for non-revertive behavior.
(4) Remain in the WTR state and send NR(0,1). Stop the WTR timer if (4) Remain in the WTR state and send NR(0,1). Stop the WTR timer if
it is running. In APS mode, OC can cancel the WTR timer and it is running. In APS mode, OC can cancel the WTR timer and
hasten the state transition to the Normal state as in other hasten the state transition to the Normal state as in other
transport networks. transport networks.
(5) If Path value is 0, re-evaluate to determine final state as if (5) If Path value is 0, re-evaluate to determine final state as if
the LER is in the Normal state. If Path value is 1, re-evaluate the node is in the Normal state. If Path value is 1, re-
to determine final state as if the LER is in the DNR state. If evaluate to determine final state as if the node is in the DNR
there are no active requests, the LER enters the Normal state state. If there are no active requests, the node enters the
when Path value is 0, or the DNR state when Path value is 1. Normal state when Path value is 0, or the DNR state when Path
value is 1.
(6) Remain in the WTR state and send NR(0,1). (6) Remain in the WTR state and send NR(0,1).
11.2. State transition by remote messages 11.2. State transition by remote messages
| LO | SF-P | FS | SF-W | SD-P | SD-W | | LO | SF-P | FS | SF-W | SD-P | SD-W |
--------+---------+--------+--------+--------+---------+---------+ --------+---------+--------+--------+--------+---------+---------+
N | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | N | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
UA:LO:L | i | i | i | i | i | i | UA:LO:L | i | i | i | i | i | i |
UA:P:L | UA:LO:R | i | i | i | i | i | UA:P:L | UA:LO:R | i | i | i | i | i |
UA:DP:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | i | (7) | UA:DP:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | i | (7) |
skipping to change at page 26, line 7 skipping to change at page 25, line 7
SA:F:R | SA:MW:R | SA:MP:R | i | E::R | i | DNR | N SA:F:R | SA:MW:R | SA:MP:R | i | E::R | i | DNR | N
SA:MW:R | i | SA:MP:R | i | E::R | i | i | N SA:MW:R | i | SA:MP:R | i | E::R | i | i | N
SA:MP:R | SA:MW:R | i | i | E::R | i | DNR | N SA:MP:R | SA:MW:R | i | i | E::R | i | DNR | N
WTR | SA:MW:R | SA:MP:R | i | i | i | i | (12) WTR | SA:MW:R | SA:MP:R | i | i | i | i | (12)
DNR | SA:MW:R | SA:MP:R | i | E::R | i | i | i DNR | SA:MW:R | SA:MP:R | i | E::R | i | i | i
E::L | SA:MW:R | SA:MP:R | (13)| i | i | i | i E::L | SA:MW:R | SA:MP:R | (13)| i | i | i | i
E::R | SA:MW:R | SA:MP:R | i | i | i | DNR | N E::R | SA:MW:R | SA:MP:R | i | i | i | DNR | N
NOTES: NOTES:
(7) If the received SD-W message has Path=0, ignore the message. If (7) If the received SD-W message has Path=0, ignore the message. If
the received SD-W message has Path=1, go to PF:DW:R state and the received SD-W message has Path=1, go to the PF:DW:R state
transmit SD(0,1) and transmit SD(0,1)
(8) If the received SD-P message has Path=1, ignore the message. If (8) If the received SD-P message has Path=1, ignore the message. If
the received SD-P message has Path=0, go to UA:DP:R state and the received SD-P message has Path=0, go to the UA:DP:R state
transmit SD(1,0). and transmit SD(1,0).
(9) Transition to the WTR state and continue to send the current (9) Transition to the WTR state and continue to send the current
message. message.
(10) Transition to the DNR state and continue to send the current (10) Transition to the DNR state and continue to send the current
message. message.
(11) If the received NR message has Path=1, transition to the WTR (11) If the received NR message has Path=1, transition to the WTR
state if domain configured for revertive behavior, else state if domain configured for revertive behavior, else
transition to the DNR state. If the received NR message has transition to the DNR state. If the received NR message has
Path=0, transition to the Normal state. Path=0, transition to the Normal state.
(12) If the receiving LER's WTR timer is running, maintain current (12) If the receiving node's WTR timer is running, maintain current
state and message. If the WTR timer is not running, transition state and message. If the WTR timer is not running, transition
to the Normal state. to the Normal state.
(13) Transit to the WTR state and send NR(0,1) message. The WTR (13) Transit to the WTR state and send NR(0,1) message. The WTR
timer is not initiated. timer is not initiated.
11.3. State transition for 1+1 unidirectional protection 11.3. State transition for 1+1 unidirectional protection
The state transition tables given in Section 11.1 and Section 11.2 The state transition tables given in Sections 11.1 and 11.2 are for
are for bidirectional protection switching, where remote PSC protocol bidirectional protection switching, where remote PSC protocol
messages are used to determine the protection switching actions. The messages are used to determine the protection switching actions. 1+1
1+1 unidirectional protection switching does not require the remote unidirectional protection switching does not require the remote
information in PSC protocol message and acts upon local inputs only. information in PSC protocol message and acts upon local inputs only.
The state transition by local inputs in Section 11.1 SHALL be reused The state transition by local inputs in Section 11.1 SHALL be reused
for the 1+1 unidirectional protection under the following conditions: for 1+1 unidirectional protection under the following conditions:
o The value of Request field in the received remote message is o The value of Request field in the received remote message is
ignored and always assumed to be no request. ignored and always assumed to be no request.
o Replace footnote (4) with "Stop the WTR timer and transit to the o Replace footnote (4) with "Stop the WTR timer and transit to the
Normal state." Normal state."
o Replace footnote (6) with "Transit to the Normal state." o Replace footnote (6) with "Transit to the Normal state."
o Exercise is not applicable. o Exercise command is not relevant.
12. Provisioning Mismatch and Protocol Failure in the APS Mode 12. Provisioning Mismatch and Protocol Failure in APS Mode
The remote PSC message that is received from the remote LER is The remote PSC message that is received from the remote node is
subject to the detection of provisioning mismatch and protocol subject to the detection of provisioning mismatch and protocol
failure conditions. In the APS mode, provisioning mismatches are failure conditions. In APS mode, provisioning mismatches are handled
handled as follows: as follows:
o If the PSC message is received from the working path due to o If the PSC message is received from the working path due to
working/protection path configuration mismatch, the node MUST working/protection path configuration mismatch, the node MUST
alert the operator and MUST NOT perform any protection switching alert the operator and MUST NOT perform any protection switching
until the operator resolves this path configuration mismatch. until the operator resolves this path configuration mismatch.
o In the case that the mismatch happens in two-bit "Protection Type o In the case that the mismatch happens in two-bit "Protection Type
(PT)" field, which indicates permanent/selector bridge type and (PT)" field, which indicates permanent/selector bridge type and
uni/bidirectional switching type, uni/bidirectional switching type,
skipping to change at page 28, line 11 skipping to change at page 27, line 11
o No PSC message is received on the protection path during at least o No PSC message is received on the protection path during at least
3.5 times the long PSC message interval, (e.g. at least 17.5 3.5 times the long PSC message interval, (e.g. at least 17.5
seconds with a default message interval of 5 seconds) and there is seconds with a default message interval of 5 seconds) and there is
no defect on the protection path: The node MUST alert the operator no defect on the protection path: The node MUST alert the operator
and MUST NOT perform any protection switching until the operator and MUST NOT perform any protection switching until the operator
resolves this defect. resolves this defect.
13. Security Considerations 13. Security Considerations
No specific security issue is raised in addition to those ones This document introduces no new security risks. [RFC6378] points out
already documented in RFC 6378 [RFC6378] that MPLS relies on assumptions about traffic injection difficulty
and assumes that the control plane does not have end-to-end security.
[RFC5920] describes MPLS security issues and generic methods for
securing traffic privacy and integrity. MPLS use should conform such
advice.
14. IANA Considerations 14. IANA Considerations
14.1. MPLS PSC Request Registry 14.1. MPLS PSC Request Registry
In the "Multiprotocol Label Switching (MPLS) Operations, In the "Generic Associated Channel (G-ACh) Parameters" registry, IANA
Administration, and Management (OAM) Parameters" registry, IANA
maintains the "MPLS PSC Request Registry". maintains the "MPLS PSC Request Registry".
IANA is requested to assign two new code points from this registry. IANA is requested to assign two new code points from this registry.
The values shall be allocated as follows: The values shall be allocated as follows:
Value Description Reference Value Description Reference
----- --------------------- --------------- ----- --------------------- ---------------
2 Reverse Request (this document) 2 Reverse Request (this document)
3 Exercise (this document) 3 Exercise (this document)
14.2. MPLS PSC TLV Registry 14.2. MPLS PSC TLV Registry
In the "Multiprotocol Label Switching (MPLS) Operations, In the "Generic Associated Channel (G-ACh) Parameters" registry, IANA
Administration, and Management (OAM) Parameters" registry, IANA
maintains the "MPLS PSC TLV Registry". maintains the "MPLS PSC TLV Registry".
This document defines a new value for the Capabilities TLV type in This document defines a new value for the Capabilities TLV type in
the "MPLS PSC TLV Registry". the "MPLS PSC TLV Registry".
Value Description Reference Value Description Reference
------ --------------------- --------------- ------ --------------------- ---------------
TBD Capabilities (this document) TBD Capabilities (this document)
14.3. MPLS PSC Capability Flag Registry 14.3. MPLS PSC Capability Flag Registry
IANA is requested to create and maintain a new registry within the IANA is requested to create and maintain a new registry within the
"Multiprotocol Label Switching (MPLS) Operations, Administration, and "Generic Associated Channel (G-ACh) Parameters" registry called "MPLS
Management (OAM) Parameters" registry called "MPLS PSC Capability PSC Capability Flag Registry". All flags within this registry SHALL
Flag Registry". All flags within this registry SHALL be allocated be allocated according to the "Standards Action" procedures as
according to the "Standards Action" procedures as specified in RFC specified in RFC 5226 [RFC5226].
5226 [RFC5226].
The length of the flags MUST be a multiple of 4 octets. This The length of the flags MUST be a multiple of 4 octets. This
document defines 4 octet flags. Flags greater than 4 octets SHALL be document defines 4 octet flags. Flags greater than 4 octets SHALL be
used only if more than 32 Capabilities need to be defined. Flags used only if more than 32 Capabilities need to be defined. Flags
defined in this document are: defined in this document are:
Bit Hex Value Capability Reference Bit Hex Value Capability Reference
---- ---------- ----------------------------------- --------------- ---- ---------- ----------------------------------- ---------------
0 0x80000000 priority modification (this document) 0 0x80000000 priority modification (this document)
1 0x40000000 non-revertive behavior modification (this document) 1 0x40000000 non-revertive behavior modification (this document)
2 0x20000000 support of MS-W command (this document) 2 0x20000000 support of MS-W command (this document)
3 0x10000000 support of protection against SD (this document) 3 0x10000000 support of protection against SD (this document)
4 0x08000000 support of EXER command (this document) 4 0x08000000 support of EXER command (this document)
5-31 Unassigned (this document) 5-31 Unassigned (this document)
15. Acknowledgements 15. Acknowledgements
The authors would like to thank Yaacov Weingarten, Yuji Tochio, The authors would like to thank Yaacov Weingarten, Yuji Tochio,
Malcolm Betts, Ross Callon and Qin Wu for their valuable comments and Malcolm Betts, Ross Callon, Qin Wu and Xian Zhang for their valuable
suggestions on this document. comments and suggestions on this document.
We would also like to acknowledge explicit text provided by Loa We would also like to acknowledge explicit text provided by Loa
Andersson and Adrian Farrel. Andersson and Adrian Farrel.
16. References 16. References
16.1. Normative References 16.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.
skipping to change at page 30, line 5 skipping to change at page 29, line 5
[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear
Protection", RFC 6378, October 2011. Protection", RFC 6378, October 2011.
16.2. Informative References 16.2. Informative References
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and
Restoration) Terminology for Generalized Multi-Protocol Restoration) Terminology for Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4427, March 2006. Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS- [RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS-
TP) Survivability Framework", RFC 6372, September 2011. TP) Survivability Framework", RFC 6372, September 2011.
[G841] International Telecommunications Union, "Types and [G841] International Telecommunications Union, "Types and
characteristics of SDH network protection architectures", characteristics of SDH network protection architectures",
ITU-T Recommendation G.841, October 1998. ITU-T Recommendation G.841, October 1998.
[G873.1] International Telecommunications Union, "Optical Transport [G873.1] International Telecommunications Union, "Optical Transport
Network (OTN): Linear protection", ITU-T Recommendation Network (OTN): Linear protection", ITU-T Recommendation
G.873.1, July 2011. G.873.1, July 2011.
[G8031] International Telecommunications Union, "Ethernet Linear [G8031] International Telecommunications Union, "Ethernet Linear
Protection Switching", ITU-T Recommendation G.8031/Y.1342, Protection Switching", ITU-T Recommendation G.8031/Y.1342,
June 2011. June 2011.
Appendix A. An Example of Out-of-service Ccenarios Appendix A. An Example of Out-of-service Scenarios
The sequence diagram shown is an example of the out-of-service The sequence diagram shown is an example of the out-of-service
scenarios based on the priority level defined in RFC 6378. The first scenarios based on the priority level defined in [RFC6378]. The
PSC message which differs from the previous PSC message is shown. first PSC message which differs from the previous PSC message is
shown.
A Z A Z
| | | |
(1) |-- NR(0,0) ------>| (1) (1) |-- NR(0,0) ------>| (1)
|<----- NR(0,0) ---| |<----- NR(0,0) ---|
| | | |
| | | |
| (FS issued at Z) | (2) | (FS issued at Z) | (2)
(3) |<------ FS(1,1) --| (3) |<------ FS(1,1) --|
|-- NR(0,1) ------>| |-- NR(0,1) ------>|
skipping to change at page 30, line 48 skipping to change at page 30, line 6
| | | |
| | | |
| (Clear FS at Z) | (5) | (Clear FS at Z) | (5)
(6) | X <- NR(0,0) --| (6) | X <- NR(0,0) --|
| | | |
| | | |
(1) Each end is in the Normal state, and transmits NR(0,0) messages. (1) Each end is in the Normal state, and transmits NR(0,0) messages.
(2) When a FS command is issued at node Z, node Z goes into local (2) When a FS command is issued at node Z, node Z goes into local
Protecting administrative state (PA:F:L) and begins transmission of Protecting Administrative state (PA:F:L) and begins transmission of
an FS(1,1) messages. an FS(1,1) messages.
(3) A remote FS message causes node A to go into remote Protecting (3) A remote FS message causes node A to go into remote Protecting
administrative state (PA:F:R), and node A begins transmitting NR(0,1) Administrative state (PA:F:R), and node A begins transmitting NR(0,1)
messages. messages.
(4) When node A detects a unidirectional SF-P, node A keeps sending (4) When node A detects a unidirectional SF-P, node A keeps sending
NR(0,1) message because SF-P is ignored under the PA:F:R state. NR(0,1) message because SF-P is ignored under the PA:F:R state.
(5) When a Clear command is issued at node Z, node Z goes into the (5) When a Clear command is issued at node Z, node Z goes into the
Normal state and begins transmission of NR(0,0) messages. Normal state and begins transmission of NR(0,0) messages.
(6) But, node A cannot receive PSC message because of local (6) But, node A cannot receive PSC message because of local
unidirectional SF-P. Because no valid PSC message is received, over unidirectional SF-P. Because no valid PSC message is received, over
skipping to change at page 31, line 30 skipping to change at page 30, line 34
Now, there exists a mismatch between the bridge/selector positions of Now, there exists a mismatch between the bridge/selector positions of
node A (transmitting an NR(0,1)) and node Z (transmitting an node A (transmitting an NR(0,1)) and node Z (transmitting an
NR(0,0)). It results in out-of-service even when there is neither NR(0,0)). It results in out-of-service even when there is neither
SF-W nor FS. SF-W nor FS.
Appendix B. An Example of Sequence Diagram Showing the Problem with the Appendix B. An Example of Sequence Diagram Showing the Problem with the
Priority Level of SFc Priority Level of SFc
An example of sequence diagram showing the problem with the priority An example of sequence diagram showing the problem with the priority
level of SFc defined in RFC 6378 is given below. The following level of SFc defined in [RFC6378] is given below. The following
sequence diagram is depicted for the case of bidirectional signal sequence diagram is depicted for the case of bidirectional signal
fails. However, other cases with unidirectional signal fails can fails. However, other cases with unidirectional signal fails can
result in the same problem. The first PSC message which differs from result in the same problem. The first PSC message which differs from
the previous PSC message is shown. the previous PSC message is shown.
A Z A Z
| | | |
(1) |-- NR(0,0) ------>| (1) (1) |-- NR(0,0) ------>| (1)
|<----- NR(0,0) ---| |<----- NR(0,0) ---|
| | | |
skipping to change at page 32, line 37 skipping to change at page 31, line 37
(2) When SF-P occurs, each node enters into the UA:P:L state and (2) When SF-P occurs, each node enters into the UA:P:L state and
transmits SF(0,0) messages. Traffic remains on the working path. transmits SF(0,0) messages. Traffic remains on the working path.
(3) When SF-W occurs, each node remains in the UA:P:L state as SF-W (3) When SF-W occurs, each node remains in the UA:P:L state as SF-W
has a lower priority than SF-P. Traffic is still on the working has a lower priority than SF-P. Traffic is still on the working
path. Traffic cannot be delivered as both the working path and the path. Traffic cannot be delivered as both the working path and the
protection path are experiencing signal fails. protection path are experiencing signal fails.
(4) When SF-P is cleared, local "Clear SF-P" request cannot be (4) When SF-P is cleared, local "Clear SF-P" request cannot be
presented to the PSC Control logic, which takes the highest local presented to the PSC Control Logic, which takes the highest local
request and runs PSC state machine, since the priority of "Clear request and runs PSC state machine, since the priority of "Clear
SF-P" is lower than that of SF-W. Consequently, there is no change SF-P" is lower than that of SF-W. Consequently, there is no change
in state, and the selector and/or bridge keep pointing at the working in state, and the selector and/or bridge keep pointing at the working
path, which has signal fail condition. path, which has signal fail condition.
Now, traffic cannot be delivered while the protection path is Now, traffic cannot be delivered while the protection path is
recovered and available. It should be noted that the same problem recovered and available. It should be noted that the same problem
will occur in the case that the sequence of SF-P and SF-W events is will occur in the case that the sequence of SF-P and SF-W events is
changed. changed.
If we further continue with this sequence to see what will happen If we further continue with this sequence to see what will happen
after SF-W is cleared, after SF-W is cleared,
(5) When SF-W is cleared, local "Clear SF-W" request can be passed to (5) When SF-W is cleared, local "Clear SF-W" request can be passed to
the PSC Control logic as there is no higher priority local input, but the PSC Control Logic as there is no higher priority local input, but
this will be ignored in the PSC Control logic according to the state this will be ignored in the PSC Control Logic according to the state
transition definition in RFC 6378. There will be no change in state transition definition in [RFC6378]. There will be no change in state
or protocol message transmitted. or protocol message transmitted.
As SF-W is now cleared and the selector and/or bridge are still As SF-W is now cleared and the selector and/or bridge are still
pointing at the working path, traffic delivery is resumed. However, pointing at the working path, traffic delivery is resumed. However,
each node is the in UA:P:L state and transmitting SF(0,0) message, each node is in the UA:P:L state and transmitting SF(0,0) message,
while there exists no outstanding request for protection switching. while there exists no outstanding request for protection switching.
Moreover, any future legitimate protection switching requests, such Moreover, any future legitimate protection switching requests, such
as SF-W, will be rejected as each node thinks the protection path is as SF-W, will be rejected as each node thinks the protection path is
unavailable. unavailable.
Appendix C. Freeze Command Appendix C. Freeze Command
The "Freeze" command applies only to the local LER of the protection The "Freeze" command applies only to the local node of the protection
group and is not signaled to the remote LER. This command freezes group and is not signaled to the remote node. This command freezes
the state of the protection group. Until the Freeze is cleared, the state of the protection group. Until the Freeze is cleared,
additional local commands are rejected and condition changes and additional local commands are rejected and condition changes and
received PSC information are ignored. received PSC information are ignored.
"Clear Freeze" command clears the local freeze. When the Freeze "Clear Freeze" command clears the local freeze. When the Freeze
command is cleared, the state of the protection group is recomputed command is cleared, the state of the protection group is recomputed
based on the persistent condition of the local triggers. based on the persistent condition of the local triggers.
Because the freeze is local, if the freeze is issued at one end only, Because the freeze is local, if the freeze is issued at one end only,
a failure of protocol can occur as the other end is open to accept a failure of protocol can occur as the other end is open to accept
any operator command or a fault condition. any operator command or a fault condition.
Appendix D. Operation Examples of the APS Mode Appendix D. Operation Examples of the APS Mode
The sequence diagrams shown in this section are only a few examples The sequence diagrams shown in this section are only a few examples
of the APS mode operations. The first PSC protocol message which of the APS mode operations. The first PSC protocol message which
differs from the previous message is shown. The operation of hold- differs from the previous message is shown. The operation of hold-
off timer is omitted. The Request, FPath and Path fields, whose off timer is omitted. The Request, FPath and Path fields, whose
values are changed during PSC message exchange are shown. For an values are changed during PSC message exchange are shown. For an
example, SF(1, 0) represents an PSC message with the following field example, SF(1,0) represents an PSC message with the following field
values: Request = SF, FPath = 1, and Path = 1. The values of the values: Request=SF, FPath=1 and Path=1. The values of the other
other fields remain unchanged from the initial configuration. fields remain unchanged from the initial configuration. W(A->Z) and
W(A->Z) and P(A->Z) indicate the working path and the protection path P(A->Z) indicate the working path and the protection path in the
in the direction of A to Z, respectively. direction of A to Z, respectively.
Example 1. 1:1 bidirectional protection switching (revertive mode) - Example 1. 1:1 bidirectional protection switching (revertive
Unidirectional SF case operation) - Unidirectional SF case
A Z A Z
| | | |
(1) |<---- NR(0,0)---->| (1) (1) |<---- NR(0,0)---->| (1)
| | | |
| | | |
(2) | (SF on W(Z->A)) | (2) | (SF on W(Z->A)) |
|---- SF(1,1)----->| (3) |---- SF(1,1)----->| (3)
(4) |<----- NR(0,1)----| (4) |<----- NR(0,1)----|
| | | |
| | | |
skipping to change at page 34, line 26 skipping to change at page 33, line 26
/| | /| |
| | | | | |
WTR timer | | WTR timer | |
| | | | | |
\| | \| |
(6) |---- NR(0,1)----->| (7) (6) |---- NR(0,1)----->| (7)
(8) |<----- NR(0,0)----| (8) |<----- NR(0,0)----|
|---- NR(0,0)----->| (9) |---- NR(0,0)----->| (9)
| | | |
(1) The protection domain is operating without any defect, and the (1) The protected domain is operating without any defect, and the
working path is used for delivering the traffic in the Normal state. working path is used for delivering the traffic in the Normal state.
(2) SF-W occurs in the Z to A direction. Node A enters into the (2) SF-W occurs in the Z to A direction. Node A enters into the
PF:W:L state and generates SF(1, 1) message. Selector and bridge of PF:W:L state and generates SF(1,1) message. Selector and bridge of
node A are pointing at the protection path. node A are pointing at the protection path.
(3) Upon receiving SF(1, 1), node Z sets selector and bridge to the (3) Upon receiving SF(1,1), node Z sets selector and bridge to the
protection path. As there is no local request in node Z, node Z protection path. As there is no local request in node Z, node Z
generates NR(0, 1) message in the PF:W:R state. generates NR(0,1) message in the PF:W:R state.
(4) Node A confirms that the remote LER is also selecting protection (4) Node A confirms that the remote node is also selecting the
path. protection path.
(5) Node A detects clearing of SF condition, starts the WTR timer, (5) Node A detects clearing of SF condition, starts the WTR timer,
and sends WTR(0, 1) message in the WTR state. and sends WTR(0,1) message in the WTR state.
(6) At expiration of the WTR timer, node A sets selector and bridge (6) At expiration of the WTR timer, node A sets selector and bridge
to the working path and sends NR(0, 1) message. to the working path and sends NR(0,1) message.
(7) Node Z is notified that the remote request has been cleared. (7) Node Z is notified that the remote request has been cleared.
Node Z transits to the Normal state and sends NR(0,0) message. Node Z transits to the Normal state and sends NR(0,0) message.
(8) Upon receiving NR(0,0) message, node A transits to the Normal (8) Upon receiving NR(0,0) message, node A transits to the Normal
state and sends NR(0,0) message. state and sends NR(0,0) message.
(9) It is confirmed that the remote LER is also selecting the working (9) It is confirmed that the remote node is also selecting the
path. working path.
Example 2. 1:1 bidirectional protection switching (revertive mode) - Example 2. 1:1 bidirectional protection switching (revertive
Bidirectional SF case - Inconsistent WTR timers operation) - Bidirectional SF case - Inconsistent WTR timers
A Z A Z
| | | |
(1) |<---- NR(0,0)---->| (1) (1) |<---- NR(0,0)---->| (1)
| | | |
| | | |
(2) | (SF on W(A<->Z)) | (2) (2) | (SF on W(A<->Z)) | (2)
|<---- SF(1,1)---->| |<---- SF(1,1)---->|
| | | |
| | | |
skipping to change at page 35, line 40 skipping to change at page 34, line 40
\| | \| |
(6) |--- NR(0,1)------>| (6) |--- NR(0,1)------>|
|<------ NR(0,0)---| (7) |<------ NR(0,0)---| (7)
(8) |--- NR(0,0)------>| (8) |--- NR(0,0)------>|
| | | |
(1) Each end is in the Normal state, and transmits NR(0,0) messages. (1) Each end is in the Normal state, and transmits NR(0,0) messages.
(2) When SF-W occurs, each node enters into the PF:W:L state and (2) When SF-W occurs, each node enters into the PF:W:L state and
transmits SF(1,1) messages. Traffic is switched to the protection transmits SF(1,1) messages. Traffic is switched to the protection
path. Upon receiving SF(1,1), each node confirms that the remote LER path. Upon receiving SF(1,1), each node confirms that the remote
is also sending and receiving the traffic from the protection path. node is also sending and receiving the traffic from the protection
path.
(3) When SF-W is cleared, each node transits to the PF:W:R state and (3) When SF-W is cleared, each node transits to the PF:W:R state and
transmits NR(0,1) messages as the last received message is SF-W. transmits NR(0,1) messages as the last received message is SF-W.
(4) Upon receiving NR(0,1) messages, each node goes into the WTR (4) Upon receiving NR(0,1) messages, each node goes into the WTR
state, starts the WTR timer, and sends the WTR(0,1) messages. state, starts the WTR timer, and sends the WTR(0,1) messages.
(5) At expiration of the WTR timer in node Z, node Z sends NR(0,1) as (5) At expiration of the WTR timer in node Z, node Z sends NR(0,1) as
the last received APS message was WTR. When NR(0,1) arrives at node the last received APS message was WTR. When NR(0,1) arrives at node
A, node A maintains the WTR state and keeps sending current WTR A, node A maintains the WTR state and keeps sending current WTR
messages as described in the state transition table. messages as described in the state transition table.
(6) At expiration of the WTR timer in node A, node A sends NR(0,1). (6) At expiration of the WTR timer in node A, node A sends NR(0,1).
(7) When the NR(0,1) message arrives at node Z, node Z moves to the (7) When the NR(0,1) message arrives at node Z, node Z moves to the
Normal state, sets selector and bridge to the working path, and sends Normal state, sets selector and bridge to the working path, and sends
NR(0, 0) message. NR(0,0) message.
(8) The received NR(0,0) message causes node A to go to the Normal (8) The received NR(0,0) message causes node A to go to the Normal
state. Now, the traffic is switched back to the working path. state. Now, the traffic is switched back to the working path.
Example 3. 1:1 bidirectional protection switching - R bit mismatch Example 3. 1:1 bidirectional protection switching - R bit mismatch
This example shows that both sides will interwork and the traffic is This example shows that both sides will interwork and the traffic is
protected when one side (node A) is configured as revertive mode and protected when one side (node A) is configured as revertive operation
the other (node Z) is configured as non-revertive mode. The and the other (node Z) is configured as non-revertive operation. The
interworking is covered in the state transition tables. interworking is covered in the state transition tables.
(revertive) A Z (non-revertive) (revertive) A Z (non-revertive)
| | | |
(1) |<---- NR(0,0)---->| (1) (1) |<---- NR(0,0)---->| (1)
| | | |
| | | |
(2) | (SF on W(A<->Z)) | (2) (2) | (SF on W(A<->Z)) | (2)
|<---- SF(1,1)---->| |<---- SF(1,1)---->|
| | | |
skipping to change at page 36, line 49 skipping to change at page 35, line 51
\| | \| |
(6) |--- NR(0,1)------>| (6) |--- NR(0,1)------>|
|<------ NR(0,0)---| (7) |<------ NR(0,0)---| (7)
(8) |--- NR(0,0)------>| (8) |--- NR(0,0)------>|
| | | |
(1) Each end is in the Normal state, and transmits NR(0,0) messages. (1) Each end is in the Normal state, and transmits NR(0,0) messages.
(2) When SF-W occurs, each node enters into the PF:W:L state and (2) When SF-W occurs, each node enters into the PF:W:L state and
transmits SF(l,l) messages. Traffic is switched to the protection transmits SF(l,l) messages. Traffic is switched to the protection
path. Upon receiving SF(1,1), each node confirms that the remote LER path. Upon receiving SF(1,1), each node confirms that the remote
is also sending and receiving the traffic on the protection path. node is also sending and receiving the traffic on the protection
path.
(3) When SF-W is cleared, each node transits to the PF:W:R state and (3) When SF-W is cleared, each node transits to the PF:W:R state and
transmits NR(0,1) messages as the last received message is SF-W. transmits NR(0,1) messages as the last received message is SF-W.
(4) Upon receiving NR(0,1) messages, node A goes into the WTR state, (4) Upon receiving NR(0,1) messages, node A goes into the WTR state,
starts the WTR timer, and sends WTR(0,1) messages. At the same time, starts the WTR timer, and sends WTR(0,1) messages. At the same time,
node B transits to the DNR state and sends DNR(0,1) message. node Z transits to the DNR state and sends DNR(0,1) message.
(5) When the WTR message arrives at node Z, node Z transits to the (5) When the WTR message arrives at node Z, node Z transits to the
WTR state and send NR(0,1) message according to the state transition WTR state and send NR(0,1) message according to the state transition
table. At the same time, the DNR message arrived at node Z is table. At the same time, the DNR message arrived at node Z is
ignored according to the state transition table. Therefore, node Z, ignored according to the state transition table. Therefore, node Z,
which is configured as non-revertive mode, is operating as if in which is configured as non-revertive operation, is operating as if in
revertive mode. revertive operation.
(6) At expiration of the WTR timer in node A, node A sends NR(0,1). (6) At expiration of the WTR timer in node A, node A sends NR(0,1).
(7) When the NR(0,1) message arrives at node Z, node Z moves to the (7) When the NR(0,1) message arrives at node Z, node Z moves to the
Normal state, sets selector and bridge to the working path, and sends Normal state, sets selector and bridge to the working path, and sends
NR(0, 0) message. NR(0,0) message.
(8) The received NR(0,0) message causes node A to transits to the (8) The received NR(0,0) message causes node A to transits to the
Normal state. Now, the traffic is switched back to the working path. Normal state. Now, the traffic is switched back to the working path.
Authors' Addresses Authors' Addresses
Jeong-dong Ryoo (editor) Jeong-dong Ryoo (editor)
ETRI ETRI
218 Gajeongno 218 Gajeongno
Yuseong-gu, Daejeon 305-700 Yuseong-gu, Daejeon 305-700
 End of changes. 169 change blocks. 
478 lines changed or deleted 502 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/