Network Working Group A. D'Alessandro Internet-Draft Telecom Italia Intended status: Standards Track J. Ryoo Expires: March 30, 2014 ETRI H. van Helvoort Huawei Technologies September 26, 2013 Supporting the Exercise command for PSC linear protection protocol draft-dj-mpls-tp-exer-psc-02 Abstract This draft indicates how IETF RFC6378 could be modified to address the Exercise function. 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 March 30, 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. D'Alessandro, et al. Expires March 30, 2014 [Page 1] Internet-Draft EXER command in PSC September 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Updates to the PSC RFC . . . . . . . . . . . . . . . . . . . 2 2.1. Updates to Section 2.1. Acronyms . . . . . . . . . . . . 3 2.2. Updates to Section 3.1. Local Request Logic . . . . . . . 3 2.3. Update to Section 3.2. Remote Requests . . . . . . . . . 3 2.4. Updates to Section 3.6. PSC Control States . . . . . . . 3 2.5. Updates to Section 4.2.2. PSC Request Field . . . . . . . 4 2.6. Updates to Section 4.3.2. Priority of Inputs . . . . . . 4 2.7. Updates to Section 4.3.3. Operation of PSC States . . . . 4 2.7.1. Updates to Section 4.3.3.1. Normal State . . . . . . 4 2.7.2. Updates to Section 4.3.3.6. Do-not-Revert State . . . 4 2.7.3. New subsection for Exercise State . . . . . . . . . . 4 2.8. Updates to Appendix A. PSC State Machine Tables . . . . . 6 2.9. Updates to Appendix B. Exercising the Protection Domain . 9 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Exercise is a command to test if the PSC communication is operating correctly. More specifically, the Exercise is to test and validate the linear protection mechanism and PSC protocol including the aliveness of the Local Request 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. It is used while the working path is either carrying the traffic or not. It is lower priority than any "real" switch request. It is only valid in bidirectional switching, since this is the only place where one can get a meaningful test by looking for a response. This command is documented in R84 of [RFC5654] and it has been identified as a requirement in the ITU's liaison statement "Liaison Statement: Recommendation ITU-T G.8131/Y.1382 revision - Linear protection switching for MPLS-TP networks " [LIAISON1205] and "Recommendation ITU-T G.8131 revision - Linear protection switching for MPLS-TP networks [LIAISON1234]. This draft is created as an attempt to align PSC behaviour and functionalities to meet IETF and ITU-T MPLS Transport Profile requirements. 2. Updates to the PSC RFC D'Alessandro, et al. Expires March 30, 2014 [Page 2] Internet-Draft EXER command in PSC September 2013 This section describes the changes required to cover the exercise functionality to the PSC protocol defined in [RFC6378] 2.1. Updates to Section 2.1. Acronyms The following text should be added in Section 2.1 in [RFC6378]: EXER Exercise RR Reverse Request 2.2. Updates to Section 3.1. Local Request Logic EXER should be included as an operator command. The following text should be added: o Exercise (EXER) - Exercise is a command to test if the PSC communication is operating correctly. It is lower priority than any "real" switch request. It is only valid in bidirectional switching, since this is the only place where one can get a meaningful test by looking for a response. 2.3. Update to Section 3.2. Remote Requests The following text should be added: o Remote EXER - indicates that the remote end point is operating under an operator command to validate the protection mechanism and PSC protocol including the aliveness of the Local Request 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. The valid response to EXER message will be an RR with the corresponding FPath and Path numbers. The near end will signal a Reverse Request (RR) only in response to an EXER command from the far end. When Exercise commands are input at both ends, an EXER, instead of RR, is transmitted from both ends. 2.4. Updates to Section 3.6. PSC Control States The following text should be added: o Exercise state - The operator has issued the Exercise command to test and validate the protection mechanism and PSC protocol including the integrity of the protection path, without triggering the actual traffic switching. D'Alessandro, et al. Expires March 30, 2014 [Page 3] Internet-Draft EXER command in PSC September 2013 2.5. Updates to Section 4.2.2. PSC Request Field The following PSC Requests should be added to PSC Request field: (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 NR, RR or DNR request that EXER replaces. (2) Reverse Request - indicates that the transmitting end point is responding to an EXER command from the far end. FPath and Path are set to the same value of the NR, RR or DNR request that EXER replaces. 2.6. Updates to Section 4.3.2. Priority of Inputs The priority of the Exercise should be inserted between the priorities of WTR Expires and No Request. 2.7. Updates to Section 4.3.3. Operation of PSC States 2.7.1. Updates to Section 4.3.3.1. Normal State Add the following text for Section 4.3.3.1. Normal State: o A local Exercise input SHALL cause the LER to go into local Exercise state and begin transmission of an EXER(0,0) message. o A remote EXER message SHALL cause the LER to go into remote Exercise state, and transmit an RR(0,0)message. 2.7.2. Updates to Section 4.3.3.6. Do-not-Revert State Add the following text for Section 4.3.3.6. Do-not-Revert State: o A local Exercise input SHALL cause the LER to go into local Exercise state and begin transmission of an EXER(0,1) message. o A remote EXER message SHALL cause the LER to go into remote Exercise state, and transmit an RR(0,1)message. 2.7.3. New subsection for Exercise State Add a new sub-section, Section 4.3.3.7. Exercise State, with the following text: In the Exercise state, the user data traffic SHALL remain on the same path as the previous state, such as Normal state or Do-Not-Revert D'Alessandro, et al. Expires March 30, 2014 [Page 4] Internet-Draft EXER command in PSC September 2013 state. The local end SHALL signal a RR message in response to a remote EXER message. When both ends are in local Exercise state, only the EXER messages are exchanged. When in Exercise state, the following describe the reaction to local input: o A local Clear SHALL be ignored if in remote Exercise state. If in local Exercise state, then this input SHALL cause the LER to go into Normal state and being transmitting NR(0,0) when the LER is configured for revertive mode. For non-revertive mode, the LER goes into DNR state and begin transmitting DNR(0,1). o A local Lockout of protection input SHALL cause the LER to go into local Unavailable state and begin transmission of an LO(0,0) message. o A local Forced Switch input SHALL cause the LER to go into local Protecting administrative state and begin transmission of an FS(1,1) message. 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. o A local Signal Fail indication on the working path SHALL cause the LER to go into local Protecting failure state and begin transmission of an SF(1,1) message. o A local Manual Switch input SHALL cause the LER to go into local Protecting administrative state and begin transmission of an MS(1,1) message. o A local EXER input can be applied when the local end is in remote EXER state. This SHALL cause the LER to remain in the EXER state, but begin transmission of an EXER message instead of RR message. o All other local inputs SHALL be ignored. When in Exercise state, the following describe the reaction to remote messages: o A remote Lockout of protection message SHALL cause the LER to go into remote Unavailable state and begin transmission of an NR(0,0) message. D'Alessandro, et al. Expires March 30, 2014 [Page 5] Internet-Draft EXER command in PSC September 2013 o A remote Forced Switch message SHALL cause the LER to go into remote Protecting administrative state and begin transmission of an NR(0,1) message. o A remote Signal Fail message for the protection path SHALL cause the LER to go into remote Unavailable state and begin transmission of an NR(0,0) message. o A remote Signal Fail message for the working path SHALL cause the LER to go into remote Protecting failure state and begin transmission of an NR(0,1) message. o A remote Manual Switch message SHALL cause the LER to go into remote Protecting administrative state and begin transmission of an NR(0,1) message. o A remote DNR(0,1) message received in remote Exercise state SHALL cause the LER to go into DNR state and begin transmitting DNR(0,1). A remote DNR(0,1) message in local Exercise state is ignored. o A remote NR(0,0) message received in remote Exercise state SHALL cause the LER to go into Normal state and begin transmitting NR(0,0). A remote NR message in local Exercise state is ignored. o All other local inputs SHALL be ignored. 2.8. Updates to Appendix A. PSC State Machine Tables Add the following extended states: E::L = Exercise due to local EXER command E::R = Exercise due to remote EXER message Add the following messages: State REQ(FP, P) ----- ---------- E::L EXER(0,0)for revertive, or EXER(0,1)for non-revertive E::R RR(0,0) for revertive, or RR(0,1) for non-revertive Add the following line to the local inputs describing the table description rows: EXER Exercise Add the following line to the remote inputs describing the table description rows: D'Alessandro, et al. Expires March 30, 2014 [Page 6] Internet-Draft EXER command in PSC September 2013 EXER remote Exercise RR Reverse Request Modify the state machine as follows (only relevant cells are shown): Part 1: Local input state machine +-------+-----+-------+------+------+------+-----+------+------+----+ | | OC | LO | SF-P | FS | SF-W | SFc | MS | WTRE | EX | | | | | | | | | | xp | ER | +-------+-----+-------+------+------+------+-----+------+------+----+ | N | | | | | | | | | E: | | | | | | | | | | | :L | | | | | | | | | | | | | UA:LO | | | | | | | | | i | | :L | | | | | | | | | | | | | | | | | | | | | | UA:P: | | | | | | | | | i | | L | | | | | | | | | | | | | | | | | | | | | | UA:LO | | | | | | | | | i | | :R | | | | | | | | | | | | | | | | | | | | | | UA:P: | | | | | | | | | i | | R | | | | | | | | | | | | | | | | | | | | | | PF:W: | | | | | | | | | i | | L | | | | | | | | | | | | | | | | | | | | | | PF:W: | | | | | | | | | i | | R | | | | | | | | | | | | | | | | | | | | | | PA:F: | | | | | | | | | i | | L | | | | | | | | | | | | | | | | | | | | | | PA:M: | | | | | | | | | i | | L | | | | | | | | | | | | | | | | | | | | | | PA:F: | | | | | | | | | i | | R | | | | | | | | | | | | | | | | | | | | | | PA:M: | | | | | | | | | i | | R | | | | | | | | | | | | | | | | | | | | | | WTR | | | | | | | | | i | | | | | | | | | | | | | DNR | | | | | | | | | E: | | | | | | | | | | | :L | D'Alessandro, et al. Expires March 30, 2014 [Page 7] Internet-Draft EXER command in PSC September 2013 | | | | | | | | | | | | E::L | [20 | UA:LO | UA:P | PA:F | PF:W | i | PA:M | i | i | | | ] | :L | :L | :L | :L | | :L | | | | | | | | | | | | | | | E::R | i | UA:LO | UA:P | PA:F | PF:W | i | PA:M | i | E: | | | | :L | :L | :L | :L | | :L | | :L | +-------+-----+-------+------+------+------+-----+------+------+----+ Part 2: Remote messages state machine +-------+-------+------+------+------+------+-----+----+---+----+---+ | | LO | SF-P | FS | SF-W | MS | WTR | DN | N | EX | R | | | | | | | | | R | R | ER | R | +-------+-------+------+------+------+------+-----+----+---+----+---+ | N | | | | | | | | | E: | i | | | | | | | | | | | :R | | | | | | | | | | | | | | | UA:LO | | | | | | | | | i | i | | :L | | | | | | | | | | | | | | | | | | | | | | | | UA:P: | | | | | | | | | i | i | | L | | | | | | | | | | | | | | | | | | | | | | | | UA:LO | | | | | | | | | i | i | | :R | | | | | | | | | | | | | | | | | | | | | | | | UA:P: | | | | | | | | | i | i | | R | | | | | | | | | | | | | | | | | | | | | | | | PF:W: | | | | | | | | | i | i | | L | | | | | | | | | | | | | | | | | | | | | | | | PF:W: | | | | | | | | | i | i | | R | | | | | | | | | | | | | | | | | | | | | | | | PA:F: | | | | | | | | | i | i | | L | | | | | | | | | | | | | | | | | | | | | | | | PA:M: | | | | | | | | | i | i | | L | | | | | | | | | | | | | | | | | | | | | | | | PA:F: | | | | | | | | | i | i | | R | | | | | | | | | | | | | | | | | | | | | | | | PA:M: | | | | | | | | | i | i | | R | | | | | | | | | | | | | | | | | | | | | | | D'Alessandro, et al. Expires March 30, 2014 [Page 8] Internet-Draft EXER command in PSC September 2013 | WTR | | | | | | | | | i | i | | | | | | | | | | | | | | DNR | | | | | | | | | E: | i | | | | | | | | | | | :R | | | | | | | | | | | | | | | E::L | UA:LO | UA:P | PA:F | PF:W | PA:M | i | i | i | i | i | | | :R | :R | :R | :R | :R | | | | | | | | | | | | | | | | | | | E::R | UA:LO | UA:P | PA:F | PF:W | PA:M | i | DN | N | i | i | | | :R | :R | :R | :R | :R | | R | | | | +-------+-------+------+------+------+------+-----+----+---+----+---+ [20] Transition to N for revertive mode, transition to DNR for non- revervtive mode 2.9. Updates to Appendix B. Exercising the Protection Domain Remove Appendix B. 3. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 4. Security Considerations No specific security issue is raised in addition to those ones already documented in [RFC6378] 5. Acknowledgements 6. References 6.1. Normative References [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. 6.2. Informative References D'Alessandro, et al. Expires March 30, 2014 [Page 9] Internet-Draft EXER command in PSC September 2013 [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. Authors' Addresses Alessandro D'Alessandro Telecom Italia via Reiss Romoli, 274 Torino 10141 Italy Phone: +30 011 2285887 Email: alessandro.dalessandro@telecomitalia.it 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 Karspeldreef 4, Amsterdam 1101 CJ the Netherlands Phone: +31 20 4300832 Email: huub.van.helvoort@huawei.com D'Alessandro, et al. Expires March 30, 2014 [Page 10]