| 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
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.
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 (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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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.
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].
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.
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.
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. Failure of the active reginal DC will trigger the failover to the redundant site without service loss.
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.
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.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |