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

Network Working Group                                             Z. Cui
Internet-Draft                                                 R. Winter
Intended status: Informational                                       NEC
Expires: April 25, 2014                                 October 22, 2013

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

Abstract

   This document describes the use cases and requirements for multi-
   failure protection (MFP) in MPLS-TP networks.  This document would be
   used to implement MFP for MPLS-TP data paths without any control
   plane.

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 April 25, 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.

Cui & Winter             Expires April 25, 2014                 [Page 1]
Internet-DrafUse Cases and Requirements for MPLS-TP multi-f October 2013

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Document scope  . . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Requirements notation . . . . . . . . . . . . . . . . . .   2
   2.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Single-failure condition  . . . . . . . . . . . . . . . .   3
     3.2.  Resource allocation failure condition . . . . . . . . . .   4
     3.3.  Multi-failure condition . . . . . . . . . . . . . . . . .   4
   4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Configuration . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Resource reservation  . . . . . . . . . . . . . . . . . .   4
     4.3.  Protection switching time . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

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 however is limited to 1+1 and 1:1 protection and not
   designed to handle multi-failure protection.

   This document describes use cases to clarify the utility and
   necessity of multi-failure survivability.  Based on these use cases,
   this document lists a number of requirements for protection
   functionality in support of multi-failure recovery.

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 control plane-based solutions such as
   using 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 focus of this document which defines a set of requirements for
   multi-failure protection not based on control plane support.

1.2.  Requirements notation

Cui & Winter             Expires April 25, 2014                 [Page 2]
Internet-DrafUse Cases and Requirements for MPLS-TP multi-f October 2013

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

   Figure 1 show a 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 does not be selected to deliver user traffic when protection
   path #1 is available.

   All examples will be based on the network topology in Figure 1, with
   a working path and the protection path referenced.  The end-points of
   the protection domain will be referred to as LER-A and LER-Z.

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

          |--------Protection Domain--------|

          Figure 1: A basic sample of multi-failure protetection

3.  Use Cases

3.1.  Single-failure condition

   Most failure cases in transport networks are caused by a single
   failure condition.  Common protection schemes include 1+1 protection
   and 1:N protection which can restore user traffic after a single
   failure condition.  Before the transport path is repaired, the user
   traffic is unprotected.  During this time, another failure (e.g. a
   human-error) could significantly affect the network.  Such multi-
   failure situations could put pressure on network operations.  A

Cui & Winter             Expires April 25, 2014                 [Page 3]
Internet-DrafUse Cases and Requirements for MPLS-TP multi-f October 2013

   multi-failure protection solution provisions one or more backup paths
   before multiple failure occur.

3.2.  Resource allocation failure condition

   In shared mesh protection ([I-D.ietf-mpls-smp-requirements]), when
   the reserved resources are allocated for a particular protection
   path, there may not be sufficient resources available for an
   additional protection path.  This then implies that if an additional
   working path triggers a protection switch, the resource allocation
   failure condition may be occurred.  If a sufficient resource
   available for an additional protection path, it may help for increase
   the utility of shared mesh protection.

3.3.  Multi-failure condition

   [RFC5654] mentions that MPLS-TP recovery must meet SLA requirements
   over multiple domains [Requirements 58].  When a single failure
   occurs in each domain, it could affect both the working path and the
   protection path.  A multi-failure protection solution might also be
   helpful in this case.

4.  Requirements

   This section contains the requirements on the protection
   functionality derived from the use-cases in section 3.

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 as shown in figure 1.  The protection paths MAY be
   added or removed when need, but should be avoided might miss any
   performance degradation of user traffic.

4.2.  Resource reservation

   The resource of the protection path 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.

Cui & Winter             Expires April 25, 2014                 [Page 4]
Internet-DrafUse Cases and Requirements for MPLS-TP multi-f October 2013

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., Mirsky, G.,
              Allan, D., King, D., and T. Cheung, "Requirements for MPLS
              Shared Mesh Protection", draft-ietf-mpls-smp-
              requirements-01 (work in progress), September 2013.

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

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

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

Authors' Addresses

   Zhenlong Cui
   NEC

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

   Rolf Winter
   NEC

   Email: Rolf.Winter@neclab.eu

Cui & Winter             Expires April 25, 2014                 [Page 5]