--- 1/draft-ietf-mpls-tp-psc-itu-03.txt 2014-03-28 00:14:35.551919159 -0700 +++ 2/draft-ietf-mpls-tp-psc-itu-04.txt 2014-03-28 00:14:35.623920984 -0700 @@ -1,29 +1,29 @@ MPLS Working Group J. Ryoo, Ed. Internet-Draft ETRI Updates: 6378 (if approved) E. Gray, Ed. Intended status: Standards Track Ericsson -Expires: August 28, 2014 H. van Helvoort +Expires: September 29, 2014 H. van Helvoort Huawei Technologies A. D'Alessandro Telecom Italia T. Cheung ETRI E. Osborne - Cisco Systems, Inc. - February 24, 2014 + + March 28, 2014 MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of SDH, OTN and Ethernet Transport Network Operators - draft-ietf-mpls-tp-psc-itu-03.txt + draft-ietf-mpls-tp-psc-itu-04.txt Abstract This document describes alternate mechanisms to perform some of the functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks. @@ -48,21 +48,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -72,68 +72,68 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Capability 1: Priority Modification . . . . . . . . . . . . . 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.4. Procedures in support of Capability 1 . . . . . . . . . . 7 - 5. Capability 2: Non-revertive Behavior Modification . . . . . . 7 + 4.4. Procedures in support of priority modification . . . . . 7 + 5. Capability 2: Non-revertive Behavior Modification . . . . . . 8 6. Capability 3: Support of MS-W Command . . . . . . . . . . . . 8 6.1. Motivation for adding MS-W . . . . . . . . . . . . . . . 8 - 6.2. Terminology to support MS-W . . . . . . . . . . . . . . . 8 - 6.3. Behavior of MS-P and MS-W . . . . . . . . . . . . . . . . 8 - 6.4. Equal priority resolution for MS . . . . . . . . . . . . 9 - 7. Capability 4: Support of Protection against SD . . . . . . . 9 - 7.1. Motivation for supporting protection against SD . . . . . 9 + 6.2. Terminology to support MS-W . . . . . . . . . . . . . . . 9 + 6.3. Behavior of MS-P and MS-W . . . . . . . . . . . . . . . . 9 + 6.4. Equal priority resolution for MS . . . . . . . . . . . . 10 + 7. Capability 4: Support of Protection against SD . . . . . . . 10 + 7.1. Motivation for supporting protection against SD . . . . . 10 7.2. Terminology to support SD . . . . . . . . . . . . . . . . 10 - 7.3. Behavior of protection against SD . . . . . . . . . . . . 10 - 7.4. Equal priority resolution . . . . . . . . . . . . . . . . 11 + 7.3. Behavior of protection against SD . . . . . . . . . . . . 11 + 7.4. Equal priority resolution . . . . . . . . . . . . . . . . 12 8. Capability 5: Support of EXER Command . . . . . . . . . . . . 13 - 9. Capabilities and Modes . . . . . . . . . . . . . . . . . . . 13 + 9. Capabilities and Modes . . . . . . . . . . . . . . . . . . . 14 9.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 14 9.1.1. Sending and receiving the Capabilities TLV . . . . . 15 - 9.2. Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 9.2.1. PSC mode . . . . . . . . . . . . . . . . . . . . . . 15 + 9.2. Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 9.2.1. PSC mode . . . . . . . . . . . . . . . . . . . . . . 16 9.2.2. APS mode . . . . . . . . . . . . . . . . . . . . . . 16 10. PSC Protocol in APS Mode . . . . . . . . . . . . . . . . . . 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.3. Acceptance and retention of local inputs . . . . . . . . 19 - 11. State Transition Tables in APS Mode . . . . . . . . . . . . . 19 - 11.1. State transition by local inputs . . . . . . . . . . . . 21 - 11.2. State transition by remote messages . . . . . . . . . . 23 + 11. State Transition Tables in APS Mode . . . . . . . . . . . . . 20 + 11.1. State transition by local inputs . . . . . . . . . . . . 22 + 11.2. State transition by remote messages . . . . . . . . . . 24 11.3. State transition for 1+1 unidirectional - protection . . . . . . . . . . . . . . . . . . . . . . . 25 - 12. Provisioning Mismatch and Protocol Failure in APS Mode . . . 26 - 13. Security Considerations . . . . . . . . . . . . . . . . . . . 27 - 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 - 14.1. MPLS PSC Request Registry . . . . . . . . . . . . . . . 27 - 14.2. MPLS PSC TLV Registry . . . . . . . . . . . . . . . . . 27 - 14.3. MPLS PSC Capability Flag Registry . . . . . . . . . . . 27 - 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 - 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 16.1. Normative References . . . . . . . . . . . . . . . . . . 28 - 16.2. Informative References . . . . . . . . . . . . . . . . . 28 - Appendix A. An Example of Out-of-service Scenarios . . . . . . . 29 + protection . . . . . . . . . . . . . . . . . . . . . . . 26 + 12. Provisioning Mismatch and Protocol Failure in APS Mode . . . 27 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 28 + 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 + 14.1. MPLS PSC Request Registry . . . . . . . . . . . . . . . 28 + 14.2. MPLS PSC TLV Registry . . . . . . . . . . . . . . . . . 28 + 14.3. MPLS PSC Capability Flag Registry . . . . . . . . . . . 28 + 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 + 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 16.1. Normative References . . . . . . . . . . . . . . . . . . 29 + 16.2. Informative References . . . . . . . . . . . . . . . . . 29 + Appendix A. An Example of Out-of-service Scenarios . . . . . . . 30 Appendix B. An Example of Sequence Diagram Showing - the Problem with the Priority Level of SFc . . . . . 30 - Appendix C. Freeze Command . . . . . . . . . . . . . . . . . . . 32 - Appendix D. Operation Examples of the APS Mode . . . . . . . . . 32 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 + the Problem with the Priority Level of SFc . . . . . 31 + Appendix C. Freeze Command . . . . . . . . . . . . . . . . . . . 33 + Appendix D. Operation Examples of the APS Mode . . . . . . . . . 33 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 1. Introduction Linear protection mechanisms for the MPLS Transport Profile (MPLS-TP) are described in RFC 6378 [RFC6378] to meet the requirements described in RFC 5654 [RFC5654]. This document describes alternate mechanisms to perform some of the functions of linear protection, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms @@ -186,39 +186,51 @@ logic, the PSC state machine and the PSC message generation and reception, and the integrity of the protection path, without triggering the actual traffic switching. This document introduces capabilities and modes. A capability is an individual behavior. The capabilities of a node are advertised using the method given in this document. A mode is a particular combination of capabilities. Two modes are defined in this document: 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 state machine of the PSC protocol when all the capabilities associated with the APS mode are enabled. The PSC protocol behavior for the PSC mode is as defined in [RFC6378]. This document updates [RFC6378] by adding a capability advertisement mechanism. It is recommended that existing implementations of the PSC protocol be updated to support this capability. Backward - compatibility with existing implementations is described in - Section 9.2.1. + compatibility with existing implementations that do not support this + 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Acronyms - This document uses the following acronyms: APS Automatic Protection Switching DNR Do-not-Revert EXER Exercise FS Forced Switch LO Lockout of protection MS Manual Switch MS-P Manual Switch to Protection path MS-W Manual Switch to Working path @@ -295,24 +307,25 @@ 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 Administrative state. In case network operators need an option to control their networks so that the traffic can remain on the protection path even when the PSC communication channel is broken, 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 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, - the list of local requests in order of priority SHALL be as follows: + When the modified priority order specified in this document is in + use, the list of local requests in order of priority SHALL be as + follows: (from highest to lowest) o Clear Signal Fail o Signal Fail on Protection path o Forced Switch o Signal Fail on Working path @@ -341,21 +354,21 @@ state machine) relative to that described in [RFC6378]. Sections 10 and 11 present the PSC Control Logic when all capabilities of APS mode are enabled. 6. Capability 3: Support of MS-W Command 6.1. Motivation for adding MS-W Changing the non-revertive operation as described in Section 5 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) 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 [RFC6378], "to revert back to the Normal state, the administrator SHALL issue a Lockout of protection (LO) command followed by a Clear command." However, using LO command introduces the potential risk of an unprotected situation while the LO is in effect. Manual Switch-over for recovery LSP/span command is defined in [RFC4427]. Requirement 83 in [RFC5654] states that the external @@ -377,21 +390,21 @@ include the case where traffic is switched to the working path as a result of the external MS-W command. 6.3. Behavior of MS-P and MS-W MS-P and MS-W SHALL have the same priority. We consider different instances of determining the priority of the commands when they are received either in succession or simultaneously. 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 opposite operations (i.e., one node receives MS-P and the other node receives MS-W) and transmit the indications to the remote node, the MS-W SHALL be considered to have a higher priority, and the MS-P SHALL be cancelled and discarded. Two commands, MS-P and MS-W are transmitted using the same Request field value, but SHALL indicate in the Fault Path (FPath) value the path that the traffic is being diverted from. When traffic is @@ -462,22 +475,22 @@ transport networks (such as SDH, OTN, and Ethernet transport networks) we define the followings: o The priorities of SD-P and SD-W SHALL be equal. o Once a switch has been completed due to SD on one path, it will not be overridden by SD on the other path (first come, first served behavior), to avoid protection switching that cannot improve signal quality. - The SD message indicates that the transmitting node has identified a - degradation of the signal, or integrity of the packet transmission on + The SD message indicates that the transmitting node has identified + degradation of the signal or integrity of the packet received on either the working path or the protection path. The FPath field 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 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 path is selected, then Path is set to 0; if the protection path is selected, then Path is set to 1). When the SD condition is cleared and the protected domain is recovering from the situation, the Wait-to-Restore (WTR) timer SHALL @@ -485,43 +498,43 @@ The WTR timer SHALL be started at the node that recovers from a local degraded condition on the working path. Protection switching against SD is always provided by a selector bridge duplicating user data traffic and feeding it to both the working path and the protection path under SD condition. When a local or remote SD occurs on either the working path or the protection path, the node SHALL duplicate user data traffic and SHALL feed to both the working path and the protection path. The packet duplication SHALL continue as long as any SD condition exists in the - protected domain. The packet duplication SHALL continue in the WTR - state in revertive operation and SHALL stop when the node leaves the - WTR state. In non-revertive operation, the packet duplication SHALL - stop when the SD condition is cleared. + protected domain. When the SD condition is cleared, in revertive + operation, the packet duplication SHALL continue in the WTR state and + SHALL stop when the node leaves the WTR state; while in non-revertive + operation, the packet duplication SHALL stop immediately. The selector bridge with the packet duplication under SD condition, which is a non-permanent bridge, is considered to be a 1:1 protection architecture. Protection switching against SD does not introduce any modification to the operation of the selector at the sink node described in [RFC6378]. 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 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 - 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 first-come, first-served rule. Once a local input is determined as the highest priority local input, then a subsequent equal priority local input requesting a different action, i.e., the action results in the same PSC Request field but different FPath value, will not be presented to the PSC Control Logic as the highest local request. Furthermore, in the case of MS command, the subsequent local MS command requesting a different action will be cancelled. @@ -597,30 +610,31 @@ 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 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 exercising the protection channel and mechanism. FPath and Path 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 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 - replaces. + Path are set to the same value of the NR or DNR message whose + transmission is stopped by RR. The relative priorities of EXER and RR are defined in Section 10.2. 9. Capabilities and Modes + 9.1. Capabilities A Capability is an individual behavior whose use is signaled in a Capabilities TLV, which is placed in Optional TLVs field inside the PSC message shown in Figure 2 of [RFC6378]. The format of the Capabilities TLV is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -682,21 +697,23 @@ and received Capabilities TLVs are not equal, this indicates a capabilities TLV mismatch. When this happens, the node MUST alert the operator and MUST NOT perform any protection switching until the operator resolves the mismatch between the two end-points. 9.2. Modes A mode is a given set of Capabilities. Modes are shorthand; referring to a set of capabilities by their individual values or by 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 PSC mode is defined as the lack of support for any of the additional capabilities defined in this document - that is, a Capabilities set of 0x0. It is the behavior specified in [RFC6378]. There are two ways to declare PSC mode. A node can send no 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 @@ -1102,22 +1119,22 @@ 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: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:MW: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: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 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 - E::L | SA:MW:R | SA:MP:R | (13)| i | i | i | i + DNR | SA:MW:R | SA:MP:R | (13)| E::R | 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 NOTES: (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 and transmit SD(0,1) (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 and transmit SD(1,0). @@ -1682,13 +1699,12 @@ Taesik Cheung ETRI 218 Gajeongno Yuseong-gu, Daejeon 305-700 South Korea Phone: +82-42-860-5646 Email: cts@etri.re.kr Eric Osborne - Cisco Systems, Inc. - Email: eosborne@cisco.com + Email: eric.osborne@notcom.com