draft-cui-mpls-tp-mfp-use-case-and-requirements-04.txt   draft-cui-mpls-tp-mfp-use-case-and-requirements-05.txt 
Network Working Group Z. Cui Network Working Group Z. Cui
Internet-Draft R. Winter Internet-Draft R. Winter
Intended status: Standards Track NEC Intended status: Informational NEC
Expires: September 10, 2015 H. Shah Expires: January 7, 2016 H. Shah
Ciena Ciena
S. Aldrin S. Aldrin
Huawei Technologies Huawei Technologies
M. Daikoku M. Daikoku
KDDI KDDI
March 9, 2015 July 6, 2015
Use Cases and Requirements for MPLS-TP multi-failure protection Use Cases and Requirements for MPLS-TP multi-failure protection
draft-cui-mpls-tp-mfp-use-case-and-requirements-04 draft-cui-mpls-tp-mfp-use-case-and-requirements-05
Abstract Abstract
For the Multiprotocol Label Switching Transport Profile (MPLS-TP) For the Multiprotocol Label Switching Transport Profile (MPLS-TP)
linear protection capable of 1+1 and 1:1 protection has already been linear protection capable of 1+1 and 1:1 protection has already been
defined in [RFC6378], [RFC7271] and [RFC7324]. That linear defined. That linear protection mechanism has not been designed for
protection mechanism has not been designed for handling multiple, handling multiple, simultaneously occuring failures, i.e. multiple
simultaneously occurring failures, e.g., multiple failures that failures that affect the working and the protection entity during the
affect the working and the protection entity during the same time same time period. In these situations currently defined protection
period. In these situations currently defined protection mechanisms mechanisms would fail.
would fail.
This document introduces use cases and requirements for mechanisms This document introduces use cases and requirements for mechanisms
that are capable of protecting against such failures. It does not that are capable of protecting against such failures. It does not
specify a protection mechanism itself. specify a multi-failure protection mechanism itself.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Document scope . . . . . . . . . . . . . . . . . . . . . 3 1.1. Document scope . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and References . . . . . . . . . . . . . . . . . 3 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 3
3. General m:n protection scenario . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. General m:n protection scenario . . . . . . . . . . . . . . . 4
4.1. m:1 (m > 1) protection . . . . . . . . . . . . . . . . . 5 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Pre-configuration . . . . . . . . . . . . . . . . . . 5 3.1. m:1 (m > 1) protection . . . . . . . . . . . . . . . . . 5
4.1.2. On-demand configuration . . . . . . . . . . . . . . . 6 3.1.1. Pre-configuration . . . . . . . . . . . . . . . . . . 5
4.2. m:n (m, n > 1, n >= m > 1) protection . . . . . . . . . . 6 3.1.2. On-demand configuration . . . . . . . . . . . . . . . 6
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. m:n (m, n > 1, n >= m > 1) protection . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
Today's businesses require reliable network connectivity and access Today's packet optical transport networks concentrate large volumes
to corporate resources. Connections to and from business units, of traffic onto a relatively small number of nodes and links. As a
vendors and SOHOs are all equally important to keep the continuity result, the failure of a single network element can potentially
when needed. Business runs all day, every day and even in off hours. interrupt a large amount of traffic. For this reason, ensuring
So, the network connectivity needs to keep all the time. This is survivability through careful network design and appropriate
sometimes referred to five nines (99.999%) uptime in a time period. technical means is important.
For this reason, ensuring survivability through careful network
design and appropriate technical means is important.
In MPLS-TP networks, a basic survivability technique is available as In MPLS-TP networks, a basic survivability technique is available as
specified in [RFC6378], [RFC7271] and [RFC7324]. That protocol specified in [RFC6378], [RFC7271] and [RFC7324]. That protocol
however is limited to 1+1 and 1:1 protection and not designed to however is limited to 1+1 and 1:1 protection and not designed to
handle multiple failures that affect both the working and protection handle multiple failures that affect both the working and protection
entity at the same time. entity at the same time.
There are various situations where above multiple failures to be There are various scenarios where multi-failure protection is an
considered, e.g., after catastrophic events such as earthquakes or important requirement for network survivability. E.g for disaster
tsunamis. During the period after such events, network availability recovery, after catastrophic events such as earthquakes or tsunamis.
is crucial, in particular for high-priority services such as During the period after such events, network availability is crucial,
emergency telephone calls. Existing 1+1 or 1:n protection however is in particular for high-priority services such as emergency telephone
limited to cover single failures which has proven as not sufficient calls. Existing 1+1 or 1:n protection however is limited to cover
during past events. single failures which has proven as not sufficient during past
events.
Beyond the natural disaster case above, when a working entity or Beyond the natural disaster use case above, multi-failure protection
protection entity was closed for maintenance or construction work, is also beneficial in situations where the network is particularly
the network service becomes vulnerable to single failure since one vulnerable, e.g., when a working entity or protection entity was
closed for maintenance or construction work. During this time, the
network service becomes vulnerable to single failures since one
entity is already down. If a failure occurs during this time, an entity is already down. If a failure occurs during this time, an
operator might not be able to meet service level agreements (SLA). operator might not be ablt to meet service level agreements (SLA).
Thus, a technical means for multi-failure protection could take
[RFC5654] establishes that MPLS-TP SHOULD MUST support 1+1 protection pressure off network operations.
and 1:n protection (including 1:1 protection). This document
provides an expansion of the basic requirements of MPLS-TP presented
in [RFC5654] for supports m:1 and m:n protection for recovers user
traffic after several failures occurred on both the working and
protection entity at the same time.
1.1. Document scope 1.1. Document scope
This document describes use cases and requirements for m:1 and m:n This document describes use cases and requirements for m:1 and m:n
protection in MPLS-TP networks without the use of control plane protection in MPLS-TP networks without the use of control plane
protocols. Existing solutions based on a control plane such as GMPLS protocols. Existing solutions based on a control plane such as GMPLS
may be able to restore user traffic when multiple failures occur. may be able to restore user traffic when multiple failures occur.
Some networks however do not use full control plane operation for Some networks however do not use full control plane operation for
reasons such as service provider preferences, certain limitations or reasons such as service provider preferences, certain limitations or
the requirement for fast service restoration (faster than achievable the requirement for fast service restoration (faster than achievable
with control plane mechanisms). These networks are the focus of this with control plane mechanisms). These networks are the focus of this
document which defines a set of requirements for m:1 and m:n document which defines a set of requirements for m:1 and m:n
protection not based on control plane support. protection not based on control plane support. This document imposes
no formal time constraints on detection times.
2. Terminology and References 1.2. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD","SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD","SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.3. Terminology
The terminology used in this document is based on the terminology The terminology used in this document is based on the terminology
defined in the MPLS-TP Survivability Framework document [RFC6372], defined in the MPLS-TP Survivability Framework document [RFC6372],
which in turn is based on [RFC4427]. which in turn is based on [RFC4427].
In particular, the following protection types are made in [RFC4427]. In particular, the following protection schemes are defined in
[RFC4427] and used as terms in this document:
o 1+1 protection o 1+1 protection
o 1:n (n >= 1) protection o 1:n (n >= 1) protection
o m:n (m, n > 1, n >= m > 1) protection o m:n (m, n > 1, n >= m > 1) protection
In this document, the following additional terminology is applied: o Further, the following additional terminology is from [RFC4427] is
used:
o "broadcast bridge", defined in [RFC4427]. o "broadcast bridge"
o "selector bridge", defined in [RFC4427]. o "selector bridge"
o "working entity", defined in [RFC4427]. o "working entity"
o "protection entity", defined in [RFC4427]. o "protection entity"
This document defines a new protection type: This document defines a new protection type:
o m:1 (m > 1) protection: A set of m protection entities protects a o m:1 (m > 1) protection: A set of m protection entities protecting
working entity. a single working entity
3. General m:n protection scenario 2. General m:n protection scenario
The general underlying assumption of this work is that an m:n The general underlying assumption of this work is that an m:n
relationship between protection entity and working entity exists, relationship between protection entity and working entity exists,
i.e. there is no artificial limitation on the ratio between i.e. there is no artificial limitation on the ratio between
protection and working entities. protection and working entities.
This general scenario is illustrated in Figure 1 which shows a This general scenario is illustrated in Figure 1 which shows a
protection domain with n working entities and m protection entities protection domain with n working entities and m protection entities
between Node A and Node Z. between Node A and Node Z.
At the Node A and in the absence of faults, traffic is transported At Node A, traffic is transported over its respective working entity
over its respective working entity and may be simultaneously and may be simultaneously transported over one of its protection
transported over one of its protection entities (in case of a entities (in case of a broadcast bridge), or it is transported over
broadcast bridge), or it is transported over its working entity and its working entity and only in case of failure over one of the
only in case of failure over one of the protection entities (in case protection entities (in case of a selector bridge). At Node Z, the
of a selector bridge). At the Node Z, the traffic is selected from traffic is selected from either its working entity or one of the
either its working entity or one of the protection entities. protection entities.
+------+ +------+ +------+ +------+
|Node A| working entity #1 |Node Z| |Node A| working entity #1 |Node Z|
| |=============================| | | |=============================| |
| | .... | | | | .... | |
| | working entity #n | | | | working entity #n | |
| |=============================| | | |=============================| |
| | | | | | | |
| | | | | | | |
| | protection entity #1 | | | | protection entity #1 | |
| |*****************************| | | |*****************************| |
| | .... | | | | .... | |
| | protection entity #m | | | | protection entity #m | |
| |*****************************| | | |*****************************| |
+------+ +------+ +------+ +------+
|--------Protection Domain--------| |--------Protection Domain--------|
Figure 1: m:n protection domain Figure 1: m:n protection domain
4. Use cases 3. Use cases
4.1. m:1 (m > 1) protection 3.1. m:1 (m > 1) protection
With MPLS-TP linear protection such as 1+1/1:1 protection, when a With MPLS-TP linear protection such as 1+1/1:1 protection, when a
single failure is detected on the working entity, the service can be single failure is detected on the working entity, the service can be
restored using the protection entity. During this time however, the restored using the protection entity. During this time however, the
traffic is unprotected until the working entity is restored. traffic is unprotected until the working entity is restored.
m:1 protection can increase service availability and reduce m:1 protection can increase service availability and reduce
operational pressure since multiple protection entities are operational pressure since multiple protection entities are
available. For any m > 1, m - 1 protection entities may fail and the available. For any m > 1, m - 1 protection entities may fail and the
service still would have a protection entity available. service still would have a protection entity available.
There are different ways to provision these alternative protection There are different ways to provision these alternative protection
entities which are outlined in the following sub-sections. entities which are outlined in the following sub-sections.
4.1.1. Pre-configuration 3.1.1. Pre-configuration
The relationship between the working entity and the protection The relationship between the working entity and the protection
entities is part of the system configuration and needs to be entities is part of the system configuration and needs to be
configured before the working entity is being used. The same applies configured before the working entity is being used. The same applies
to additional protection entities. to additional protection entities.
Unprotected traffic can be transported over the m protection entities Unprotected traffic can be transported over the m protection entities
as long as these entities do not carry protected traffic. as long as these entities do not carry protected traffic.
4.1.2. On-demand configuration 3.1.2. On-demand configuration
The protection relationship between a working entity and a protection The protection relationship between a working entity and a protection
entity is configured while the system is in operation. entity is configured while the system is in operation.
Additional protection entities are configured by either a control Additional protection entities are configured by either a control
plane protocol or static configuration using a management system plane protocol or static configuration using a management system
directly after failure detection and/or notification of either the directly after failure detection and/or notification of either the
working entity or the protection entity. working entity or the protection entities.
4.2. m:n (m, n > 1, n >= m > 1) protection 3.2. m:n (m, n > 1, n >= m > 1) protection
In order to reduce the cost of protection entities, in the m:n In order to reduce the cost of protection entities, in the m:n
scenario, m dedicated protection transport entities are sharing scenario, m dedicated protection transport entities are sharing
protection resources for n working transport entities. protection resources for n working transport entities.
The bandwidth of each protection entity should be allocated in such a The bandwidth of each protection entity should be allocated in such a
way that it may be possible to protect any of the n working entities way that it may be possible to protect any of the n working entities
in case at least one of the m protection entities is available. When in case at least one of the m protection entities is available. When
a working entity is determined to be impaired, its traffic first must a working entity is determined to be impaired, its traffic first must
be assigned to an available protection transport entity followed by a be assigned to an available protection transport entity followed by a
transition from the working to the assigned protection entity at both transition from the working to the assigned protection entity at both
the Node A and Node Z of the protected domain. It is noted that when Node A and Node Z of the protected domain. It is noted that when
more than m working entities are impaired, only m working entities more than m working entities are impaired, only m working entities
can be protected. can be protected.
5. Requirements 4. Requirements
A number of recovery requirements are defined in [RFC5654]. These A number of recovery requirements are defined in [RFC5654]. These
requirements however are limited to cover single failure case and not requirements however are limited to cover single failure case and not
multiple, simultaneously occurring failures. This section extends multiple, simultaneously occuring failures. This section extends the
the list of requirements to support multiple failures scenarios. list of requirements to support multiple failures scenarios.
R1. MPLS-TP MUST support m:1 (m > 1) protection. R1. MPLS-TP SHOULD support m:1 (m > 1) protection.
1 An m:1 protection mechanism MUST protect against multiple failures 1. An m:1 protection mechanism MUST protect against multiple
that are detected on both the working path and one or more failures that are detected on both the working entity and one or
protection paths. more protection entities.
2 Pre-configuration of protection paths SHOULD be supported. 2. Pre-configuration of protection entities SHOULD be supported.
3 On-demand protection path configuration MAY be supported. 3. On-demand protection entity configuration MAY be supported.
4 On-demand protection resource activation MAY be supported. 4. On-demand protection resource activation MAY be supported.
5 A priority scheme MUST be provided, since a protection path has to 5. A priority scheme MUST be provided, since a protection entity has
chosen out of two or more protection paths. to be chosen out of two or more protection entities.
R2. MPLS-TP MUST support m:n (m, n > 1, n >= m > 1) protection. R2. MPLS-TP SHOULD support m:n (m, n > 1, n >= m > 1) protection.
1 An m:n protection mechanism MUST protect against multiple failures 1. An m:n protection mechanism MUST protect against multiple
that are simultaneously detected on both a working path and failures that are simultaneously detected on both a working
protection path or multiple working paths. entity and a protection entity or multiple working entities.
2 A priority scheme MUST be provided, since protection resources are 2. A priority scheme MUST be provided, since protection resources
shared by multiple working paths dynamically. are shared by multiple working entities dynamically.
6. Security Considerations 5. Security Considerations
General security considerations for MPLS-TP are covered in [RFC5921]. General security considerations for MPLS-TP are covered in [RFC5921].
The security considerations for the generic associated control The security considerations for the generic associated control
channel are described in [RFC5586]. channel are described in [RFC5586]. The requirements described in
this document are extensions to the requirements presented in
The requirements described in this document are extensions to the [RFC5654] and does not introduce any new security risks.
requirements presented in [RFC5654] and does not introduce any new
security risks.
7. Normative References 6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and
Restoration) Terminology for Generalized Multi-Protocol Restoration) Terminology for Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4427, March 2006. Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009. Associated Channel", RFC 5586, June 2009.
 End of changes. 46 change blocks. 
99 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/