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]