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

Versions: 00 01 02 03 04 05 06 07 08 draft-ietf-mpls-tp-mfp-use-case-and-requirements

Network Working Group                                             Z. Cui
Internet-Draft                                                 R. Winter
Intended status: Informational                                       NEC
Expires: August 18, 2014                               February 14, 2014


    Use Cases and Requirements for MPLS-TP multi-failure protection
           draft-cui-mpls-tp-mfp-use-case-and-requirements-01

Abstract

   MPLS Transport Profile (MPLS-TP) linear protection is defined in
   [RFC6378].  That however is limited to 1+1 and 1:1 protection and is
   not able to care that the multiple failures are occurred on both
   working and protection paths.

   This document describes why we need to consider the case for multiple
   failures, and lists some requirements for multi-failure protection
   (MFP) functionality.

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 18, 2014.

Copyright Notice

   Copyright (c) 2014 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



Cui & Winter             Expires August 18, 2014                [Page 1]


Internet-DraftUse Cases and Requirements for MPLS-TP multi-February 2014


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Document scope  . . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Requirements notation . . . . . . . . . . . . . . . . . .   3
   2.  Summary of the problem statement and use case . . . . . . . .   3
   3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Configuration . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Resource reservation  . . . . . . . . . . . . . . . . . .   5
     4.3.  Protection switching time . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Network survivability - the ability of the network to remain
   functioning in the face of failures - is an important property of a
   network built to provide service guarantees.

   For MPLS-TP networks, the protocol for linear protection is defined
   in [RFC6378].  That protocol can restores user traffic when a single
   failure condition is detected.

   If need take a long time to repair, some operators may have to find
   other protection resources to protect the user traffic since the user
   traffic is unprotected.  However, common linear protection not allows
   an overlap between a protection group and a other different path.

   This document describes the detail of the problem statements, and
   lists a number of requirements for new protection functionality.

1.1.  Document scope

   This document describes the use cases and requirements for multi-
   failure protection in MPLS-TP networks without the use of control
   plane protocols.  Existing solutions based on control plane such as
   GMPLS may be able to restore user traffic when multiple failures
   occur.  Some networks however do not use full control plane operation
   for reasons such as service provider preferences, certain limitations
   or the requirement for fast service restoration (faster than
   achievable with control plane mechanisms).  These networks are the



Cui & Winter             Expires August 18, 2014                [Page 2]


Internet-DraftUse Cases and Requirements for MPLS-TP multi-February 2014


   focus of this document which defines a set of requirements for multi-
   failure protection not based on control plane support.

1.2.  Requirements notation

   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].

2.  Summary of the problem statement and use case

   The following Figure 1 shows the network topology of an operation
   scenario.  As shown in the Figure 1, there are three independent
   paths i, j and k between LER-A and LER-B. We assume a protection
   domain between LER-A and LER-B, using path i (working path) and j
   (protection path).  Additionally, path k is a sharing resource.

                     Path i (working path)
                  ++++++++++++++++++++++++++++
                 +                            +
                +                              +
         +-----+                                +-----+
         |     |    Path j (protection path)    |     |
         |LER-A|--------------------------------|LER-Z|
         |     |                                |     |
         +-----+                                +-----+
                *                              *
                 *  Path k (sharing resource) *
                  ****************************

          Figure 1: The network topology of an operation scenario

   When a failure is detected in path i, we can restore user traffic to
   path j using existing protection schemes such as 1+1 protection and
   1:1 protection.

   However, since the user traffic is unprotected until the working path
   is repaired, some operators may take the following measures to
   protect the user service.

   1) After a single failure condition is detected on the working path
   i,

      1-1) Remove the protection group between path i and j.

      1-2) Create a new protection group between path j and k to protect
      user traffic.




Cui & Winter             Expires August 18, 2014                [Page 3]


Internet-DraftUse Cases and Requirements for MPLS-TP multi-February 2014


   2) The failure condition of working path is repaired,

      2-1) In order to clear the sharing resources, remove the
      relationship of protection group between path j and k.

      2-2) Re-create a protection group between path i and j.

   However, above progresses are very complex, may increase the risk for
   operation mistake and pressure.  An automatic restoration mechanism
   such as GMPLS [RFC3945], are well-known.  But some operators in
   particular in the transport sector that do not operate their MPLS
   networks under the control plane.  Therefore, we suggest that define
   a non-control-plane based protection scheme that allows an overlap
   between a protection group and other paths.

3.  Architecture

   Figure 2 shows a new protection domain with a single working path and
   N protection paths.  Each of the protection paths MAY be assigned a
   priority that could decide which protection path to use, i.e.
   protection path #1 > protection path #2, thus, the protection path #2
   will not be selected to deliver user traffic when protection path #1
   is available.

          +-----+                             +-----+
          |     |=============================|     |
          |LER-A|      Working Path           |LER-Z|
          |     |                             |     |
          |     |*****************************|     |
          |     |     Protection Path #1      |     |
          |     |                             |     |
          |     |*****************************|     |
          |     |     Protection Path #2      |     |
          |     |                             |     |
          |     |            ooo              |     |
          |     |                             |     |
          |     |*****************************|     |
          |     |     Protection Path #N      |     |
          +-----+                             +-----+
                |--------Protection Domain----|

           Figure 2: A basic example of multi-failure protection

4.  Requirements

   This section contains the requirements on the protection
   functionality derived from the problem statement and use case in
   section 2.



Cui & Winter             Expires August 18, 2014                [Page 4]


Internet-DraftUse Cases and Requirements for MPLS-TP multi-February 2014


4.1.  Configuration

   Before failure detection and/or notification, one or more protection
   paths are instantiated between the same ingress-egress node pair as
   the working path shown in figure 2.  The protection paths MAY be
   added or removed if necessary, but any performance degradation of
   user traffic should be avoided.

4.2.  Resource reservation

   The resource of the protection paths MAY be shared with other
   transport paths.  In this case, the multiple failure protection
   SHOULD be supported by a shared mesh protection solution.  The
   solution is out of scope of this document.

4.3.  Protection switching time

   Protection switching time refers to the transfer time (Tt) defined in
   [G.808.1] and recovery switching time defined in [RFC4427].  A
   multiple failure protection solution MUST support switching time
   within 50 ms from the moment of fault detection in a network.

5.  Security Considerations

   TBD

6.  IANA Considerations

   TBD

7.  Normative References

   [I-D.ietf-mpls-smp-requirements]
              Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., and G.
              Mirsky, "Requirements for MPLS Shared Mesh Protection",
              draft-ietf-mpls-smp-requirements-03 (work in progress),
              January 2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3945]  Mannie, E., "Generalized Multi-Protocol Label Switching
              (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC4427]  Mannie, E. and D. Papadimitriou, "Recovery (Protection and
              Restoration) Terminology for Generalized Multi-Protocol
              Label Switching (GMPLS)", RFC 4427, March 2006.




Cui & Winter             Expires August 18, 2014                [Page 5]


Internet-DraftUse Cases and Requirements for MPLS-TP multi-February 2014


   [RFC6378]  Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
              A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear
              Protection", RFC 6378, October 2011.

Authors' Addresses

   Zhenlong Cui
   NEC

   Email: c-sai@bx.jp.nec.com


   Rolf Winter
   NEC

   Email: Rolf.Winter@neclab.eu



































Cui & Winter             Expires August 18, 2014                [Page 6]


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