draft-ietf-mpls-tp-psc-itu-01.txt   draft-ietf-mpls-tp-psc-itu-02.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: July 23, 2014 H. van Helvoort Expires: August 12, 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.
January 19, 2014 February 8, 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-01.txt draft-ietf-mpls-tp-psc-itu-02.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 sub-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.
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 July 23, 2014. This Internet-Draft will expire on August 12, 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 37 skipping to change at page 2, line 37
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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. Motivations 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 . . . . . . . 7
4.3. Motivation for introducing Freeze command . . . . . . . . 7 4.3. Motivation for introducing Freeze command . . . . . . . . 7
4.4. Modifications to RFC 6378 . . . . . . . . . . . . . . . . 7 4.4. Procedures in support of Capability 1 . . . . . . . . . . 7
5. Capability 2: Modification of non-revertive operation . . . . 8 5. Capability 2: Non-revertive Behavior Modification . . . . . . 8
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. Terms modified to support MS-W . . . . . . . . . . . . . 9 6.2. Terminology to support MS-W . . . . . . . . . . . . . . . 9
6.3. Behavior of MS-P and MS-W . . . . . . . . . . . . . . . . 9 6.3. Behavior of MS-P and MS-W . . . . . . . . . . . . . . . . 9
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 . . . . . . . 10
7.1. Motivation for supporting protection against SD . . . . . 10 7.1. Motivation for supporting protection against SD . . . . . 10
7.2. Terms modified to support SD . . . . . . . . . . . . . . 10 7.2. Terminology to support SD . . . . . . . . . . . . . . . . 10
7.3. Behavior of protection against SD . . . . . . . . . . . . 10 7.3. Behavior of protection against SD . . . . . . . . . . . . 11
7.4. Equal priority resolution . . . . . . . . . . . . . . . . 11 7.4. Equal priority resolution . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . 14
9.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 14
9.1.1. Sending the Capabilities TLV . . . . . . . . . . . . 15 9.1.1. Sending and receiving the Capabilities TLV . . . . . 15
9.1.2. Receiving the Capabilities TLV . . . . . . . . . . . 15 9.2. Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1.3. Handling Capabilities TLV errors . . . . . . . . . . 15 9.2.1. PSC mode . . . . . . . . . . . . . . . . . . . . . . 16
9.2. Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.2.2. APS mode . . . . . . . . . . . . . . . . . . . . . . 16
9.2.1. PSC Mode . . . . . . . . . . . . . . . . . . . . . . 16 10. PSC Protocol in APS Mode . . . . . . . . . . . . . . . . . . 16
9.2.2. APS Mode . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Request field in PSC protocol message . . . . . . . . . 16
9.3. Backward compatibility . . . . . . . . . . . . . . . . . 17 10.2. Priorities of local inputs and remote requests . . . . . 16
10. PSC Protocol in APS Mode . . . . . . . . . . . . . . . . . . 17 10.3. Acceptance and retention of local inputs . . . . . . . . 19
10.1. Request field in PSC protocol message . . . . . . . . . 17 11. State Transition Tables in APS Mode . . . . . . . . . . . . . 19
10.2. Priorities of local inputs and remote requests . . . . . 18 11.1. State transition by local inputs . . . . . . . . . . . . 22
10.3. Acceptance and retention of local inputs . . . . . . . . 20 11.2. State transition by remote messages . . . . . . . . . . 24
11. State Transition Tables in APS Mode . . . . . . . . . . . . . 21
11.1. State transition by local inputs . . . . . . . . . . . . 23
11.2. State transition by remote messages . . . . . . . . . . 25
11.3. State transition for 1+1 unidirectional 11.3. State transition for 1+1 unidirectional
protection . . . . . . . . . . . . . . . . . . . . . . . 27 protection . . . . . . . . . . . . . . . . . . . . . . . 26
12. Provisioning mismatch and protocol failure 12. Provisioning Mismatch and Protocol Failure in the APS Mode . 27
in the APS mode . . . . . . . . . . . . . . . . . . . . . . . 28 13. Security Considerations . . . . . . . . . . . . . . . . . . . 28
13. Security considerations . . . . . . . . . . . . . . . . . . . 28 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
14. IANA considerations . . . . . . . . . . . . . . . . . . . . . 28 14.1. MPLS PSC Request Registry . . . . . . . . . . . . . . . 28
14.1. MPLS PSC Request Registry . . . . . . . . . . . . . . . 29 14.2. MPLS PSC TLV Registry . . . . . . . . . . . . . . . . . 28
14.2. MPLS PSC TLV Registry . . . . . . . . . . . . . . . . . 29 14.3. MPLS PSC Capability Flag Registry . . . . . . . . . . . 28
14.3. MPLS PSC Capability Flag Registry . . . . . . . . . . . 29 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 16.1. Normative References . . . . . . . . . . . . . . . . . . 29
16.1. Normative References . . . . . . . . . . . . . . . . . . 30 16.2. Informative References . . . . . . . . . . . . . . . . . 29
16.2. Informative References . . . . . . . . . . . . . . . . . 30 Appendix A. An Example of Out-of-service Ccenarios . . . . . . . 30
Appendix A. An example of out-of-service scenarios . . . . . . . 31 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 . . . . . 32
Appendix C. Freeze Command . . . . . . . . . . . . . . . . . . . 33 Appendix C. Freeze Command . . . . . . . . . . . . . . . . . . . 33
Appendix D. Operation examples of the APS mode . . . . . . . . . 34 Appendix D. Operation Examples of the APS Mode . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
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 sub-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
skipping to change at page 5, line 13 skipping to change at page 5, line 9
without triggering the actual traffic switching. without 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 of the PSC protocol including
the priority logic and the state machine when all the capabilities the priority logic and the state machine when all the capabilities
associated with the APS mode are enabled. associated with the APS mode are enabled. The PSC protocol behavior
for the PSC mode is as defined in RFC 6378.
This document updates RFC 6378 in that the capability advertisement This document updates RFC 6378 by adding a capability advertisement
method defined here is an addition to that document. For an existing mechanism. It is recommended that existing implementations of RFC
implementation of RFC 6378, it is recommended to be updated with the 6378 should be updated to support this capability. The backward
bug-fixes in [I-D.ietf-mpls-psc-updates] and the capability compatibility with existing implementations is described in
advertisement in this document. 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 [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 LER Label Edge Router
LO Lockout of protection LO Lockout of protection
skipping to change at page 6, line 30 skipping to change at page 6, line 30
RR Reverse Request RR Reverse Request
SD Signal Degrade SD Signal Degrade
SDH Synchronous Digital Hierarchy SDH Synchronous Digital Hierarchy
SD-P Signal Degrade on Protection path SD-P Signal Degrade on Protection path
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
In this document, the priorities of FS and SF-P are swapped and the RFC 6378 [RFC6378] defines the priority of FS to be higher than that
priority of Clear SF (SFc) is raised. In addition to the priority of SF-P. That document also defines the priority of Clear SF (SFc)
modification, this document introduces the use of Freeze command in to be low. This document defines the priority modification
Appendix C. The reasons for these changes are explained in the capability whereby the priorities of FS and SF-P are swapped and the
following sub-sections from technical and network operational priority of Clear SF (SFc) is raised. In addition, this capability
aspects. introduces the use of Freeze command as described in Appendix C. The
reasons for these changes are explained in the following sub-sections
from technical and network operational aspects.
4.1. Motivations for swapping priorities of FS and SF-P 4.1. Motivations 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. situation where the protected traffic is taken out-of-service. When
Setting the priority of any input that is supposed to be signaled to the protection path fails PSC communication may stop as a result. In
the other end to be higher than that of SF-P can result in this case, if any input that is supposed to be signaled to the other
unpredictable protection switching state, when the protection path end has a higher priority than SF-P then this can result in
has failed and consequently the PSC communication stopped. An unpredictable protection switching state. An example of the out-of-
example of the out-of-service scenarios is shown in Appendix A. service scenarios is shown in Appendix A.
According to Section 2.4 of RFC 5654 [RFC5654] it MUST be possible to According to Section 2.4 of RFC 5654 [RFC5654] it MUST be possible to
operate an MPLS-TP network without using a control plane. This means operate an MPLS-TP network without using a control plane. This means
that external switch commands, e.g., FS, can be transferred to the that the PSC communication channel is very important for the transfer
remote Label Edge Router (LER) only by using the PSC communication of external switch commands (e.g., FS), and these commands should not
channel and should not rely on the presence of a control plane. rely on the presence of a control plane. In consequence, the failure
of the PSC communication channel has higher priority than FS.
As the priority of SF-P has been higher than FS in other transport In other transport networks (such as SDH, OTN, and Ethernet transport
networks, such as SDH, OTN and Ethernet transport networks, for networks) the priority of SF-P has been higher than that of FS. It
network operators it is important that the MPLS-TP protection is therefore important to offer network operators the option of
switching preserves the network operation behavior to which network having the same behavior in their MPLS-TP network so that they can
operators have become accustomed. Typically, FS command is issued have the same operational protection switching behavior to which they
before network maintenance jobs, (e.g., replacing optical cables or have become accustomed. Typically, FS command is issued before
other network components). When an operator pulls out a cable on the network maintenance jobs, (e.g., replacing optical cables or other
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 be protected and the
operator expects this behavior based on his/her experience on the operator expects this behavior based on his/her experience on the
traditional transport network operations. 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 [RFC6378] can cause The priority level of SFc defined in RFC 6378 can cause traffic
traffic disruption when a node that has experienced local signal disruption when a node that has experienced local signal fails on
fails on both the working and the protection paths is recovering from both the working and the protection paths is recovering from these
these failures. failures.
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 as defined in RFC 6378 is shown in Appendix B. level of SFc as defined in RFC 6378 is shown 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 the case that network operators need an
option to control their networks so that the traffic can remain on option to control their networks so that the traffic can remain on
the protection path even when the PSC communication channel is the protection path even when the PSC communication channel is
broken, the Freeze command, which is a local command (i.e., not broken, the Freeze command, which is a local command (i.e., not
signaled to the other end) can be used. The use of the Freeze signaled to the other end) can be used. The use of the Freeze
command is described in Appendix C. command is described in Appendix C.
4.4. Modifications to RFC 6378 4.4. Procedures in support of Capability 1
The list of local requests in order of priority SHALL be modified as When this capability is in use the list of local requests in order of
follows: priority SHALL be as follows:
(from higher to lower) (from higher to lower)
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
The change of the PSC Control logic including the state machine due This requires different PSC Control logic (including the state
to this priority modification is incorporated in the PSC Control machine) compared to that described in RFC 6378. Section 10 and
logic description in Section 10 and Section 11 when all the Section 11 show the PSC Control logic when all of the capabilities in
capabilities are enabled. APS mode are enabled.
5. Capability 2: Modification of non-revertive operation 5. Capability 2: Non-revertive Behavior Modification
Non-revertive mode of protection switching is defined in RFC 4427 Non-revertive mode of protection switching is defined in RFC 4427
[RFC4427]. In this mode, the traffic does not return to the working [RFC4427]. In this mode, the traffic does not return to the working
path when switch-over requests are terminated. path when switch-over requests are terminated.
However, PSC protocol defined in RFC 6378 [RFC6378] supports this However, the PSC protocol defined in RFC 6378 [RFC6378] supports this
operation only when recovering from a defect condition, but does not operation only when recovering from a defect condition: it does not
operate as non-revertive when an operator's switch-over command such support the non-revertive function when an operator's switch-over
as FS or Manual Switch (MS) is cleared. To be aligned with legacy command, such as FS or Manual Switch (MS), is cleared. To be aligned
transport network behavior and RFC 4427, a node should go into the with the behavior in other transport networks and to be consistent
Do-not-Revert (DNR) state not only when a failure condition on the with RFC 4427, a node should go into the Do-not-Revert (DNR) state
working path is cleared but also when an operator command requesting not only when a failure condition on the working path is cleared, but
switch-over is cleared. also when an operator command that requested switch-over is cleared.
The change of the PSC Control logic including the state machine due This requires different PSC Control logic (including the state
to the modification of non-revertive operation is incorporated into machine) compared to that described in RFC 6378. Section 10 and
the PSC Control logic description in Section 10 and Section 11 when Section 11 show the PSC Control logic when all of the capabilities in
all the capabilities are enabled. APS 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 introduces necessity of a new Changing the non-revertive operation as described in Section 5
operator command to revert traffic to the working path when in the introduces necessity of a new operator command to revert traffic to
DNR state. When the traffic is on the protection path in the DNR the working path when in the DNR state. When the traffic is on the
state, a Manual Switch to Working (MS-W) command is issued to switch protection path in the DNR state, a Manual Switch to Working (MS-W)
the normal traffic back to working path. According to command is issued to switch the normal traffic back to working path.
Section 4.3.3.6 (Do-not-Revert State) in RFC 6378 [RFC6378], "to According to Section 4.3.3.6 (Do-not-Revert State) in RFC 6378
revert back to Normal state, the administrator SHALL issue a Lockout [RFC6378], "to revert back to Normal state, the administrator SHALL
of protection (LO) command followed by a Clear command." However, issue a Lockout of protection (LO) command followed by a Clear
using LO command introduces the potential risk of an unprotected command." However, using LO command introduces the potential risk of
situation while the LO is in effect. an unprotected situation while the LO is in effect.
Manual Switch-over for recovery LSP/span command, defined in RFC 4427 Manual Switch-over for recovery LSP/span command is defined in RFC
[RFC4427] and also defined in RFC 5654 [RFC5654], Requirement 83, as 4427 [RFC4427]. Requirement 83 in RFC 5654 [RFC5654] states that the
one of the mandatory external commands, should be used for this external commands defined in RFC 4427 must be supported. No such
purpose, but is not included in RFC 6378. Note that the "Manual command is supported in PSC as defined in RFC 6378 so there is a need
Switch-over for recovery LSP/span" command is the same as MS-W to provide support for that feature. Note that the "Manual Switch-
command. over for recovery LSP/span" command is the same as the MS-W command.
6.2. Terms modified to support MS-W 6.2. Terminology to support MS-W
The term "Manual Switch" and its acronym "MS" used in RFC 6378 are RFC 6378 uses the term "Manual Switch" and its acronym "MS". This
replaced respectively by "Manual Switch to Protection path" and document uses the term "Manual Switch to Protection path" and "MS-P"
"MS-P" by this document to avoid confusion with "Manual Switch to to have the same meaning, but avoid confusion with "Manual Switch to
Working path" and its acronym "MS-W". Working path" and its acronym "MS-W".
Also, the term "Protecting administrative state" used in RFC 6378 is Similarly, RFC 6378 uses the term "Protecting administrative state",
replaced by "Switching administrative state" by this document to and this document uses "Switching administrative state" to cover the
include the case where traffic is switched back to the working path same concept but also include the case where traffic is switched back
by administrative MS-W command. to the working path by administrative MS-W command.
6.3. Behavior of MS-P and MS-W 6.3. Behavior of MS-P and MS-W
The MS-P and MS-W commands SHALL have the same priority. If one of If one of the MS-P and MS-W commands is received and processed after
these commands is already issued and accepted, then the other command the other, the two commands SHALL have the same priority such that if
that is issued afterwards SHALL be ignored. If two LERs are one of the commands is already issued and accepted, the command that
requesting opposite operations simultaneously, i.e. one LER is is issued afterwards SHALL be ignored. However, if two Label Edge
sending MS-P while the other LER is sending MS-W, the MS-W SHALL be Routers (LERs) request opposite operations simultaneously (i.e., one
considered to have a higher priority than MS-P, and MS-P SHALL be LER sends MS-P and the other sends MS-W), the MS-W SHALL be
ignored and cancelled. 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 Two commands, MS-P and MS-W are represented by the same Request field
value, but differentiated by the FPath value. When traffic is value, but differentiated by the FPath value. When traffic is
switched to the protection path, the FPath field SHALL indicate that 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 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 Path field SHALL indicate that user data traffic is being transported
on the protection path (i.e., Path set to 1). When traffic is 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 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 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 field SHALL indicate that user data traffic is being transported on
the working path (i.e., Path set to 0). the working path (i.e., Path set to 0).
When an MS command is in effect at an LER, any subsequent MS or EXER
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 RFC 6378 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.
The change of the PSC Control logic including the state machine due Support of this function requires changes to the PSC Control logic
to the support of MS-W command is incorporated into the PSC Control (including the state machine) compared to that shown in RFC 6378.
logic description in Section 10 and Section 11 when all the Section 10 and Section 11 show the PSC Control logic when all of the
capabilities are enabled capabilities in 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 MPLS-TP survivability framework [RFC6372], fault conditions
include both SF and SD that can be used to trigger protection include both SF and SD that can be used to trigger protection
switching. switching.
RFC 6378 [RFC6378], which defines the protection switching protocol RFC 6378 [RFC6378], which defines the protection switching protocol
for MPLS-TP does not specify how the SF and SD are detected, and for MPLS-TP does not specify how the SF and SD are detected, and
specifies the protection switching protocol associated with SF only. specifies the protection switching protocol associated with SF only.
The PSC protocol associated with SD is covered in this document, and 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 the scope of
the protection protocol similar to the facts that how SF is detect the protection protocol similar to the facts that how SF is detect
and how MS and FS commands are initiated in a management system and and how MS and FS commands are initiated in a management system and
signaled to protection switching are out of its scope. signaled to protection switching are out of its scope.
7.2. Terms modified to support SD 7.2. Terminology to support SD
Instead of SFc, Clear Signal Fail or Degrade (SFDc) is used to In this document the term Clear Signal Fail or Degrade (SFDc) is used
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 RFC 6378
shows the intention of including Signal Degrade on Protection path shows the intention of including Signal Degrade on Protection path
(SD-P) in the Unavailable state. Even though the protection path can (SD-P) in the Unavailable state. Even though the protection path can
be partially available under the condition of SD-P, this document be partially available under the condition of SD-P, this document
follows the same state grouping as RFC 6378 for SD-P. follows the same state grouping as RFC 6378 for SD-P.
The bullet item "Protecting failure state" in Section 3.6 in RFC 6378 The bullet item "Protecting failure state" in Section 3.6 in RFC 6378
includes the degraded condition in Protecting failure state. This includes the degraded condition in Protecting failure state. This
document follows the same state grouping as RFC 6378 for Signal document follows the same state grouping as RFC 6378 for Signal
Degrade on Working path (SD-W). Degrade on Working path (SD-W).
7.3. Behavior of protection against SD 7.3. Behavior of protection against SD
In order to maintain the network operation behavior to which In order to make the behavior of MPLS-TP networks consistent with
transport network operators have become accustomed, the priorities of that of other transport networks (such as SDH, OTN and Ethernet
SD-P and SD-W are defined to be equal as in other transport networks, transport networks), the priorities of SD-P and SD-W are defined to
such as SDH, OTN and Ethernet transport networks. Once a switch has be equal. Once a switch has been completed due to SD on one path, it
been completed due to SD on one path, it will not be overridden by SD will not be overridden by SD on the other path (first come, first
on the other path (first come, first served behavior), to avoid served behavior), to avoid protection switching that cannot improve
protection switching that cannot improve signal quality. signal quality.
SD indicates that the transmitting end point has identified a SD indicates that the transmitting end point 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 degrade 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 The Wait-to-Restore (WTR) timer is used when the protected domain is
configured for revertive behavior and started at the node that configured for revertive behavior and started at the node that
recovers from a local degraded condition on the working path. 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 LER 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, and SHALL stop when there is no SD condition.
Additionally, the packet duplication SHALL continue in the WTR state Additionally, the packet duplication SHALL continue in the WTR state
in revertive mode. In non-revertive mode, the packet duplication in revertive mode. In non-revertive mode, the packet duplication
SHALL stop when there is no SD condition. SHALL stop when there is no SD condition.
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
to the operation of the selector at the sink LER described in RFC
6378. The selector chooses either the working or protection 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
receive the traffic, is determined by the PSC protocol in
bidirectional switching or by the local input in unidirectional
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 manual switch behavior described in
Section 6.3 and the protection against Signal Degrade described in Section 6.3 and the protection against Signal Degrade described in
Section 7.3, the rules to resolve the equal priority requests are Section 7.3, the rules to resolve the equal priority requests are
required. required.
For the equal priority local inputs, such as MS and SD, first-come, For the equal priority local inputs, such as MS and SD, first-come,
first-served rule is applied. Once a local input is determined as first-served rule is applied. 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 the LER 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
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 If the LER is in remote Switching administrative state due to a
remote MS-P, then subsequent local MS-W SHALL be ignored and remote MS-P, then subsequent local MS-W SHALL be ignored and
skipping to change at page 12, line 24 skipping to change at page 12, line 43
There is a case where one LER receives a local input and the other There is a case where one LER receives a local input and the other
LER receives, simultaneously, a local input with the same priority LER receives, simultaneously, a local input with the same priority
but requesting different action. In this case, each of the two LERs but requesting different action. In this case, each of the two LERs
receives a subsequent remote message having the same priority but receives a subsequent remote message having the same priority but
requesting different action, while the LER is in a local state due to requesting different action, while the LER is in a local state due to
the local input. When this case happens, a priority must be set for the local input. When this case happens, a priority must be set for
the inputs with the same priority regardless of its origin (local the inputs with the same priority regardless of its origin (local
input or remote message). input or remote message).
When MS-W and MS-P occur simultaneously at both LERs, MS-W SHALL be o When MS-W and MS-P occur simultaneously at both LERs, MS-W SHALL
considered as having higher priority than MS-P at both LERs. be considered as having higher priority than MS-P at both LERs.
When SD-W and SD-P occur simultaneously at both LERs, the SD on the o When SD-W and SD-P occur simultaneously at both LERs, the SD on
standby path (the path from which the selector does not select the the standby path (the path from which the selector does not select
user data traffic) is considered as having higher priority than the the user data traffic) is considered as having higher priority
SD on the active path (the path from which the selector selects the than the SD on the active path (the path from which the selector
user data traffic) regardless of its origin (local or remote selects the user data traffic) regardless of its origin (local or
message). Therefore, no unnecessary protection switching is remote message). Therefore, no unnecessary protection switching
performed and the user data traffic continues to be selected from the is performed and the user data traffic continues to be selected
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 data path (Path) field than the value of the
Path field in the transmitted SD (or MS) message, both the local and Path field in the transmitted SD (or MS) message, both the local and
the remote SD requests are considered to occur simultaneously. the remote SD requests are considered to occur simultaneously.
The change of the PSC Control logic including the state machine due The addition of support for protection against SD requires different
to the support of protection against SD is incorporated into the PSC PSC Control logic (including the state machine) compared to that
Control logic description in Section 10 and Section 11 when all the shown in RFC 6378. Section 10 and Section 11 show the PSC Control
capabilities are enabled. logic when all of the capabilities in 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 EXER is a command to test if the PSC communication is operating
correctly. More specifically, EXER is to test and validate the correctly. More specifically, EXER is to test and validate the
linear protection mechanism and PSC protocol including the aliveness linear protection mechanism and PSC protocol including the aliveness
of the Local Request logic, the PSC state machine and the PSC message of the Local Request logic, the PSC state machine and the PSC message
generation and reception, and the integrity of the protection path, generation and reception, and the integrity of the protection path,
without triggering the actual traffic switching. It is used while without triggering the actual traffic switching. It is used while
the working path is either carrying the traffic or not. It has lower the working path is either carrying the traffic or not. It has lower
priority than any "real" switch request. It is only valid in priority than any "real" switch request. It is only valid in
bidirectional switching, since this is the only place where one can bidirectional switching, since this is the only place where one can
skipping to change at page 13, line 30 skipping to change at page 13, line 45
A received EXER message indicates that the remote end point is A received EXER message indicates that the remote end point is
operating under an operator command to validate the protection operating under an operator command to validate the protection
mechanism and PSC protocol including the aliveness of the Local mechanism and PSC protocol including the aliveness of the Local
Request logic, the PSC state machine and the PSC message generation Request logic, the PSC state machine and the PSC message generation
and reception, and the integrity of the protection path, without and reception, and the integrity of the protection path, without
triggering the actual traffic switching. The valid response to EXER triggering the actual traffic switching. The valid response to EXER
message is an Reverse Request (RR) with the corresponding FPath and 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 Path numbers. The local LER SHALL signal a RR only in response to an
EXER command from the remote LER. EXER command from the remote LER.
When Exercise commands are input at both ends, an EXER, instead of If EXER commands are input at both ends, then a race condition may
RR, SHALL be transmitted from both ends. arise. This is resolved as follows:
The following PSC Requests SHALL be added to PSC Request field to o If an LER has issued EXER and receives EXER before receiving RR,
support Exercise: it
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
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 LER. FPath and Path
are set to the same value of the NR or DNR request that RR are set to the same value of the NR or DNR request that RR
replaces. replaces.
The priority of Exercise SHALL be inserted between the priorities of The relative priorities of EXER and RR are shown in Section 10.2.
WTR Expires and No Request.
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 RFC 6378 [RFC6378]. The format of
the Capabilities TLV is: the 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
skipping to change at page 15, line 4 skipping to change at page 15, line 22
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 from 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, an LER SHALL set
0xF8000000 in the Flags field. 0xF8000000 in the Flags field.
9.1.1. Sending the Capabilities TLV 9.1.1. Sending and receiving the Capabilities TLV
PSC sends messages in response to external events and in periodic
retransmission of current status. It may be expensive to send and to
parse an Capabilities TLV attached to a packet intended to trigger a
protection switch or other real-time behavior. However, if a node
does not periodically send its Capabilities TLV, the receiving node
cannot discriminate a deliberate omission of the Capabilities TLV for
performance reasons from an accidental omission due to an
implementation issue. To guard against this, a node MUST include its
Capabilities TLV in every PSC message that it sends.
9.1.2. Receiving the Capabilities TLV
A node MUST establish a receive timer for the Capabilities TLV. By A node MUST include its Capabilities TLV in every PSC message that it
default this MUST be 3.5 times the periodic retransmission timer of sends. The transmission and acceptance of the PSC message is
five seconds - i.e., 17.5 seconds. Both the periodic retransmission described in Section 4.1 of RFC 6378.
time and the timeout SHOULD be configurable by the operator. When a
node receives a Capabilities TLV it resets the timer to 17.5 seconds.
If the timer expires, the node behaves as in Section 9.1.3.
When a node receives a Capabilities TLV it MUST compare it to its When a node receives a Capabilities TLV it MUST compare it to its
most recent transmitted Capabilities TLV. If the two are equal, the most recent transmitted Capabilities TLV. If the two are equal, the
protected domain is said to be running in the mode indicated by that protected domain is said to be running in the mode indicated by that
set of capabilities (see Section 9.2). If the sent and received set of capabilities (see Section 9.2). If the sent and received
Capabilities TLVs are not equal, this indicates a capabilities Capabilities TLVs are not equal, this indicates a capabilities
mismatch. When this happens, the node MUST alert the operator and mismatch. When this happens, the node MUST alert the operator and
MUST behave as in Section 9.1.3. MUST NOT perform any protection switching until the operator resolves
the mismatch in the Capabilities TLV.
9.1.3. Handling Capabilities TLV errors
This section covers the two possible errors - a TLV timeout and a TLV
mismatch - and the error handling procedures in both cases.
9.1.3.1. Capabilities TLV Timeout
If the Capabilities TLV receive timer expires and there is no defect
on the protection path, the node MUST alert the operator and MUST
behave as in Section 9.1.3.3.
9.1.3.2. Capabilities TLV Mismatch
If the sent and received Capabilities TLVs are not equal, this
indicates a capabilities mismatch. When this happens, the node MUST
alert the operator and MUST behave as in Section 9.1.3.3. A node MAY
retain the received TLV for logging, alert or debug purposes.
9.1.3.3. Handling Capabilities TLV error conditions
When a node enters in Capabilities protocol error conditions, the
following actions MUST be taken:
1. Indicate the error condition (e.g., either mismatch or timeout)
to the operator by the usual alert mechanisms (e.g., syslog).
2. Not make any state transitions based on the contents of any PSC
messages
To expand on point 2 - assume node A is receiving NR(0,0) from its
PSC peer node Z and is also receiving a mismatched set of
capabilities (e.g., received 0x20000000, transmitted 0xA0000000). If
node Z detects a local SF-W and wants to initiate a protection switch
(that is, by sending SF(1,1)), node A MUST NOT react to this input by
changing its state. A node MAY increase the severity or urgency of
its alarms to the operator, but until the operator resolves the
mismatch in the Capabilities TLV the protected domain will likely
operate in an inconsistent state.
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 any Capabilities - that is, a
Capabilities set of 0x0. It is the behavior specified in RFC 6378. Capabilities set of 0x0. It is the behavior specified in RFC 6378.
There are two ways to declare PSC Mode. A node can send a
Capabilities TLV of 0x0, or it can send no Capabilities TLV at all.
This is further explored in Section 9.3.
9.2.2. APS Mode
APS Mode is defined as the use of all the five specific capabilities, There are two ways to declare PSC mode. A node can send no
which are described from Section 4 to Section 8 in this document. Capabilities TLV at all since there are no TLV units defined in RFC
APS Mode is indicated with the Flags value of 0xF8000000. 6378, or it can send a Capabilities TLV with Flags value set to 0x0.
In order to allow backward compatibility between two nodes - one
9.3. Backward compatibility which can send the Capabilities TLV, and one which cannot, a node
which has the ability to send and receive the PSC mode Capabilities
As defined in Section 9.2.1, PSC Mode is indicated either with a TLV MUST be able to both send the PSC mode Capabilities TLV and send
Capabilities TLV of 0x0 or the lack of Capabilities TLV. This is to no Capabilities TLV at all. An implementation MUST be configurable
allow backward compatibility between two nodes - one which can send between these two choices.
the Capabilities TLV, and one which cannot.
RFC 6378 does not define how to handle an unrecognized TLV. There
may be some implementations that silently discard an unrecognized
TLV, and some that take more drastic steps like refusing to allow PSC
to operate. Thus, a node which has the ability to send and receive
the PSC Mode Capabilities TLV MUST be able to both send the PSC Mode
Capabilities TLV and send no Capabilities TLV at all. An
implementation MUST be configurable between these two choices.
One question that arises from this dual definition of PSC Mode is,
what happens if a node which was sending a non-null Capabilities TLV
(e.g., APS Mode) sends PSC packets without any Capabilities TLV?
This case is handled as follows:
If a node has never, during the life of a PSC session, received a 9.2.2. APS mode
Capabilities TLV from its peer, the lack of a Capabilities TLV is
treated as receipt of a PSC Capabilities TLV. This allows for
interoperability between nodes which support the PSC Mode TLV and
nodes which do not, and are thus implicitly operating in PSC Mode.
If a node has received a non-null Capabilities TLV (e.g., APS Mode) APS mode is defined as the use of all the five specific capabilities,
during the life of a PSC session and then receives a PSC packet with which are described from Section 4 to Section 8 in this document.
no Capabilities TLV, the receiving node MUST treat the lack of APS mode is indicated with the Flags value of 0xF8000000.
Capabilities TLV as simply a lack of refresh. That is, the receipt
of a PSC packet with no Capabilities TLV simply does not reset the
receive timer defined in Section 9.1.2.
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 Section 11 define the behavior of PSC protocol when
all of the aforementioned capabilities are enabled, i.e., APS mode. 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
The values of "Request" field in PSC protocol message, which is shown This document defines two new values for the "Request" field in the
in Figure 2 of RFC 6378 [RFC6378], are redefined as follows: PSC protocol message that is shown in Figure 2 of RFC 6378 [RFC6378]
as follows:
(14) Lockout of protection
(12) Forced Switch
(10) Signal Fail
(7) Signal Degrade
(5) Manual Switch
(4) Wait-to-Restore
(3) Exercise (3) Exercise
(2) Reverse Request (2) Reverse Request
(1) Do-not-Revert See also Section 14.1 of this document.
(0) No Request
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 Section 3 and Section 4.3.2 in RFC 6378,
the priorities of multiple outstanding local inputs are evaluated in the priorities of multiple outstanding local inputs are evaluated in
the Local Request logic, where the highest priority local input the Local Request logic, where the highest priority local input
(highest local request) is determined. This highest local request is (highest local request) is determined. This highest local request is
passed to the PSC Control logic, that will determine the higher passed to the PSC Control logic, that will determine the higher
priority input (top priority global request) between the highest priority input (top priority global request) between the highest
local request and the last received remote message. When a remote local request and the last received remote message. When a remote
message comes to the PSC Control logic, the top priority global message comes to the PSC Control logic, the top priority global
request is determined between this remote message and the highest request is determined between this remote message and the highest
local request which is present. The top priority global request is local request which is present. The top priority global request is
used to determine the state transition, which is described in used to determine the state transition, which is described in
Section 11. Section 11. In this document, in order to simplify the description
on the PSC Control logic, we strictly decouple the priority
evaluation from the state 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)
skipping to change at page 19, line 8 skipping to change at page 17, line 35
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 Expires (Local only) o WTR Timer Expires (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)
skipping to change at page 19, line 39 skipping to change at page 18, line 19
requests, such as SD and MS, the following equal priority resolution requests, such as SD and MS, the following equal priority resolution
rules are defined: rules are defined:
o If two local inputs having the same priority but requesting o If two local inputs having the same priority but requesting
different action come to the Local Request logic, then the input different action come to the Local Request logic, then the input
coming first SHALL be considered to have a higher priority than coming first SHALL be considered to have a higher priority than
the other coming later (first-come, first-served). the other coming later (first-come, first-served).
o If the PSC Control logic has both the highest local request and a o If the PSC Control logic has both the highest local request and a
remote message with the same priority and requesting the same remote message with the same priority and requesting the same
action, i.e., the same PSC Request Field and the same FPath value, 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 then the local input SHALL be considered to have a higher priority
than the remote message. than the remote message.
o If the PSC Control logic has both the highest local request and a o If the PSC Control logic has both the highest local request and a
remote message with the same priority but requesting different remote message with the same priority but requesting different
action and the remote message exists when the highest local action and the remote message exists when the highest local
request comes to the PSC Control logic, the highest local request request comes to the PSC Control logic, the highest local request
is ignored and the remote Request SHALL be the top priority global is ignored and the remote Request SHALL be the top priority global
request. request.
skipping to change at page 20, line 48 skipping to change at page 19, line 29
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
disappears, the local defect will become the highest local request if disappears, 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 Expires are not persistent. Operator Clear command, SFDc and WTR Timer Expires are not
Once they appear to the Local Request logic and complete the persistent. Once they appear to the Local Request logic and complete
operation, they SHALL be disappeared. the operation, they SHALL be disappeared.
Operator LO, FS, MS, and EXER commands SHALL be rejected if there is Operator LO, FS, MS, and EXER commands SHALL be rejected if there is
any higher priority local input in the Local Request logic. If a new any higher priority local input in the Local Request logic. If a new
operator command is accepted, any previous lower-priority local higher-priority local request (including an operator command) is
operator command SHALL be cancelled. When any higher priority remote accepted, any previous lower-priority local operator command SHALL be
request is received, a lower-priority local operator command SHALL be cancelled. When any higher-priority remote request is received, a
cancelled. The cancelled operator command is forgotten and will lower-priority local operator command SHALL be cancelled. The
never return, unless the operator reissues the command. cancelled operator command is forgotten and will never return, unless
the operator reissues 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 LER. Otherwise, remote messages state transition
table in Section 11.2 SHALL be used. table 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 field
and Fpath. and Fpath.
o For the LER currently in the local state, if the top priority o For the LER currently in the local state, if the top priority
global request is changed to OC or SFDc causing the next state to global request is changed to Operator Clear (OC) or SFDc causing
be Normal, WTR or DNR, then all the local and remote requests the next state to be Normal, WTR or DNR, then all the local and
should be re-evaluated as if the LER is in the state specified in remote requests SHALL be re-evaluated as if the LER is in the
the footnotes to the state transition tables, before deciding the state specified in the footnotes to the state transition tables,
final state. This re-evaluation is an internal operation confined before deciding the final state. If there are no active requests,
within the local LER, and PSC messages are generated according to the LER enters the state specified in the footnotes to the state
the final state. transition tables. This re-evaluation is an internal operation
confined within the local LER, and the PSC messages are generated
according to the final state.
o The WTR timer is started only when the LER which has recovered o The WTR timer is started only when the LER which has recovered
from a local failure/degradation enters the WTR state. An LER from a local failure/degradation enters the WTR state. An LER
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 is stopped when any does not start the WTR timer. The WTR timer SHALL be stopped when
local or remote request triggers the state change out of the WTR any local or remote request triggers the state change out of the
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
skipping to change at page 23, line 31 skipping to change at page 22, line 31
SA:F:R highest local request(local FPath,1) SA:F:R highest local request(local FPath,1)
SA:MW:R NR(0,0) SA:MW:R NR(0,0)
SA:MP:R NR(0,1) SA:MP:R NR(0,1)
WTR WTR(0,1) WTR WTR(0,1)
DNR DNR(0,1) DNR DNR(0,1)
E::L EXER(0,x), where x is the existing Path value E::L EXER(0,x), where x is the existing Path value
when Exercise command is issued. when Exercise command is issued.
E::R RR(0,x), where x is the existing Path value E::R RR(0,x), where x is the existing Path value
when RR message is generated. when RR message is generated.
Some operation examples of the APS mode are shown in Appendix D. Some operation examples of APS mode are shown in Appendix D.
In the state transition tables below, the letter 'i' stands for
"ignore", and is an indication to remain in the current state and
continue transmitting the current PSC message
11.1. State transition by local inputs 11.1. State transition by local inputs
| OC | LO | SFDc | SF-P | FS | SF-W | | OC | LO | SFDc | SF-P | FS | SF-W |
--------+-----+---------+------+--------+--------+--------+ --------+-----+---------+------+--------+--------+--------+
N | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L | N | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
UA:LO:L | (1) | i | i | i | i | i | UA:LO:L | (1) | i | i | i | i | i |
UA:P:L | i | UA:LO:L | (1) | i | i | i | UA:P:L | i | UA:LO:L | (1) | i | i | i |
UA:DP:L | i | UA:LO:L | (1) | UA:P:L | SA:F:L | PF:W:L | UA:DP:L | i | UA:LO:L | (1) | UA:P:L | SA:F:L | PF:W:L |
UA:LO:R | i | UA:LO:L | i | UA:P:L | i | PF:W:L | UA:LO:R | i | UA:LO:L | i | UA:P:L | i | PF:W:L |
UA:P:R | i | UA:LO:L | i | UA:P:L | i | PF:W:L | UA:P:R | i | UA:LO:L | i | UA:P:L | i | PF:W:L |
skipping to change at page 25, line 7 skipping to change at page 24, line 7
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 LER is in the
Normal state. Normal state. If there are no active requests, the LER enters
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 LER enters into the
WTR state when the domain is configured for revertive behavior, WTR state when the domain is configured for revertive behavior,
or the LER enters into the DNR state when the domain is or the LER enters into the DNR state when the domain is
configured for non-revertive behavior. In all the other cases, configured for non-revertive behavior. In all the other cases,
re-evaluate to determine the final state as if the LER is in the where one or more active requests exist, re-evaluate to
Normal state. determine the final state as if the LER 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 LER 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 LER is in the DNR state when the domain
is configured for non-revertive behavior, is configured for non-revertive behavior. If there are no
active requests, the LER enters either the Normal state when the
domain is configured for revertive behavior or the DNR state
when the domain is configured for non-revertive behavior.
(4) Remain in WTR and send NR(0,1). Stop the WTR timer if it is (4) Remain in the WTR state and send NR(0,1). Stop the WTR timer if
running. it is running. In APS mode, OC can cancel the WTR timer and
hasten the state transition to the Normal state as in other
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 LER is in the Normal state. If Path value is 1, re-evaluate
to determine final state as if the LER is in the DNR state. to determine final state as if the LER is in the DNR state. If
there are no active requests, the LER enters the Normal state
when Path value is 0, or the DNR state when Path value is 1.
(6) Remain in WTR 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) |
UA:LO:R | i | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | UA:LO:R | i | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
UA:P:R | UA:LO:R | i | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | UA:P:R | UA:LO:R | i | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
skipping to change at page 27, line 14 skipping to change at page 26, line 14
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 PF:DW:R state and
transmit SD(0,1) 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 UA:DP:R state and
transmit SD(1,0). transmit SD(1,0).
(9) Transition to 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 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 WTR if (11) If the received NR message has Path=1, transition to the WTR
domain configured for revertive behavior, else transition to state if domain configured for revertive behavior, else
DNR. If the received NR message has Path=0, transition to N. transition to the DNR state. If the received NR message has
Path=0, transition to the Normal state.
(12) If the receiving LER's WTR timer is running, maintain current (12) If the receiving LER'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 N. to the Normal state.
(13) Transit to WTR state and send NR(0,1) message. The WTR timer is (13) Transit to the WTR state and send NR(0,1) message. The WTR
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 Section 11.1 and Section 11.2
are for bidirectional protection switching, where remote PSC protocol are for 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. The
1+1 unidirectional protection switching does not require the remote 1+1 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 the 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 o Replace footnote (4) with "Stop the WTR timer and transit to the
Normal state." Normal state."
o Replace footnote (6) with "Transit to Normal state." o Replace footnote (6) with "Transit to the Normal state."
o Exercise is not applicable. o Exercise is not applicable.
12. Provisioning mismatch and protocol failure in the APS mode 12. Provisioning Mismatch and Protocol Failure in the APS Mode
The remote PSC message that is received from the remote LER is The remote PSC message that is received from the remote LER 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 the APS mode, provisioning mismatches are
handled as follows: handled 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.
o If the "Protection Type (PT)" field mismatches and two sides are o In the case that the mismatch happens in two-bit "Protection Type
unable to converge as described in Section 5.1 in (PT)" field, which indicates permanent/selector bridge type and
[I-D.ietf-mpls-psc-updates], the node MUST alert the operator and uni/bidirectional switching type,
MUST NOT perform any protection switching.
* If the value of the PT field of one side is 2 (i.e., selector
bridge) and the value of PT field of the other side is 1 or 3
(i.e., permanent bridge), then this event MUST be notified to
the operator and each node MUST NOT perform any protection
switching until the operator resolves this bridge type
mismatch.
* If the bridge type matches but the switching type mismatches,
i.e., one side has PT=1 (unidirectional switching) while the
other side has PT=2 or 3 (bidirectional switching), then the
node provisioned for bidirectional switching SHOULD fall back
to unidirectional switching to allow interworking. The node
SHOULD notify the operator of this event.
o If the "Revertive (R)" bit mismatches, two sides will interwork o If the "Revertive (R)" bit mismatches, two sides will interwork
and traffic is protected in the APS mode. The node MAY notify the and traffic is protected according to the state transition
definition given in Section 11. The node SHOULD notify the
operator of this event. operator of this event.
o If the Capabilities TLV mismatches, the node MUST alert the o If the Capabilities TLV mismatches, the node MUST alert the
operator and MUST NOT perform any protection switching. operator and MUST NOT perform any protection switching until the
operator resolves the mismatch in the Capabilities TLV.
The followings are the protocol failure situations and the actions to The followings are the protocol failure situations and the actions to
be taken: be taken:
o No match in sent "Data Path (Path)" and received "Data Path o No match in sent "Data Path (Path)" and received "Data Path
(Path)" for more than 50 ms: The node MAY continue to perform (Path)" for more than 50 ms: The node MAY continue to perform
protection switching and SHOULD notify the operator of these protection switching and SHOULD notify the operator of this event.
events:
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) and there is no defect on the protection path (The seconds with a default message interval of 5 seconds) and there is
Capabilities TLV Timeout error specifies in Section 9.1.3 is no defect on the protection path: The node MUST alert the operator
included in this situation.): The node MUST alert the operator and and MUST NOT perform any protection switching until the operator
MUST NOT perform any protection switching. resolves this defect.
13. Security considerations 13. Security Considerations
No specific security issue is raised in addition to those ones No specific security issue is raised in addition to those ones
already documented in RFC 6378 [RFC6378] already documented in RFC 6378 [RFC6378]
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 "Multiprotocol Label Switching (MPLS) Operations,
Administration, and Management (OAM) 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
skipping to change at page 30, line 16 skipping to change at page 29, line 21
---- ---------- ----------------------------------- --------------- ---- ---------- ----------------------------------- ---------------
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,
Malcolm Betts, Ross Callon and Qin Wu for their valuable comments and
suggestions on this document.
We would also like to acknowledge explicit text provided by Loa
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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile", and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009. RFC 5654, September 2009.
[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.
[I-D.ietf-mpls-psc-updates]
Osborne, E., "Updates to PSC", draft-ietf-mpls-psc-
updates-00 (work in progress), October 2013.
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.
[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
skipping to change at page 31, line 13 skipping to change at page 30, line 20
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 scenarios Appendix A. An Example of Out-of-service Ccenarios
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 RFC 6378. The first
PSC message which differs from the previous PSC message is shown. 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) ---|
| | | |
skipping to change at page 32, line 16 skipping to change at page 31, line 26
unidirectional SF-P. Because no valid PSC message is received, over unidirectional SF-P. Because no valid PSC message is received, over
a period of several successive message intervals, the last valid a period of several successive message intervals, the last valid
received message remains applicable and the node A continue to received message remains applicable and the node A continue to
transmit an NR(0,1) message in the PA:F:R state. transmit an NR(0,1) message in the PA:F:R state.
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 RFC 6378 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
| | | |
skipping to change at page 34, line 9 skipping to change at page 33, line 32
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 fields remain unchanged from the initial configuration. other fields remain unchanged from the initial configuration.
W(A->Z) and P(A->Z) indicate the working path and the protection path W(A->Z) and P(A->Z) indicate the working path and the protection path
 End of changes. 106 change blocks. 
358 lines changed or deleted 324 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/