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]