MPLS Working Group J. Ryoo Internet-Draft ETRI Intended status: Standards Track H. van Helvoort Expires: August 22, 2013 Huawei Technologies A. D'Alessandro Telecom Italia February 18, 2013 Priority Modification for the PSC Linear Protection draft-rhd-mpls-tp-psc-priority-00.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 August 22, 2013. 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 August 22, 2013 [Page 1] Internet-Draft Priority in PSC Linear Protection February 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivations for swapping priorities of FS and SF-P . . . . 3 1.2. Motivation for raising the priority of Clear SF . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . . 4 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . 5 4.3. Updates to Section 4.3.3.3. Protecting Administrative State . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.4. Updates to Appendix A. PSC State Machine Tables . . . . . . 6 5. Security considerations . . . . . . . . . . . . . . . . . . . . 7 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Appendix A. Freeze Command . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Ryoo, et al. Expires August 22, 2013 [Page 2] Internet-Draft Priority in PSC Linear Protection February 2013 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. 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 has failed and consequently the PSC communication stopped. An example of the out-of-service scenarios is shown in Annex 1 of the ITU's liaison statement "Liaison Statement: Recommendation ITU-T G.8131/Y.1382 revision - Linear protection switching for MPLS-TP networks" [LIAISON1205]. 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 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. In the case that network operators need an option to control their networks so that the traffic can be placed on the protection path even when the PSC communication channel is broken, an end-to-end command should not be an option. Changing the priority of inputs by provisioning adds complexity and the possibility for mis- configuration. This is unacceptable for transport network operators. Ryoo, et al. Expires August 22, 2013 [Page 3] Internet-Draft Priority in PSC Linear Protection February 2013 Instead of using FS, 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 A. 1.2. Motivation for raising the priority of Clear SF The technical issue with the priority of Clear SF defined in [RFC6378] is shown in Appendix IV of [LIAISON1234]. 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 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) Ryoo, et al. Expires August 22, 2013 [Page 4] Internet-Draft Priority in PSC Linear Protection February 2013 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 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. Ryoo, et al. Expires August 22, 2013 [Page 5] Internet-Draft Priority in PSC Linear Protection February 2013 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): 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 Ryoo, et al. Expires August 22, 2013 [Page 6] Internet-Draft Priority in PSC Linear Protection February 2013 +---------+----+--------+----+------+----+-----+-----+----+ | | 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 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. References 8.1. 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., Ryoo, et al. Expires August 22, 2013 [Page 7] Internet-Draft Priority in PSC Linear Protection February 2013 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. 8.2. Informative References [LIAISON1205] ITU-T SG15, "Liaison Statement: Recommendation ITU-T G.8131/Y.1382 revision - Linear protection switching for MPLS-TP networks", https://datatracker.ietf.org/liaison/1205/ , October 2012. [LIAISON1234] ITU-T SG15, "Liaison Statement: Recommendation ITU-T G.8131 revision - Linear protection switching for MPLS-TP networks", https://datatracker.ietf.org/liaison/1234/ , February 2013. Appendix A. 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. Ryoo, et al. Expires August 22, 2013 [Page 8] Internet-Draft Priority in PSC Linear Protection February 2013 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 Huub van Helvoort Huawei Technologies Email: huub.van.helvoort@huawei.com Alessandro D'Alessandro Telecom Italia via Reiss Romoli, 274 Torino 10141 Italy Phone: +30 011 2285887 Email: alessandro.dalessandro@telecomitalia.it Ryoo, et al. Expires August 22, 2013 [Page 9]