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]