Internet DRAFT - draft-suzuki-teas-actn-multidomain-opc
draft-suzuki-teas-actn-multidomain-opc
Network Working Group T. Suzuki
Internet-Draft Hitachi, Ltd.
Intended status: Informational July 6, 2015
Expires: January 7, 2016
Use-case and Requirements for Multi-domain Operation Plane Change
draft-suzuki-teas-actn-multidomain-opc-00
Abstract
This document provides a use-case and requirements that address the
need for facilitating dynamic change of an operation plane, which
includes virtually prepared multiple networks and/or data
transmission paths, from a current operation one to a backup one
during scheduled maintenance or an emergency such as a network
disaster. Specifically, the necessity of interfaces to establish
consistent end-to-end data transmission paths over multiple domain
networks is addressed.
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 January 7, 2016.
Copyright Notice
Copyright (c) 2015 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
Suzuki Expires January 7, 2016 [Page 1]
Internet-Draft Multi-domain Operation Plane Change July 2015
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirement for Interface of operation plane change system . . 7
4.1. Type I: Direct control interface between DNCs . . . . . . 7
4.2. Type II: Indirect control interface through MDNC . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Informative References . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Suzuki Expires January 7, 2016 [Page 2]
Internet-Draft Multi-domain Operation Plane Change July 2015
1. Introduction
This draft provides a use case and requirements that address the
necessity of a dynamic change of an operation plane, which includes
virtually prepared multiple networks and/or data transmission paths,
from a current operation one to a backup one through cooperation
between inter domain networks during scheduled maintenance or an
emergency such as a network disaster.
Networks have become indispensable in daily life, as reflected in the
popularity of cloud services provided by way of networks, such as the
Internet. Therefore, highly reliable end-to-end data transmission
services must be provided. In addition, even if network facilities
are extensively damaged due to a natural disaster, data transmission
services must be promptly restored. To meet these requirements, a
highly reliable packet transport network, such as the Multi-Protocol
Label Switching - Transport Profile (MPLS-TP) network, is needed and
may be used to transmit data between not only countries but also data
centers.
In conventional packet transport network management, a data
transmission path protection function is used for promptly recovering
from a small network failure, such as a node or link failure.
However, the path protection is not always usable in a network
disaster. Plenty of data transmission paths are calculated
sequentially after a network disaster is detected. As a result, much
time is needed to calculate all the paths. In another case, multiple
path configurations will be changed for maintenance to add, delete,
and check network resources. Therefore, a novel network management
scheme is needed to change plenty of path configurations
instantaneously from the current operation plane to the backup one.
Related documents are the ACTN-framework [ACTN-Framework], the
problem statement [ACTN-Problem] and the requirements
[ACTN-Requirement].
Section 2 discusses specific issues on the prompt changing of network
configurations. Section 3 describes a use case for an inter-domain
network management system. Section 4 prescribes requirements that
the system needs to satisfy.
Suzuki Expires January 7, 2016 [Page 3]
Internet-Draft Multi-domain Operation Plane Change July 2015
2. Problem Statement
There are two major techniques for recovering from network failures:
protection and restoration. In protection, a backup data
transmission path for a current one is calculated and set up before
network operations are started. When a data transmission failure is
detected, a data transmission path is changed from the current path
to the backup one. In restoration, the backup path is not physically
prepared in advance. When a data transmission failure is detected, a
new data transmission path is calculated and/or set up. Then data
are transmitted through the newly set up data path.
In a network disaster due to an earthquake, for example, protection
paths might not be useful for some situations. When the protection
paths are not useful, another backup path should be calculated. If
there are plenty of current data transmission paths, calculating the
backup paths takes an enormous amount of time. In the same way, a
huge amount of time is needed to calculate and to set up plenty of
paths for restoration.
Enhancement of protection is envisaged as a new recovery procedure
from a network disaster. Specifically, a concept of a virtual
operation plane is adopted. The virtual operation plane includes
multiple data transmission paths, and so does the current operation
plane. In contrast, a recovery operation plane includes multiple
backup data transmission paths. In the new recovery procedure,
multiple backup operation planes are prepared in advance. When a
network disaster is detected, the most suitable backup operation
plane is selected and configurations for recovery are distributed to
data transmission nodes.
In addition, a network system must be able to change plenty of path
configurations instantaneously when it adds or deletes network
resources or stops using resources to execute maintenance.
The system explained above can be easily managed if there is only one
management server. However, if the network is composed of multiple
domains and there are multiple management servers, coordinated
network disaster recovery procedures are not easy to execute.
Therefore, a cooperative management scheme for recovering from a
network disaster is needed.
Suzuki Expires January 7, 2016 [Page 4]
Internet-Draft Multi-domain Operation Plane Change July 2015
3. Use Case
A target operation plane change system through cooperation of
multiple domain controller servers is shown in Figure 1. The whole
network is composed of multiple domain networks such as domain-A and
domain-B physical networks. Each domain has a domain network
controller server. In addition, each domain network is composed of
multiple packet transport nodes. An end-to-end data transmission
path is managed through cooperation between domain network controller
servers. Each domain network controller server calculates multiple
current data transmission paths and manages them as one current
operation plane. In addition, the controller server calculates
multiple backup operation planes and controls them in the case of a
network disaster.
For example, the domain-A network controller server prepares a backup
operation plane, plane-A1, on the basis of the assumption of network
failures or maintenance. Plane-A1 includes multiple data
transmission paths or virtual networks. The domain-B network
controller server prepares another backup operation plane, plane-B1,
to connect data transmission paths to plane-A1 of the domain-A
network. On the other hand, the domain-B network controller server
prepares another backup operation plane, plane-B2, on the basis of
the assumption of other network failures or maintenance. The
domain-A network controller server prepares another backup operation
plane, plane-A2, to connect data transmission paths to plane-B2 of
the domain-B network.
When the domain-A network controller server changes the operation
plane from the current operation one to plane-A1 during the network
operation, it transmits an identifier of plane-A1 to the domain-B
network controller server to show a change of the operation plane of
the domain-A network controller server. After receiving the
identifier of plane-A1, the domain-B network controller server
changes the operation plane from the current one to plane-B1.
To develop the above-mentioned system, two interfaces must be
created. One maintains consistency of the end-to-end data
transmission paths between domains in the backup operation plane.
Specifically, this interface needs to transmit information of the
backup operation planes including multiple data transmission paths
from one domain network controller server to another. The other
domain network controller server can then calculate backup operation
planes in accordance with the received backup operation plane
information. The other interface is used for transmitting the
identifier to change the operation plane from one domain network
controller server to another.
Suzuki Expires January 7, 2016 [Page 5]
Internet-Draft Multi-domain Operation Plane Change July 2015
+--------------------+ +--------------------+
| Domain-A network | | Domain-B network |
| controller server | | controller server |
+---------+----------+ +---------+----------+
| |
| |
+------------+-------------+ +-----------+--------------+
| | | |
| +--------------------+ | | +--------------------+ |
| | Current +----------+ Current | |
| | operation plane +----------+ operation plane | |
| | A0 +----------+ B0 | |
| +--------------------+ | | +--------------------+ |
| | | |
| ======================== | | ======================== |
| | | |
| +--------------------+ | | +--------------------+ |
| | Backup +----------+ Backup | |
| | operation plane +----------+ operation plane | |
| | A1 +----------+ B1 | |
| +--------------------+ | | +--------------------+ |
| | | |
| +--------------------+ | | +--------------------+ |
| | Backup +----------+ Backup | |
| | operation plane +----------+ operation plane | |
| | A2 +----------+ B2 | |
| +--------------------+ | | +--------------------+ |
| - | | - |
| - | | - |
| - | | - |
| +--------------------+ | | +--------------------+ |
| | Backup +----------+ Backup | |
| | operation plane +----------+ operation plane | |
| | An +----------+ Bn | |
| +--------------------+ | | +--------------------+ |
| | | |
+--------------------------+ +--------------------------+
Domain-A physical network Domain-B physical network
Figure 1: Example of target operation plane change system
Suzuki Expires January 7, 2016 [Page 6]
Internet-Draft Multi-domain Operation Plane Change July 2015
4. Requirement for Interface of operation plane change system
There are two types of control structures. One is a direct
communication type between domain network controllers (DNCs) as shown
in Figure 2. The other is an indirect communication type through a
multi-domain network controller (MDNC) as shown in Figure 3. To
realize an operation plane change system, the interfaces shown in
either figure must be defined.
4.1. Type I: Direct control interface between DNCs
The interfaces shown in Figure 2 must be prepared to execute
consistent changing of operation planes to establish end-to-end data
transmission paths between multiple domain networks for network
disaster recovery or maintenance. The requirements for each
interface are briefly described below.
(I-1) Interface for preparing backup operation planes:
This interface is used to prepare consistent backup operation
planes through cooperation between DNCs. For example, the
domain-A network controller (DNC-A) prepares multiple backup
operation planes as shown in Figure 1 for the current operation
plane composed of multiple data transmission paths. A backup
operation plane is prepared for each assumed network failure or
maintenance. The DNC-A transmits "information of sharing paths
for each link between domain networks" and "the identifier of a
backup operation plane" to the domain-B network controller
(DNC-B) when it attempts to change the operation plane to
recover from a network disaster or to execute maintenance.
When the DNC-B controller receives them, it prepares a backup
operation plane for each received DNC-A backup plane to
establish consistent data transmission paths. In addition,
configurations of prepared backup operation planes are stored.
(I-2) Interface for requesting change of operation plane:
This interface is used to send a change request of the
operation plane from the current one to the backup one when a
DNC detects a network disaster or starts to execute
maintenance. For example, when the DNC-A detects a network
disaster, it determines the most suitable backup operation
plane and starts management in accordance with the
configurations of the selected operation plane. In addition,
the DNC-A transmits "the identifier of the backup operation
plane" to the DNC-B to establish consistent end-to-end paths
when it changes the operation plane. When the DNC-B receives
the identifier of the backup operation plane, it changes the
operation plane from the current one to the backup one
specified by the received identifier. In addition, information
Suzuki Expires January 7, 2016 [Page 7]
Internet-Draft Multi-domain Operation Plane Change July 2015
of the time to change path configurations is exchanged through
this interface between DNCs.
+--------------------+ (I-1)I/F +--------------------+
| Domain-A network | (I-2)I/F | Domain-B network |
| controller (DNC-A) |<--------->| controller (DNC-B) |
+---------+----------+ +---------+----------+
| |
| |
+------------+-------------+ +------------+-------------+
| +-----+ |
| Domain-A +-----+ Domain-B |
| physical network +-----+ physical network |
+--------------------------+ +--------------------------+
Links
Figure 2: Control structure type I
4.2. Type II: Indirect control interface through MDNC
In the case of the type II control communication structure, the
interfaces shown in Figure 3 must be prepared to execute consistent
changing of operation planes to establish end-to-end data
transmission paths between multiple domain networks for network
disaster recovery or maintenance. The requirements for each
interface are briefly described below.
(II-1) Interface to MDNC for preparing backup operation planes:
This interface is used to prepare consistent backup operation
planes through cooperation between DNCs through the MDNC. For
example, the DNC-A prepares multiple backup operation planes
for the current operation plane composed of multiple data
transmission paths. A backup operation plane is prepared for
each assumed network failure or maintenance. The DNC-A
transmits "information of sharing paths for each link between
domains" and "the identifier of a backup operation plane" to
the MDNC in order to send the information to the DNC-B as a
final destination.
(II-2) Interface to MDNC for requesting change of operation plane:
This interface is used to send a change of the operation plane
from the current one to the backup one when a DNC detects a
network disaster or starts to execute maintenance. For
Suzuki Expires January 7, 2016 [Page 8]
Internet-Draft Multi-domain Operation Plane Change July 2015
example, when the DNC-A detects a network disaster, it
determines the most suitable backup operation plane and starts
management in accordance with the configurations of the
selected operation plane. In addition, the DNC-A transmits
"the identifier of the backup operation plane" to the MDNC to
establish consistent end-to-end paths in order to send the
identifier to the DNC-B as a final destination.
(II-3) Interface to DNC for preparing backup operation planes:
This interface is used to prepare consistent backup operation
planes by cooperation between DNCs through the MDNC. For
example, the MDNC transmits received "information of sharing
paths for each link between domains" and "the identifier of a
backup operation plane" to the DNC-B. When the DNC-B receives
them, it prepares a backup operation plane for each received
DNC-A backup plane to establish consistent data transmission
paths. In addition, configurations of prepared backup
operation planes are stored.
(II-4) Interface to DNC for requesting change of operation plane:
This interface is used to send a change of the operation plane
from the current one to the backup one. For example, the MDNC
transmits received "the identifier of the backup operation
plane" to the DNC-B. When the DNC-B receives the identifier,
it changes the operation plane from the current one to the
backup one specified by the received identifier. In addition,
information of the time to change path configurations is sent
through this interface from the MDNC to the DNC-B.
Suzuki Expires January 7, 2016 [Page 9]
Internet-Draft Multi-domain Operation Plane Change July 2015
+-----------------------------------------------------+
| Multi-domain network controller (MDNC) |
+------------------------------------------+----------+
^ |
:(II-1)I/F |(II-3)I/F
:(II-2)I/F |(II-4)I/F
: v
+--------------------+ +--------------------+
| Domain-A network | | Domain-B network |
| controller (DNC-A) | | controller (DNC-B) |
+---------+----------+ +---------+----------+
| |
| |
+------------+-------------+ +------------+-------------+
| +-----+ |
| Domain-A +-----+ Domain-B |
| physical network +-----+ physical network |
+--------------------------+ +--------------------------+
Links
Figure 3: Control structure type II
Suzuki Expires January 7, 2016 [Page 10]
Internet-Draft Multi-domain Operation Plane Change July 2015
5. Security Considerations
This document describes problems and requirements for network
disaster recovery or maintenance through cooperation between domain
management functions or servers. The system might be composed of
multiple management functions to manage each domain network, and each
management function might be implemented in different computational
equipment. To achieve network disaster recovery through coordination
between multiple network domains, information must be exchanged
between them. Therefore, a secure communication channel needs to be
used between the domain management functions.
Suzuki Expires January 7, 2016 [Page 11]
Internet-Draft Multi-domain Operation Plane Change July 2015
6. IANA Considerations
This document includes no request for IANA.
Suzuki Expires January 7, 2016 [Page 12]
Internet-Draft Multi-domain Operation Plane Change July 2015
7. Informative References
[ACTN-Framework]
Ceccarelli, D., Lee, Y., Fang, L., Lopez, D., Belotti,
S., King, D., and D. Dhoddy, "Framework for Abstraction
and Control of Transport Networks", June 2015.
<http://tools.ietf.org/pdf/
draft-ceccarelli-teas-actn-framework-00>
[ACTN-Problem]
Lee, Y., King, D., Boucadair, M., Jing, R., and L.
Murillo, "Problem Statement for Abstraction and Control of
Transport Networks", June 2015.
<http://tools.ietf.org/pdf/
draft-leeking-teas-actn-problem-statement-00>
[ACTN-Requirement]
Lee, Y., Belotti, S., Pithewan, K., and D. Ceccarelli,
"Requirements for Abstraction and Control of Transport
Networks", April 2015.
<https://tools.ietf.org/pdf/
draft-lee-teas-actn-requirements-00>
Suzuki Expires January 7, 2016 [Page 13]
Internet-Draft Multi-domain Operation Plane Change July 2015
Author's Address
Toshiaki Suzuki
Research & Development Group, Hitachi, Ltd.
292 Yoshida-cho
Totsuka-ku, Yokohama, Kanagawa 244-0817
Japan
Phone: +81-50-3135-3066
Email: toshiaki.suzuki.cs@hitachi.com
Suzuki Expires January 7, 2016 [Page 14]
