Internet DRAFT - draft-dj-mpls-tp-exer-psc
draft-dj-mpls-tp-exer-psc
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]
