[Docs] [txt|pdf] [Tracker] [WG] [Email] [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: 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]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/