draft-ietf-mpls-tp-psc-itu-03.txt   draft-ietf-mpls-tp-psc-itu-04.txt 
MPLS Working Group J. Ryoo, Ed. MPLS Working Group J. Ryoo, Ed.
Internet-Draft ETRI Internet-Draft ETRI
Updates: 6378 (if approved) E. Gray, Ed. Updates: 6378 (if approved) E. Gray, Ed.
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: August 28, 2014 H. van Helvoort Expires: September 29, 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.
February 24, 2014 March 28, 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-03.txt draft-ietf-mpls-tp-psc-itu-04.txt
Abstract Abstract
This document describes alternate mechanisms to perform some of the This document describes alternate mechanisms to perform some of the
functions of MPLS Transport Profile (MPLS-TP) linear protection functions of MPLS Transport Profile (MPLS-TP) linear protection
defined in RFC 6378, and also defines additional mechanisms. The defined in RFC 6378, and also defines additional mechanisms. The
purpose of these alternate and additional mechanisms is to provide purpose of these alternate and additional mechanisms is to provide
operator control and experience that more closely models the behavior operator control and experience that more closely models the behavior
of linear protection seen in other transport networks. of linear protection seen in other transport networks.
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 28, 2014. This Internet-Draft will expire on September 29, 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 39 skipping to change at page 2, line 39
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. Motivation for swapping priorities of FS and SF-P . . . . 6 4.1. Motivation for swapping priorities of FS and SF-P . . . . 6
4.2. Motivation for raising the priority of SFc . . . . . . . 6 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. Procedures in support of Capability 1 . . . . . . . . . . 7 4.4. Procedures in support of priority modification . . . . . 7
5. Capability 2: Non-revertive Behavior Modification . . . . . . 7 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. Terminology to support MS-W . . . . . . . . . . . . . . . 8 6.2. Terminology to support MS-W . . . . . . . . . . . . . . . 9
6.3. Behavior of MS-P and MS-W . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . 10
7. Capability 4: Support of Protection against SD . . . . . . . 9 7. Capability 4: Support of Protection against SD . . . . . . . 10
7.1. Motivation for supporting protection against SD . . . . . 9 7.1. Motivation for supporting protection against SD . . . . . 10
7.2. Terminology 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 . . . . . . . . . . . . . . . . . . . 13 9. Capabilities and Modes . . . . . . . . . . . . . . . . . . . 14
9.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 14
9.1.1. Sending and receiving the Capabilities TLV . . . . . 15 9.1.1. Sending and receiving the Capabilities TLV . . . . . 15
9.2. Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.2. Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.2.1. PSC mode . . . . . . . . . . . . . . . . . . . . . . 15 9.2.1. PSC mode . . . . . . . . . . . . . . . . . . . . . . 16
9.2.2. APS mode . . . . . . . . . . . . . . . . . . . . . . 16 9.2.2. APS mode . . . . . . . . . . . . . . . . . . . . . . 16
10. PSC Protocol in APS Mode . . . . . . . . . . . . . . . . . . 16 10. PSC Protocol in APS Mode . . . . . . . . . . . . . . . . . . 16
10.1. Request field in PSC protocol message . . . . . . . . . 16 10.1. Request field in PSC protocol message . . . . . . . . . 16
10.2. Priorities of local inputs and remote requests . . . . . 16 10.2. Priorities of local inputs and remote requests . . . . . 17
10.2.1. Equal priority requests . . . . . . . . . . . . . . 18 10.2.1. Equal priority requests . . . . . . . . . . . . . . 18
10.3. Acceptance and retention of local inputs . . . . . . . . 19 10.3. Acceptance and retention of local inputs . . . . . . . . 19
11. State Transition Tables in APS Mode . . . . . . . . . . . . . 19 11. State Transition Tables in APS Mode . . . . . . . . . . . . . 20
11.1. State transition by local inputs . . . . . . . . . . . . 21 11.1. State transition by local inputs . . . . . . . . . . . . 22
11.2. State transition by remote messages . . . . . . . . . . 23 11.2. State transition by remote messages . . . . . . . . . . 24
11.3. State transition for 1+1 unidirectional 11.3. State transition for 1+1 unidirectional
protection . . . . . . . . . . . . . . . . . . . . . . . 25 protection . . . . . . . . . . . . . . . . . . . . . . . 26
12. Provisioning Mismatch and Protocol Failure in APS Mode . . . 26 12. Provisioning Mismatch and Protocol Failure in APS Mode . . . 27
13. Security Considerations . . . . . . . . . . . . . . . . . . . 27 13. Security Considerations . . . . . . . . . . . . . . . . . . . 28
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
14.1. MPLS PSC Request Registry . . . . . . . . . . . . . . . 27 14.1. MPLS PSC Request Registry . . . . . . . . . . . . . . . 28
14.2. MPLS PSC TLV Registry . . . . . . . . . . . . . . . . . 27 14.2. MPLS PSC TLV Registry . . . . . . . . . . . . . . . . . 28
14.3. MPLS PSC Capability Flag Registry . . . . . . . . . . . 27 14.3. MPLS PSC Capability Flag Registry . . . . . . . . . . . 28
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
16.1. Normative References . . . . . . . . . . . . . . . . . . 28 16.1. Normative References . . . . . . . . . . . . . . . . . . 29
16.2. Informative References . . . . . . . . . . . . . . . . . 28 16.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. An Example of Out-of-service Scenarios . . . . . . . 29 Appendix A. An Example of Out-of-service Scenarios . . . . . . . 30
Appendix B. An Example of Sequence Diagram Showing Appendix B. An Example of Sequence Diagram Showing
the Problem with the Priority Level of SFc . . . . . 30 the Problem with the Priority Level of SFc . . . . . 31
Appendix C. Freeze Command . . . . . . . . . . . . . . . . . . . 32 Appendix C. Freeze Command . . . . . . . . . . . . . . . . . . . 33
Appendix D. Operation Examples of the APS Mode . . . . . . . . . 32 Appendix D. Operation Examples of the APS Mode . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 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
functions of linear protection, and also defines additional functions of linear protection, and also defines additional
mechanisms. The purpose of these alternate and additional mechanisms mechanisms. The purpose of these alternate and additional mechanisms
skipping to change at page 5, line 7 skipping to change at page 5, line 7
logic, the PSC state machine and the PSC message generation and logic, the PSC state machine and the PSC message generation and
reception, and the integrity of the protection path, without reception, and the integrity of the protection path, without
triggering the actual traffic switching. triggering the actual traffic switching.
This document introduces capabilities and modes. A capability is an This document introduces capabilities and modes. A capability is an
individual behavior. The capabilities of a node are advertised using individual behavior. The capabilities of a node are advertised using
the method given in this document. A mode is a particular the method given in this document. A mode is a particular
combination of capabilities. Two modes are defined in this document: combination of capabilities. Two modes are defined in this document:
PSC mode and Automatic Protection Switching (APS) mode. PSC mode and Automatic Protection Switching (APS) mode.
Other modes may be defined as new combinations of the capabilities
defined in this document or through the definition of additional
capabilities. In either case, the specification defining a new mode
will be responsible for documenting the behavior, the priority logic,
and the state machine of the PSC protocol when the set of
capabilities in the new mode are enabled.
This document describes the behavior, the priority logic, and the This document describes the behavior, the priority logic, and the
state machine of the PSC protocol when all the capabilities state machine of the PSC protocol when all the capabilities
associated with the APS mode are enabled. The PSC protocol behavior associated with the APS mode are enabled. The PSC protocol behavior
for the PSC mode is as defined in [RFC6378]. for the PSC mode is as defined in [RFC6378].
This document updates [RFC6378] by adding a capability advertisement This document updates [RFC6378] by adding a capability advertisement
mechanism. It is recommended that existing implementations of the mechanism. It is recommended that existing implementations of the
PSC protocol be updated to support this capability. Backward PSC protocol be updated to support this capability. Backward
compatibility with existing implementations is described in compatibility with existing implementations that do not support this
Section 9.2.1. mechanism is described in Section 9.2.1.
Implementations are expected to be configured to support a specific
set of capabilities (a mode) and to reject messages that indicate the
use of a different set of capabilities (a different mode). Thus, the
capabilities advertisement is not a negotiation, but a verification
that peers are using the same mode.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Acronyms 3. Acronyms
This document uses the following acronyms: This document uses the following acronyms:
APS Automatic Protection Switching APS Automatic Protection Switching
DNR Do-not-Revert DNR Do-not-Revert
EXER Exercise EXER Exercise
FS Forced Switch FS Forced Switch
LO Lockout of protection LO Lockout of protection
MS Manual Switch MS Manual Switch
MS-P Manual Switch to Protection path MS-P Manual Switch to Protection path
MS-W Manual Switch to Working path MS-W Manual Switch to Working path
skipping to change at page 7, line 20 skipping to change at page 7, line 46
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 case network operators need an option to Administrative state. In case network operators need an option to
control their networks so that the traffic can remain on the control their networks so that the traffic can remain on the
protection path even when the PSC communication channel is broken, protection path even when the PSC communication channel is broken,
the Freeze command can be used. Freeze is defined to be a "local" the Freeze command can be used. Freeze is defined to be a "local"
command that is not signaled to the remote node. The use of the command that is not signaled to the remote node. The use of the
Freeze command is described in Appendix C. Freeze command is described in Appendix C.
4.4. Procedures in support of Capability 1 4.4. Procedures in support of priority modification
When the modified priorities specified in this document is in use, When the modified priority order specified in this document is in
the list of local requests in order of priority SHALL be as follows: use, the list of local requests in order of priority SHALL be as
follows:
(from highest to lowest) (from highest to lowest)
o Clear Signal Fail o Clear Signal Fail
o Signal Fail on Protection path o Signal Fail on Protection path
o Forced Switch o Forced Switch
o Signal Fail on Working path o Signal Fail on Working path
skipping to change at page 8, line 18 skipping to change at page 8, line 44
state machine) relative to that described in [RFC6378]. Sections 10 state machine) relative to that described in [RFC6378]. Sections 10
and 11 present the PSC Control Logic when all capabilities of APS and 11 present the PSC Control Logic when all capabilities of APS
mode are enabled. mode are enabled.
6. Capability 3: Support of MS-W Command 6. Capability 3: Support of MS-W Command
6.1. Motivation for adding MS-W 6.1. Motivation for adding MS-W
Changing the non-revertive operation as described in Section 5 Changing the non-revertive operation as described in Section 5
introduces necessity of a new operator command to revert traffic to introduces necessity of a new operator command to revert traffic to
the working path when in the DNR state. When the traffic is on the the working path in the DNR state. When the traffic is on the
protection path in the DNR state, a Manual Switch to Working (MS-W) protection path in the DNR state, a Manual Switch to Working (MS-W)
command is issued to switch the normal traffic back to the working command is issued to switch the normal traffic back to the working
path. According to Section 4.3.3.6 (Do-not-Revert State) in path. According to Section 4.3.3.6 (Do-not-Revert State) in
[RFC6378], "to revert back to the Normal state, the administrator [RFC6378], "to revert back to the Normal state, the administrator
SHALL issue a Lockout of protection (LO) command followed by a Clear SHALL issue a Lockout of protection (LO) command followed by a Clear
command." However, using LO command introduces the potential risk of command." However, using LO command introduces the potential risk of
an unprotected situation while the LO is in effect. an unprotected situation while the LO is in effect.
Manual Switch-over for recovery LSP/span command is defined in Manual Switch-over for recovery LSP/span command is defined in
[RFC4427]. Requirement 83 in [RFC5654] states that the external [RFC4427]. Requirement 83 in [RFC5654] states that the external
commands defined in [RFC4427] MUST be supported. Since there is no commands defined in [RFC4427] MUST be supported. Since there is no
support for this external command in [RFC6378], this functionality support for this external command in [RFC6378], this functionality
should be added to PSC. This support is provided by introducing the should be added to PSC. This support is provided by introducing the
MS-W command. The MS-W command, as described here, corresponds to MS-W command. The MS-W command, as described here, corresponds to
the "Manual Switch- over for recovery LSP/span" command. the "Manual Switch-over for recovery LSP/span" command.
6.2. Terminology to support MS-W 6.2. Terminology to support MS-W
[RFC6378] uses the term "Manual Switch" and its acronym "MS". This [RFC6378] uses the term "Manual Switch" and its acronym "MS". This
document uses the term "Manual Switch to Protection path" and "MS-P" document uses the term "Manual Switch to Protection path" and "MS-P"
to have the same meaning, while avoiding confusion with "Manual to have the same meaning, while avoiding confusion with "Manual
Switch to Working path" and its acronym "MS-W". Switch to Working path" and its acronym "MS-W".
Similarly, we modify the name of "Protecting Administrative" state Similarly, we modify the name of "Protecting Administrative" state
(as defined in [RFC6378]) to be "Switching Administrative" state to (as defined in [RFC6378]) to be "Switching Administrative" state to
include the case where traffic is switched to the working path as a include the case where traffic is switched to the working path as a
result of the external MS-W command. result of the external MS-W command.
6.3. Behavior of MS-P and MS-W 6.3. Behavior of MS-P and MS-W
MS-P and MS-W SHALL have the same priority. We consider different MS-P and MS-W SHALL have the same priority. We consider different
instances of determining the priority of the commands when they are instances of determining the priority of the commands when they are
received either in succession or simultaneously. received either in succession or simultaneously.
o When two commands are received in succession, the command that is o When two commands are received in succession, the command that is
received after the initial command is accepted SHALL be cancelled. received after the initial command SHALL be cancelled.
o If two nodes simultaneously receive commands that indicate o If two nodes simultaneously receive commands that indicate
opposite operations (i.e., one node receives MS-P and the other opposite operations (i.e., one node receives MS-P and the other
node receives MS-W) and transmit the indications to the remote node receives MS-W) and transmit the indications to the remote
node, the MS-W SHALL be considered to have a higher priority, and node, the MS-W SHALL be considered to have a higher priority, and
the MS-P SHALL be cancelled and discarded. the MS-P SHALL be cancelled and discarded.
Two commands, MS-P and MS-W are transmitted using the same Request Two commands, MS-P and MS-W are transmitted using the same Request
field value, but SHALL indicate in the Fault Path (FPath) value the field value, but SHALL indicate in the Fault Path (FPath) value the
path that the traffic is being diverted from. When traffic is path that the traffic is being diverted from. When traffic is
skipping to change at page 10, line 45 skipping to change at page 11, line 23
transport networks (such as SDH, OTN, and Ethernet transport transport networks (such as SDH, OTN, and Ethernet transport
networks) we define the followings: networks) we define the followings:
o The priorities of SD-P and SD-W SHALL be equal. o The priorities of SD-P and SD-W SHALL be equal.
o Once a switch has been completed due to SD on one path, it will o Once a switch has been completed due to SD on one path, it will
not be overridden by SD on the other path (first come, first not be overridden by SD on the other path (first come, first
served behavior), to avoid protection switching that cannot served behavior), to avoid protection switching that cannot
improve signal quality. improve signal quality.
The SD message indicates that the transmitting node has identified a The SD message indicates that the transmitting node has identified
degradation of the signal, or integrity of the packet transmission on degradation of the signal or integrity of the packet received 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 degraded condition SHALL identify the path that is reporting the degraded condition
(i.e., if the protection path, then FPath is set to 0; if the working (i.e., if the protection path, then FPath is set to 0; if the working
path, then FPath is set to 1), and the Path field SHALL indicate path, then FPath is set to 1), and the Path field SHALL indicate
where the data traffic is being transported (i.e., if the working where the data traffic is being transported (i.e., if the working
path is selected, then Path is set to 0; if the protection path is path is selected, then Path is set to 0; if the protection path is
selected, then Path is set to 1). selected, then Path is set to 1).
When the SD condition is cleared and the protected domain is When the SD condition is cleared and the protected domain is
recovering from the situation, the Wait-to-Restore (WTR) timer SHALL recovering from the situation, the Wait-to-Restore (WTR) timer SHALL
skipping to change at page 11, line 20 skipping to change at page 11, line 46
The WTR timer SHALL be started at the node that recovers from a local The WTR timer SHALL be started at the node that recovers from a local
degraded condition on the working path. 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 node SHALL duplicate user data traffic and SHALL protection path, the node SHALL duplicate user data traffic and SHALL
feed to both the working path and the protection path. The packet feed to both the working path and the protection path. The packet
duplication SHALL continue as long as any SD condition exists in the duplication SHALL continue as long as any SD condition exists in the
protected domain. The packet duplication SHALL continue in the WTR protected domain. When the SD condition is cleared, in revertive
state in revertive operation and SHALL stop when the node leaves the operation, the packet duplication SHALL continue in the WTR state and
WTR state. In non-revertive operation, the packet duplication SHALL SHALL stop when the node leaves the WTR state; while in non-revertive
stop when the SD condition is cleared. operation, the packet duplication SHALL stop immediately.
The selector bridge with the packet duplication under SD condition, The selector bridge with the packet duplication under SD condition,
which is a non-permanent bridge, is considered to be a 1:1 protection which is a non-permanent bridge, is considered to be a 1:1 protection
architecture. architecture.
Protection switching against SD does not introduce any modification Protection switching against SD does not introduce any modification
to the operation of the selector at the sink node described in to the operation of the selector at the sink node described in
[RFC6378]. The selector chooses either the working or protection [RFC6378]. The selector chooses either the working or protection
path from which to receive the normal traffic in both 1:1 and 1+1 path from which to receive the normal traffic in both 1:1 and 1+1
architectures. The position of the selector, i.e., which path to architectures. The position of the selector, i.e., which path to
receive the traffic, is determined by the PSC protocol in receive the traffic, is determined by the PSC protocol in
bidirectional switching or by the local input in unidirectional bidirectional switching or by the local input in unidirectional
switching. switching.
7.4. Equal priority resolution 7.4. Equal priority resolution
In order to support the MS behavior described in Section 6.3 and the In order to support the MS behavior described in Section 6.3 and the
protection against SD described in Section 7.3, it is necessary to protection against SD described in Section 7.3, it is necessary to
expand the rules for treating equal priority inputs. expand rules for treating equal priority inputs.
For equal priority local inputs, such as MS and SD, apply a simple For equal priority local inputs, such as MS and SD, apply a simple
first-come, first-served rule. Once a local input is determined as first-come, first-served rule. Once a local input is determined as
the highest priority local input, then a subsequent equal priority the highest priority local input, then a subsequent equal priority
local input requesting a different action, i.e., the action results local input requesting a different action, i.e., the action results
in the same PSC Request field but different FPath value, will not be in the same PSC Request field but different FPath value, will not be
presented to the PSC Control Logic as the highest local request. presented to the PSC Control Logic as the highest local request.
Furthermore, in the case of MS command, the subsequent local MS Furthermore, in the case of MS command, the subsequent local MS
command requesting a different action will be cancelled. command requesting a different action will be cancelled.
skipping to change at page 13, line 39 skipping to change at page 14, line 15
o If a node has issued EXER and receives EXER before receiving RR, o If a node has issued EXER and receives EXER before receiving RR,
it MUST treat the received EXER as it would an RR, and SHOULD NOT it MUST treat the received EXER as it would an RR, and SHOULD NOT
respond with RR. respond with RR.
The following PSC Requests are added to the PSC Request field to The following PSC Requests are added to the PSC Request field to
support the Exercise command (see also Section 14.1): support the Exercise command (see also Section 14.1):
(3) Exercise - indicates that the transmitting end point is (3) Exercise - indicates that the transmitting end point is
exercising the protection channel and mechanism. FPath and Path exercising the protection channel and mechanism. FPath and Path
are set to the same value of the No Request (NR), RR or DNR are set to the same value of the No Request (NR), RR or DNR
request that EXER replaces. message whose transmission is stopped by EXER.
(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 node. FPath and responding to an EXER command from the remote node. FPath and
Path are set to the same value of the NR or DNR request that RR Path are set to the same value of the NR or DNR message whose
replaces. transmission is stopped by RR.
The relative priorities of EXER and RR are defined in Section 10.2. The relative priorities of EXER and RR are defined in Section 10.2.
9. Capabilities and Modes 9. Capabilities and Modes
9.1. Capabilities 9.1. Capabilities
A Capability is an individual behavior whose use is signaled in a A Capability is an individual behavior whose use is signaled in a
Capabilities TLV, which is placed in Optional TLVs field inside the Capabilities TLV, which is placed in Optional TLVs field inside the
PSC message shown in Figure 2 of [RFC6378]. The format of the PSC message shown in Figure 2 of [RFC6378]. The format of the
Capabilities TLV is: Capabilities TLV is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 31 skipping to change at page 16, line 10
and received Capabilities TLVs are not equal, this indicates a and received Capabilities TLVs are not equal, this indicates a
capabilities TLV mismatch. When this happens, the node MUST alert capabilities TLV mismatch. When this happens, the node MUST alert
the operator and MUST NOT perform any protection switching until the the operator and MUST NOT perform any protection switching until the
operator resolves the mismatch between the two end-points. operator resolves the mismatch between the two end-points.
9.2. Modes 9.2. Modes
A mode is a given set of Capabilities. Modes are shorthand; A mode is a given set of Capabilities. Modes are shorthand;
referring to a set of capabilities by their individual values or by referring to a set of capabilities by their individual values or by
the name of their mode does not change the protocol behavior. This the name of their mode does not change the protocol behavior. This
document defines two modes - PSC and APS. document defines two modes - PSC and APS. Capability TLVs with other
combinations than the one specified by a mode are not supported in
this specification.
9.2.1. PSC mode 9.2.1. PSC mode
PSC mode is defined as the lack of support for any of the additional PSC mode is defined as the lack of support for any of the additional
capabilities defined in this document - that is, a Capabilities set capabilities defined in this document - that is, a Capabilities set
of 0x0. It is the behavior specified in [RFC6378]. of 0x0. It is the behavior specified in [RFC6378].
There are two ways to declare PSC mode. A node can send no There are two ways to declare PSC mode. A node can send no
Capabilities TLV at all since there are no TLV units defined in Capabilities TLV at all since there are no TLV units defined in
[RFC6378], or it can send a Capabilities TLV with Flags value set to [RFC6378], or it can send a Capabilities TLV with Flags value set to
skipping to change at page 24, line 48 skipping to change at page 25, line 48
PF:DW:L | i | i | i | i | i | i | i PF:DW:L | i | i | i | i | i | i | i
PF:W:R | SA:MW:R | SA:MP:R | (9) | E::R | i | (10) | (11) PF:W:R | SA:MW:R | SA:MP:R | (9) | E::R | i | (10) | (11)
PF:DW:R | SA:MW:R | SA:MP:R | (9) | E::R | i | (10) | (11) PF:DW:R | SA:MW:R | SA:MP:R | (9) | E::R | i | (10) | (11)
SA:F:L | i | i | i | i | i | i | i SA:F:L | i | i | i | i | i | i | i
SA:MW:L | i | i | i | i | i | i | i SA:MW:L | i | i | i | i | i | i | i
SA:MP:L | i | i | i | i | i | i | i SA:MP:L | i | i | i | i | i | i | i
SA:F:R | SA:MW:R | SA:MP:R | i | E::R | i | DNR | N SA:F:R | SA:MW:R | SA:MP:R | i | E::R | i | DNR | N
SA:MW:R | i | SA:MP:R | i | E::R | i | i | N SA:MW:R | i | SA:MP:R | i | E::R | i | i | N
SA:MP:R | SA:MW:R | i | i | E::R | i | DNR | N SA:MP:R | SA:MW:R | i | i | E::R | i | DNR | N
WTR | SA:MW:R | SA:MP:R | i | i | i | i | (12) WTR | SA:MW:R | SA:MP:R | i | i | i | i | (12)
DNR | SA:MW:R | SA:MP:R | i | E::R | i | i | i DNR | SA:MW:R | SA:MP:R | (13)| E::R | i | i | i
E::L | SA:MW:R | SA:MP:R | (13)| i | i | i | i E::L | SA:MW:R | SA:MP:R | i | i | i | i | i
E::R | SA:MW:R | SA:MP:R | i | i | i | DNR | N E::R | SA:MW:R | SA:MP:R | i | i | i | DNR | N
NOTES: NOTES:
(7) If the received SD-W message has Path=0, ignore the message. If (7) If the received SD-W message has Path=0, ignore the message. If
the received SD-W message has Path=1, go to the PF:DW:R state the received SD-W message has Path=1, go to the PF:DW:R state
and transmit SD(0,1) and transmit SD(0,1)
(8) If the received SD-P message has Path=1, ignore the message. If (8) If the received SD-P message has Path=1, ignore the message. If
the received SD-P message has Path=0, go to the UA:DP:R state the received SD-P message has Path=0, go to the UA:DP:R state
and transmit SD(1,0). and transmit SD(1,0).
skipping to change at page 37, line 32 skipping to change at page 38, line 32
Taesik Cheung Taesik Cheung
ETRI ETRI
218 Gajeongno 218 Gajeongno
Yuseong-gu, Daejeon 305-700 Yuseong-gu, Daejeon 305-700
South Korea South Korea
Phone: +82-42-860-5646 Phone: +82-42-860-5646
Email: cts@etri.re.kr Email: cts@etri.re.kr
Eric Osborne Eric Osborne
Cisco Systems, Inc.
Email: eosborne@cisco.com Email: eric.osborne@notcom.com
 End of changes. 32 change blocks. 
61 lines changed or deleted 76 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/