draft-ietf-mpls-tp-mfp-use-case-and-requirements-01.txt   draft-ietf-mpls-tp-mfp-use-case-and-requirements-02.txt 
Network Working Group Z. Cui Network Working Group Z. Cui
Internet-Draft R. Winter Internet-Draft R. Winter
Intended status: Informational NEC Updates: 5654 (if approved) NEC
Expires: February 4, 2017 H. Shah Intended status: Informational H. Shah
Ciena Expires: February 17, 2017 Ciena
S. Aldrin S. Aldrin
Huawei Technologies Huawei Technologies
M. Daikoku M. Daikoku
KDDI KDDI
August 3, 2016 August 16, 2016
Use Cases and Requirements for MPLS-TP multi-failure protection Use Cases and Requirements for MPLS-TP multi-failure protection
draft-ietf-mpls-tp-mfp-use-case-and-requirements-01 draft-ietf-mpls-tp-mfp-use-case-and-requirements-02
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. That linear protection mechanism has not been designed for defined. That linear protection mechanism has not been designed for
handling multiple, simultaneously occuring failures, i.e. multiple handling multiple, simultaneously occuring failures, i.e. multiple
failures that affect the working and the protection entity during the failures that affect the working and the protection entity during the
same time period. In these situations currently defined protection same time period. In these situations currently defined protection
mechanisms would fail. mechanisms would fail.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 February 4, 2017. This Internet-Draft will expire on February 17, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
1.2. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. General m:n protection scenario . . . . . . . . . . . . . . . 4 2. General m:n protection scenario . . . . . . . . . . . . . . . 4
3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. m:1 (m > 1) protection . . . . . . . . . . . . . . . . . 5 3.1. m:1 (m > 1) protection . . . . . . . . . . . . . . . . . 5
3.1.1. Pre-configuration . . . . . . . . . . . . . . . . . . 5 3.1.1. Pre-configuration . . . . . . . . . . . . . . . . . . 5
3.1.2. On-demand configuration . . . . . . . . . . . . . . . 6 3.1.2. On-demand configuration . . . . . . . . . . . . . . . 6
3.2. m:n (m, n > 1, n >= m > 1) protection . . . . . . . . . . 6 3.2. m:n (m, n > 1, n >= m > 1) protection . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Normative References . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
Today's packet optical transport networks concentrate large volumes Today's packet optical transport networks concentrate large volumes
of traffic onto a relatively small number of nodes and links. As a of traffic onto a relatively small number of nodes and links. As a
result, the failure of a single network element can potentially result, the failure of a single network element can potentially
interrupt a large amount of traffic. For this reason, ensuring interrupt a large amount of traffic. For this reason, ensuring
survivability through careful network design and appropriate survivability through careful network design and appropriate
technical means is important. technical means is important.
skipping to change at page 6, line 36 skipping to change at page 6, line 36
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
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.
4. Requirements 4. Requirements
A number of recovery requirements are defined in [RFC5654]. These Recovery requirements are defined in section 2.5 of RFC 5654
requirements however are limited to cover single failure case and not [RFC5654]. More specifically, RFC 5654 outlines protection
multiple, simultaneously occuring failures. This section extends the requirements in subsections 2.5.1.1. and 2.5.1.2. These however are
list of requirements to support multiple failures scenarios. limited to cover single failure cases and not multiple,
simultaneously occuring failures. This section extends the list of
requirements to support multiple failures scenarios.
R1. MPLS-TP SHOULD 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 1. An m:1 protection mechanism MUST protect against multiple
failures that are detected on both the working entity and one or failures that are detected on both the working entity and one or
more protection entities. more protection entities.
2. Pre-configuration of protection entities SHOULD be supported. 2. Pre-configuration of protection entities SHOULD be supported.
3. On-demand protection entity configuration MAY be supported. 3. On-demand protection entity configuration MAY be supported.
skipping to change at page 7, line 29 skipping to change at page 7, line 31
mechanisms. mechanisms.
5. 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]. The requirements described in channel are described in [RFC5586]. The requirements described in
this document are extensions to the requirements presented in this document are extensions to the requirements presented in
[RFC5654] and does not introduce any new security risks. [RFC5654] and does not introduce any new security risks.
6. Normative References 6. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
7. 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. 7 change blocks. 
12 lines changed or deleted 22 lines changed or added

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