...
Let’s combine ETSI MANO definitions with service orchestration (which ETSI doesn’t define [VY] What about Network Service (NS) management in NFVO?) to come up with a set of roles/functions for various components which we can map into deployment scenarios. I’ll work down the stack, starting at the service orchestrator. Note that below, I will use “service orchestrator” to define generic functions and “SO” to talk about the ONAP module which may or may not be covered by a different component in the ETSI MANO architecture that I’ll be using for reference.
...
Decompose service template into connectivity and application components
[VY] Why cannot we assume that in the service template (probably, similar to NSD in ETSI NFV) we already have separation of application components (VNFs, PNFs) and connectivity components (VLs, VNFFG)?Call controllers/managers to configure the network and instantiate VNFs
[VY] This part may need clarification. A call (e.g. voice call) setup, normally does not require instantiation of VNFs or network (re)configuration. Then, why the function of network configuration and VNFs instantiation should be assigned to the call controller/manager?
For clarification, it will be helpful to provide a definition of the services (orchestration of which is performed by the Service Orchestrator). The term “service” is quite ambiguous. A voice call is a service provided to an individual subscriber. Normally it’s based on control plane procedures and is not related to VNF instantiation and (re)configuration. On the other hand, ETSI NFV Network Service (NS) is a set of VNFs and PNFs together with connections (VLs) and forwarding rules (VNFFG). Setup (instantiation) of the NS is closely linked to VNF instantiation and (re)configuration.
NFV orchestrator (including Resource Orchestrator) (ETSI MANO: http://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_NFV-MAN001v010101p.pdf)
...
- Management of Network Services deployment templates and VNF Packages (e.g. on-boarding new Network Services and VNF Packages). During on-boarding of NS and VNF, a validation step is required. To support subsequent instantiation of a NS, respectively a VNF, the validation procedure needs to verify the integrity and authenticity of the provided deployment template, and that all mandatory information is present and consistent. In addition, during the on-boarding of VNFs, software images provided in the VNF Package for the different VNF components are catalogued in one or more NFVI-PoPs, using the support of VIM.
- Network Service instantiation and Network Service instance lifecycle management, e.g. update, query, scaling, collecting performance measurement results, event collection and correlation, termination.
[VY] Some of these operations are not considered NS life cycle management operations: - Management of the instantiation of VNF Managers where applicable.
- Management of the instantiation of VNFs, in coordination with VNF Managers.
- Validation and authorization of NFVI resource requests from VNF Managers, as those may impact Network Services (granting of the requested operation needs to be governed by policies).
- Management of the integrity and visibility of the Network Service instances through their lifecycle, and the relationship between the Network Service instances and the VNF instances, using the NFV Instances repository.
- Management of the Network Service instances topology (e.g. create, update, query, delete VNF Forwarding Graphs).
- Network Service instances automation management (e.g. trigger automatic operational management of NS instances and VNF instances, according to triggers and actions captured in the on-boarded NS and VNF deployment templates and governed by policies applicable to those NS and VNF instances).
- Policy management and evaluation for the Network Service instances and VNF instances (e.g. policies related with affinity/anti-affinity, scaling, fault and performance, geography, regulatory rules, NS topology, etc.).
- Validation and authorization of NFVI resource requests from VNF Manager(s), as those may impact the way the requested resources are allocated within one NFVI-PoP or across multiple NFVI-PoPs (granting of the requested resources is governed by policies, and may require prior reservation).
- NFVI resource management across operator's Infrastructure Domains including the distribution, reservation and allocation of NFVI resources to Network Service instances and VNF instances by using an NFVI resources repository, as well as locating and/or accessing one or more VIMs as needed and providing the location of the appropriate VIM to the VNFM, when required.
- Supporting the management of the relationship between the VNF instances and the NFVI resources allocated to those VNF instances by using NFVI Resources repository and information received from the VIMs.
- Policy management and enforcement for the Network Service instances and VNF instances (e.g. NFVI resources access control, reservation and/or allocation policies, placement optimization based on affinity and/or anti-affinity rules as well as geography and/or regulatory rules, resource usage, etc.).
- Collect usage information of NFVI resources by VNF instances or groups of VNF instances, for example, by collecting information about the quantity of NFVI resources consumed via NFVI interfaces and then correlating NFVI usage records to VNF instances.
...
Based on Vimal’s and Lingli’s presentations, let’s map these functions into the various modules (including DCAE & Policy).
SO:
- 1a&b
- [VY] ETSI NFVO does not do 1a (=decomposing a complex network service into its constituent parts). For 1b, further clarifications are needed (see above comment).
- 2a, c, d, j, k, l
APPC
- 2 b, g, h
- 3a-k
...