MPLS Working Group J. Ryoo Internet-Draft ETRI Intended status: Standards Track H. van Helvoort Expires: February 22, 2014 Huawei Technologies A. D'Alessandro Telecom Italia August 21, 2013 Priority Modification for the PSC Linear Protection draft-rhd-mpls-tp-psc-priority-01.txt Abstract This document contains the modifications to the priorities of inputs in [RFC6378], "MPLS Transport Profile (MPLS-TP) Linear Protection" in an effort to satisfy the ITU-T's protection switching requirements and correcting the problems that have been identified. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 February 22, 2014. Copyright Notice Copyright (c) 2013 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Ryoo, et al. Expires February 22, 2014 [Page 1] Internet-Draft Priority in PSC Linear Protection August 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Motivations for swapping priorities of FS and SF-P . . . 2 1.2. Motivation for raising the priority of Clear SF . . . . . 3 1.3. Motivation for introducing Freeze command . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Updates to the PSC RFC . . . . . . . . . . . . . . . . . . . 4 4.1. Updates to Section 4.3.2. Priority of Inputs . . . . . . 4 4.2. Updates to Section 4.3.3.2. Unavailable State . . . . . . 4 4.3. Updates to Section 4.3.3.3. Protecting Administrative State . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.4. Updates to Appendix A. PSC State Machine Tables . . . . . 5 5. Security considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 Appendix A. An exmaple of out-of-service scenarios . . . . . . . 7 Appendix B. An exmaple of sequence diagram showing the problem with the priority level of Clear SF . . 8 Appendix C. Freeze Command . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction This document contains the modifications to the priorities of inputs in [RFC6378], "MPLS Transport Profile (MPLS-TP) Linear Protection" in an effort to satisfy the ITU-T's protection switching requirements and correcting the problems that have been identified. In this document, the priorities of FS and SF-P are swapped and the priority of Clear SF is raised. In addition to the prioririty modification, this document introduces the use of a Freeze command in an Appendix. The reasons for these changes are explained in the following sub-sections from technical and network operational aspects. 1.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 situation where the protected traffic is taken out-of-service. Setting the priority of any input that is supposed to be signaled to the other end to be higher than that of SF-P can result in unpredictable protection switching state, when the protection path Ryoo, et al. Expires February 22, 2014 [Page 2] Internet-Draft Priority in PSC Linear Protection August 2013 has failed and consequently the PSC communication stopped. An example of the out-of-service scenarios is shown in Appendix A According to Section 2.4 of [RFC5654] it MUST be possible to operate an MPLS-TP network without using a control plane. This means that external switch commands, e.g. FS, can be transferred to the far end only by using the PSC communication channel and should not rely on the presence of a control plane. As the priority of SF-P has been higher than FS in optical transport networks and Ethernet transport networks, for network operators it is important that the MPLS-TP protection switching preserves the network operation behaviour to which network operators have become accustomed. Typically, the FS command is issued before network maintenance jobs, 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 operator expects this behaviour based on his/her experience on the traditional transport network operations. 1.2. Motivation for raising the priority of Clear SF The priority level of Clear SF defined in [RFC6378] can cause traffic disruption when a node that has experienced local signal fails on both working and protection paths is recovering from these failures. An exmaple of sequence diagram showing the problem with the priority level of Clear SF defined in [RFC6378] is shown in Appendix B. 1.3. Motivation for introducing Freeze command 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 the case that 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, which is a local command and not signaled to the other end, can be used. The use of the Freeze command is described in Appendix C. 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 [RFC2119]. 3. Acronyms Ryoo, et al. Expires February 22, 2014 [Page 3] Internet-Draft Priority in PSC Linear Protection August 2013 This draft uses the following acronyms: FS Forced Switch MPLS-TP Transport Profile for MPLS SF Signal Fail SFc Clear Signal Fail 4. Updates to the PSC RFC This section describes the changes required to modify the priorities of FS, SF-P and Clear SF in the PSC protocol defined in [RFC6378] 4.1. Updates to Section 4.3.2. Priority of Inputs The list of local requests in order of priority should be modified as follows: 3 Clear Signal Fail/Degrade (OAM / control-plane / server indication) 4 Signal Fail on protection (OAM / control-plane / server indication) 5 Forced Switch (operator command) 6 Signal Fail on working (OAM / control-plane / server indication) 7 Signal Degrade on working (OAM / control-plane / server indication) 4.2. Updates to Section 4.3.3.2. Unavailable State Remove the following bullet items and their text: o A local Forced Switch SHALL be ignored by the PSC Control logic when in Unavailable state as a result of a (local or remote) Lockout of protection. If in Unavailable state due to an SF on protection, then the FS SHALL cause the LER to go into local Protecting administrative state and begin transmitting an FS(1,1) message. It should be noted that due to the unavailability of the protection path (i.e., due to the SF condition) that this FS may not be received by the far-end until the SF condition is cleared. o A remote Forced Switch message SHALL be ignored by the PSC Control logic when in Unavailable state as a result of a (local or remote) Lockout of protection. If in Unavailable state due to a local or remote SF on protection, then the FS SHALL cause the LER to go Ryoo, et al. Expires February 22, 2014 [Page 4] Internet-Draft Priority in PSC Linear Protection August 2013 into remote Protecting administrative state; if in Unavailable state due to local SF, begin transmitting an SF(0,1) message. 4.3. Updates to Section 4.3.3.3. Protecting Administrative State Remove the following text in the first paragraph: The difference between a local FS and local MS affects what local indicators may be received -- the Local Request logic will block any local SF when under the influence of a local FS, whereas the SF would override a local MS. Replace the following bullet item text: o A local Signal Fail indication on the protection path SHALL cause the LER to go into local Unavailable state and begin transmission of an SF(0,0) message, if the current state is due to a (local or remote) Manual Switch operator command. If the LER is in (local or remote) Protecting administrative state due to an FS situation, then the SF on protection SHALL be ignored. With: o A local Signal Fail indication on the protection path SHALL cause the LER to go into local Unavailable state and begin transmission of an SF(0,0) message. Replace the following bullet item text: o A remote Signal Fail message indicating a failure on the protection path SHALL cause the LER to go into remote Unavailable state and begin transmitting an NR(0,0) message, if the Protecting administrative state is due to a Manual Switch command. It should be noted that this automatically cancels the current Manual Switch command and data traffic is reverted to the working path. With: o A remote Signal Fail message indicating a failure on the protection path SHALL cause the LER to go into remote Unavailable state and begin transmitting an NR(0,0) message. It should be noted that this automatically cancels the current Forced Switch or Manual Switch command and data traffic is reverted to the working path. 4.4. Updates to Appendix A. PSC State Machine Tables Modify the state machine as follows (only modified cells are shown): Ryoo, et al. Expires February 22, 2014 [Page 5] Internet-Draft Priority in PSC Linear Protection August 2013 Part 1: Local input state machine +---------+----+----+--------+----+------+-----+----+--------+ | | OC | LO | SF-P | FS | SF-W | SFc | MS | WTRExp | +---------+----+----+--------+----+------+-----+----+--------+ | N | | | | | | | | | | UA:LO:L | | | | | | | | | | UA:P:L | | | | i | | | | | | UA:LO:R | | | | | | | | | | UA:P:R | | | | i | | | | | | PF:W:L | | | | | | | | | | PF:W:R | | | | | | | | | | PA:F:L | | | UA:P:L | | | | | | | PA:M:L | | | | | | | | | | PA:F:R | | | UA:P:L | | | | | | | PA:M:R | | | | | | | | | | WTR | | | | | | | | | | DNR | | | | | | | | | +---------+----+----+--------+----+------+-----+----+--------+ Part 2: Remote messages state machine +---------+----+--------+----+------+----+-----+-----+----+ | | LO | SF-P | FS | SF-W | MS | WTR | DNR | NR | +---------+----+--------+----+------+----+-----+-----+----+ | N | | | | | | | | | | UA:LO:L | | | | | | | | | | UA:P:L | | | i | | | | | | | UA:LO:R | | | | | | | | | | UA:P:R | | | i | | | | | | | PF:W:L | | | | | | | | | | PF:W:R | | | | | | | | | | PA:F:L | | UA:P:R | | | | | | | | PA:M:L | | | | | | | | | | PA:F:R | | UA:P:R | | | | | | | | PA:M:R | | | | | | | | | | WTR | | | | | | | | | | DNR | | | | | | | | | +---------+----+--------+----+------+----+-----+-----+----+ Remove the following item in the footnotes for the table: [19] Transition to PA:F:R and send SF (0,1). 5. Security considerations Ryoo, et al. Expires February 22, 2014 [Page 6] Internet-Draft Priority in PSC Linear Protection August 2013 No specific security issue is raised in addition to those ones already documented in [RFC6378] 6. IANA considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Acknowledgements 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009. [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, October 2011. Appendix A. An exmaple of out-of-service scenarios The sequence diagram shown is an example of the out-of-service scenerios based on the priority level defined in [RFC6378]. The first PSC message which differs from the previous PSC message is shown. A Z | | (1) |-- NR(0,0) ------>| (1) |<----- NR(0,0) ---| | | | | | (FS issued at Z) | (2) (3) |<------ FS(1,1) --| |-- NR(0,1) ------>| | | | | (4) | (SF on P(A<-Z)) | | | | | | (Clear FS at Z) | (5) (6) | X <- NR(0,0) --| Ryoo, et al. Expires February 22, 2014 [Page 7] Internet-Draft Priority in PSC Linear Protection August 2013 | | | | (1) Each end is in Normal state, and transmits NR (0,0) messages. (2) When a Forced Switch command is issued at node Z, node Z goes into local Protecting Administrative state (PA:F:L) and begins transmission of an FS (1,1) messages. (3) A remote Forced Switch message causes node A to go into remote Protecting Administrative state (PA:F:R), and node A begins transmitting NR (0,1) messages. (4) When node A detects a unidirectional Signal Fail on the protection path, node A keeps sending NR (0,1) message because SF-P is ignored under the state PA:F:R. (5) When a Clear command is issued at node Z, node Z goes into Normal state and begins transmission of NR (0,0) messages. (6) But node A cannot receive PSC message because of local unidirectional Signal Fail indication on the protection path. Because no valid PSC message is received, over a period of several continual messages intervals, the last valid received message remains applicable and the node A continue to transmit an NR (0,1) message in the state of PA:F:R. Now, there exists a mismatch between the bridge/selector positions of 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 signal fail on working path nor FS. Appendix B. An exmaple of sequence diagram showing the problem with the priority level of Clear SF An exmaple of sequence diagram showing the problem with the priority level of Clear SF defined in [RFC6378] is given below. The following sequence diagram is depicted for the case of bidirectional signal fails. However, other cases with unidirectional signal fails can result in the same problem. The first PSC message which differs from the previous PSC message is shown. A Z | | (1) |-- NR(0,0) ------>| (1) |<----- NR(0,0) ---| | | Ryoo, et al. Expires February 22, 2014 [Page 8] Internet-Draft Priority in PSC Linear Protection August 2013 | | (2) | (SF on P(A<->Z)) | (2) |-- SF(0,0) ------>| |<------ SF(0,0) --| | | | | (3) | (SF on W(A<->Z)) | (3) | | | | (4) | (Clear SF-P) | (4) | | | | (5) | (Clear SF-W) | (5) | | | | (1) Each end is in Normal state, and transmits NR (0,0) messages. (2) When signal fail on protection (SF-P) occurs, each node enters into [UA:P:L] state and transmits SF (0,0) messages. Traffic remains on working path. (3) When signal fail on working (SF-W) occurs, each node remains in [UA:P:L] state as SF-W has a lower priority than SF-P. Traffic is still on the working path. Traffic cannot be delivered as both working and protection paths are experiencing signal fails. (4) When the signal fail on protection is cleared, local "Clear SF-P" request cannot be presented to the PSC control logic, which takes the highest priority local request and runs PSC state machine, as the priority of "Clear SF-P" is lower than that of SF-W. Consequently, there is no change in state, and the selector and/or bridge keep pointing at the working path, which has signal fail condition. Now, traffic cannot be delivered while the protection path is recovered and available. It should be noted that the same problem will occur in the case that the sequence of SF-P and SF-W events is changed. If we further continue with this sequence to see what will happen after SF-W is cleared, Ryoo, et al. Expires February 22, 2014 [Page 9] Internet-Draft Priority in PSC Linear Protection August 2013 (5) When the signal fail on working is cleared, local "Clear SF-W" request can be passed to the PSC control logic (state machine) as there is no higher priority local request, but this will be ignored in the PSC control logic according to the state transition definition in [RFC6378]. There will be no change in state or protocol message transmitted. As the signal fail on working is now cleared and the selector and/or bridge are still pointing at the working path, traffic delivery is resumed. However, each node is in [UA:P:L] state and transmitting SF(0,0) message, while there exists no outstanding request for protection switching. Moreover, any future legitimate protection switching requests, such as SF-W, will be rejected as each node thinks the protection path is unavailable. Appendix C. Freeze Command The "Freeze" command applies only to the near end (local node) of the protection group and is not signaled to the far end. This command freezes the state of the protection group. Until the Freeze is cleared, additional near end commands are rejected and condition changes and received PSC information are ignored. "Clear Freeze" command clears the local freeze. When the Freeze command is cleared, the state of the protection group is recomputed based on the persistent condition of the local triggers. 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 any operator command or a fault condition. Authors' Addresses Jeong-dong Ryoo ETRI 218 Gajeongno Yuseong-gu, Daejeon 305-700 South Korea Phone: +82-42-860-5384 Email: ryoo@etri.re.kr Ryoo, et al. Expires February 22, 2014 [Page 10] Internet-Draft Priority in PSC Linear Protection August 2013 Huub van Helvoort Huawei Technologies Karspeldreef 4, Amsterdam 1101 CJ the Netherlands Phone: +31 20 4300936 Email: huub.van.helvoort@huawei.com Alessandro D'Alessandro Telecom Italia via Reiss Romoli, 274 Torino 10141 Italy Phone: +39 011 2285887 Email: alessandro.dalessandro@telecomitalia.it Ryoo, et al. Expires February 22, 2014 [Page 11]