[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 draft-ryoogray-mpls-tp-psc-itu

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]


Html markup produced by rfcmarkup 1.122, available from https://tools.ietf.org/tools/rfcmarkup/