Internet DRAFT - draft-fu-nfvrg-hierarchical-orchestraotr
draft-fu-nfvrg-hierarchical-orchestraotr
Internet Engineering Task Force Q. Fu, Ed.
Internet-Draft China Mobile
Intended status: Informational October 19, 2015
Expires: April 21, 2016
Framework of Hierarchical Orchestrator in NFV Deployment
draft-fu-nfvrg-hierarchical-orchestraotr-00
Abstract
This document discusses about the framework of Orchestrator in the
NFV deployment. A hierarchical framework of Orchestrator is then
proposed. Such framework is very important for large scale NFV
deployment in Operator networks, since multi-site of NFV deployment
and management should be considered. This draft will further discuss
the responsibilities of the multi-layers of the Orchestrator and the
interfaces between them.
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 21, 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
include Simplified BSD License text as described in Section 4.e of
Fu Expires April 21, 2016 [Page 1]
Internet-Draft Hierarchical Orchestrator October 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Framework of Hierarchical Orchestrator . . . . . . . . . . . 3
4. Responsibilities of Hierarchical Orchestrator . . . . . . . . 4
5. Interface between the Hierarchical Orchestrator . . . . . . . 6
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Informative References . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
In the NFV architecture defined by ETSI NFV ISG, the Orchestrator has
two responsibilities as follows:
1) the orchestration of NFVI resources across multiple VIMs,
fulfilling the Resource Orchestration (RO) functions described in
section 4.2 of [NFVMAN001]
2) the lifecycle management of Network Services (NS), fulfilling the
Network Service Orchestration functions described in section 4.4 of
[NFVMAN001]
The Orchestrator is the key point of NFV deployment within Operator's
Networks, since it is responsible for deploying the virtualized
services and forwarding graphs in one or multiple NFV sites.
Meanwhile, it also interfaces with the OSS/BSS, which is responsible
for network management within the operators' network of both the VNFs
(Virtual Network Function) and also the lagecy network functions.
How to deploy the Orchestrator, so as to simplify the management and
orchestration of VNFs on the one hand, and be compatible with the
lagecy network management system on the other hand, becomes an
important issue.
In this document, we will first discuss about the NFV deployment in
the operators' network, and propose an hierarchical orchestrator
framework. Responsibilities of the different layers of orchestrator,
and their interfaces will be discussed afterwards.
2. Terminology
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].
Fu Expires April 21, 2016 [Page 2]
Internet-Draft Hierarchical Orchestrator October 2015
3. Framework of Hierarchical Orchestrator
Large scale deployment of NFV in the operators' network will require
the NFV structure to be deployed in multiple sites. This is because
VNFs of different kinds should be deployed in different Data Center.
VNFs for access and aggregate networks, e.g. vBRAS, vCPE, will be
deployed in reginal DC, near the customer ends. While VNFs for Core
networks may be deployed in centralized DC with limited numbers.
The multisite distribution of the VNFs requires an hierarchical
framework of Orchestrator. Figure 1 shows this hierarchical
framework, in which the lower layer Orchestrator are deployed in
local DCs where VNFs are deployed, and the higher level Orchestrator
are deployed in a more centralized position and is interfaced with
the OSS/BSS. The higher layer Orchestrator is named as "Super-
Orchestrator (S-Orchestrator)" in the following text. And the lower
layer Orchestrator is named as "Reginal Orchestrator
(R-Orchestrator)".
Such framework can also be extended to three or more layers, based on
the number of the NFV sites. In multi-layer deployments, only the
lower layer should be the R-Orchestrator. All the upper-layers
should be S-Orchestrator and should be responsible for supervising
the under-layer Orchestrator. That is to say, the S-Orchestrator in
the middle layers are acting as S-Orchestrator to the under-layer and
R-Orchestrator to the upper-layer.
+---------+
| OSS/BSS |
+----+----+
|
+------------+------------+
| Super-Orchestrator |
+-+---------+-----------+-+
| | |
+----+ | +---+
| | |
+-----+------+ +-----+------+ +------+-----+
| Reginal | | Reginal | | Reginal |
|Orchestrator| |Orchestrator| |Orchestrator|
+------------+ +------------+ +------------+
Figure 1: Hierarchical Orchestrator Framework
In this hierarchical Orchestrator deployment, the responsiblity of
the S-Orchestrator and the R-Orchestrator can be different. The
interface between them is required. In the following sections, we
will discuss about the responsibilities and interfaces in detail.
Fu Expires April 21, 2016 [Page 3]
Internet-Draft Hierarchical Orchestrator October 2015
4. Responsibilities of Hierarchical Orchestrator
In this hierarchical Orchestrator framework, the S-Orchestrator is
designed to be more complicated, so as to maintain the full topology
of the network, and orchestrate the network in a higher lavel. The
R-Orchestrator is designed to be more general, so as to orchestrate
VNFs within the reginal DC. The S-Orchestrator should also support
all the functions of the R-Orchestrator. Therefore it can also act
as the R-Orchestrator of the DC it deployed.
There could be two approaches of deploying the S-Orchestrator. It
can be deployed in a certral DC which is only responsible for
supervising the whole network. Or it could be deployed in a reginal
DC, and is acting as the R-Orchestrator for that DC, while in the
mean time manages and orchestrates the whole network.
The responsibilities of the R-Orchestrator are listed as follows:
1) Deployment and orchestration of VNFs within the reginal DC. The
R-Orchestrator should be responsible for deploying VNFs and the
related network in the reginal DC according to the VNFD (VNF
Discriptor), the NSD (Network Service Discriptor), the VNF FGD(VNF
Forwarding Graph Discriptor), and the VLD (Virtual Link Discriptor)
download from the S-Orchestrator.
2) Monitoring and Providing the local VNF topology within the reginal
DC. The R-Orchestrator should be responsible for monitoring the
topology within the reginal DC. It can display such topology to the
administrator, and can also upload the topology to the
S-Orchestration for supervision from the upper level. The
R-Orchestrator is also responsible of restore the topology according
to the NFV deployment requirement the S-Orchestrator distributes.
3) Upgrade the VNFs within the reginal DC. It is the
R-Orchestrator's responsibility to upgrade the VNFs. The
R-Orchestrator should make the decision of when and how to do the
upgrade based on its own service and network situation. It should
inform the S-Orchestrator of the upgrade in advance. Service should
not be interupted during the upgrade.
4) Fault monitoring and management within the reginal DC. The
R-Orchestrator should be responsible for the fault monitoring and
management within the reginal DC. The NFVI fault and VNF fault and
failure should be reported to the R-Orchestrator, eventhough it may
be the VIM and the VNFM that take the action of repairing. The
R-Orchestrator should report to the S-Orchestrator for failures
itself can't recover.
Fu Expires April 21, 2016 [Page 4]
Internet-Draft Hierarchical Orchestrator October 2015
The responsibilities of the S-Orchestrator are listed as follows:
1) Deployment and Orchestration of VNFs in the whole NFV deployment.
The S-Orchestrator receives NFV deployment order from OSS/BSS. Such
requirement should be described by multiple VNFD, NSD, VNF FGD, and
VLD. The S-Orchestrator shoule be aware of the R-Orchestrator and
their distribution topology. The S-Orchestrator should translate the
full network deployment requirement into reginal NFV deployment, and
distributed to the R-Orchestrators. Such reginal NFV deployment
requirement may include a list of multiple VNF deployments and VNF
network deployment requirements, also discribed in VNFD, NSD, VNF
FGD, and VLD. The S-Orchestrator may download these requirements to
the R-Orchestrator item by item, or in a packet way which the
R-Orchestrator can understand.
2) Maintain the complete topology of the VNFs in the network. The
S-Orchestrator can derive the reginal topology from the
R-Orchestrator, and organizes them into a complete network topology.
The R-Orchestrator should be responsible to inform the S-Orchestrator
of any topology changes. However, the R-Orchestrator should restore
its reginal topology according to the NFV deployment requirement
automatically.
3) Providing the VNF image files. It is the S-Orchestrator's
responsibility to preserve and distribute the VNF images to be
deployed or upgraded within the whole network. The R-Orchestrator
can request these image file for deployment and upgrade. Such
restriction is defined so that the S-Orchestrator can have the full
knowledge and control of the VNF images deployed within the network.
However, it brings aditional reliability and availability issues,
since the disruption of the image files will bring VNF deployment and
upgrade incapability. Therefore, the storage of the VNF image files
should be highly available and reliable.
4) Fault monitoring and management of the whole network. The
S-Ochestrator should monitor and manage the fault and failure
reported by the R-Orchestrator. We expect the R-Orchestrator to
manage the failure within its own reginal DC. While the
S-Ochestrator will only take this responsibility when the
R-Orchestrator reports failure it can't recovery. These may be
catastrophic damages, such as earthquack. And the S-Orchestrator
will take the responsibility of recovering the whole site of the
reginal DC.
5) Building Geographic Redundancy (GR) of specific DC. The
S-Orchestrator should also be responsible for requesting GR for a
specific reginal DC. The specific reginal DC will then have a
redundant site which copies all of its VNF services and data.
Fu Expires April 21, 2016 [Page 5]
Internet-Draft Hierarchical Orchestrator October 2015
Failure of the active reginal DC will trigger the failover to the
redundant site without service loss.
5. Interface between the Hierarchical Orchestrator
Interface between the S-Orchestrator and the R-Orchestrator should be
well defined. Such interface should support the following actions:
1)R-Orchestrator signing up to the S-Orchestrator. The
R-Orchestrator should sign up to the S-Orchestrator once it is
deployed. Here we assum the VIM has already been deployed and the
R-Orchestrator is deployed and finish the initial management of the
VIM. The R-Orchestrator will then sign up to the S-Orchestrator,
meaning that this reginal NFV DC site is complete and ready for
deploying VNFs.
2)S-Orchestrator downloading of VNFD, NSD, VNF FGD, and VLD.
3)R-Orchestrator uploading of topology of reginal DC.
4)R-Orchestrator reporting of failure.
5)S-Orchestrator configuration of GR site.
6. Conclusion
In this document, a hierarchical framework of Orchestrator deployment
is proposed. Such framework is quite practical in large scale NFV
deployment in the Operators' network. The responsibilities of the
S-Orchestrator and the R-Orchestrator is discussed, while the
S-Orchestrator will provide overall suprevision of the network, the
R-Orchestrator will only responsible for deployments and
orchestration within its own reginal DC. The interface between the
S- and R-Orchestrator is then discussed. This document proposes an
practical framework for the NFV deployment. The hierarchical
framework of the Orchestrator should be taken into consideration in
the future protocol and deployment development and discussion.
7. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Fu Expires April 21, 2016 [Page 6]
Internet-Draft Hierarchical Orchestrator October 2015
Author's Address
Qiao Fu (editor)
China Mobile
Xuanwumenxi Ave. No.32
Beijing
China
Email: fuqiao1@outlook.com
Fu Expires April 21, 2016 [Page 7]
