Thoughts on SO-APPC-VFC

Below are thoughts to continue the SO-APPC-VFC discussion. So far, we have discussed proposals from Vimal, Lingli, and Jamil.  This page attempts to synthesize and analyze the proposals to help drive further discussion.  Please feel free to update.

Language

One of the first challenges we have is around language.  We use the term “controller” for the entities that bring up SDN services and NFV applications.  However, I can’t find good industry definitions for an “NFV Controller”.  Controller does have widespread use and common definitions in the SDN space, as it operates in the control plane to direct traffic flows. In ONAP, many of the controllers are built on ODL, so this is understandable. On the other hand, NFV generally works in the management plane (providing management, monitoring, and configuration functions).  Indeed, Vimal’s description of a controller covers many of those management functions: “Maintain Topology, Configuration State, Perform Configuration Management and Provide Life Cycle Management Functions (i.e. common verbs – Restart, Suspend, Drain, etc.)”.  ETSI NFV language, too, focuses on managers (Management and Orchestration, Virtual Network Function Manager, Virtual Infrastructure Manager, etc.). Reality is, of course, messier. For example, ODL is primarily an SDN controller, but can also be used for management functions and OpenStack is primarily a manager, but also supports controller functions through Neutron.

I think the term “orchestration” is clearer, with similar definitions coming from ETSI NFV and the computing industry.  To choose two:

• Orchestration: Aligning business request with applications, data, and infrastructure (Wikipedia)
• Service Orchestration: The coordination and arrangement of multiple services exposed as a single aggregate service (Mulesoft)

These seem to fit our SO module as a stateless entity that decomposes an aggregate service definition and calls the appropriate component(s) to instantiate and manage it. 

Since I’m having trouble finding clear, consistent industry definitions, I’d like to propose that we use the following for the purposes of this conversation:

• Service orchestrator: the software module primarily responsible for decomposing an aggregate service and coordinating/arranging it through one or more subordinate modules
• Manager: a software module primarily responsible for providing management functions (e.g., management, monitoring, and configuring) within its domain
• Controller: a software module primarily responsible for providing control plane functions (e.g., maintaining network topology, directing traffic flows) within its domain

If you have better definitions, please share.

Note that for clarity, let's still use the terms “APPC” and “VFC” to refer to the modules in question, regardless of whether they are providing controller or manager functions.

Goals and questions

Through the various proposals we’ve heard on the topic, there have been several requirements and assumptions – some explicit and some implicit.  

Goals/requirements where we have consensus

• Flexibility for operator deployments: AT&T, China Mobile, Orange, and others may all want to deploy ONAP differently in their networks, and the system should be able to accommodate their needs.
• Align with ONAP architecture principles
  • Minimize the impact to external components (e.g., DCAE, A&AI): while some updates may be necessary, we want to fit into the existing framework as best as possible
  • Minimize the impact to VNF vendors: we want to make it easy for VNF vendors to work with ONAP
  • NF/Services/Product agnostic
  • Microservices-based
  • Modular
  • Align with the ONAP charter
  • Capable of delivering in R1

Open questions that have been raised, but where I don’t think we’ve reached consensus

• Avoid replication of functionality? 
• ETSI MANO alignment?
• Feature parity between APP-C and VF-C?  Do we require synchronization or do we allow variation within each module as long as the interfaces and interactions with other modules are consistent?

Functional Definitions

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.

Service Orchestrator is responsible for decomposing a complex network service into its constituent parts.

1. 1. 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)?

   2. 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)

1. 1. 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.
   2. 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:
   3. Management of the instantiation of VNF Managers where applicable.
   4. Management of the instantiation of VNFs, in coordination with VNF Managers.
   5. 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).
   6. 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.
   7. Management of the Network Service instances topology (e.g. create, update, query, delete VNF Forwarding Graphs).
   8. 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).
   9. 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.).
   10. 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).
   11. 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.
   12. 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.
   13. 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.).
   14. 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.

VNFM

1. 1. VNF instantiation, including VNF configuration if required by the VNF deployment template (e.g. VNF initial configuration with IP addresses before completion of the VNF instantiation operation).
   2. VNF instantiation feasibility checking, if required.
   3. VNF instance software update/upgrade.
   4. VNF instance modification.
   5. VNF instance scaling out/in and up/down.
   6. VNF instance-related collection of NFVI performance measurement results and faults/events information, and correlation to VNF instance-related events/faults.
   7. VNF instance assisted or automated healing.
   8. VNF instance termination.
   9. VNF lifecycle management change notification.
   10. Management of the integrity of the VNF instance through its lifecycle.
   11. Overall coordination and adaptation role for configuration and event reporting between the VIM and the EM.

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

VFC

• 2 a-n
• 3 a-k (optional – using OPEN-O G-VNFM; other gVNFM or sVNFM possible)

DCAE

• 2 b, n
• 3 f

Policy

• 2 i, m

So, SO+VFC would provide all of 1, 2, and 3, with some overlap in 2 a, c, d, j, k, and l. SO+APPC provides 1, 2 a-d, g, h, j-l. SO+VFC+APPC again provides all of 1, 2, and 3 with overlap in 2 a, c, d, j, k, l. 

Also, regardless of approach, VFC could work with DCAE and Policy on 2 b, i, m, n, and 3 f.

Deployment scenarios

We have seen three different deployment scenarios 

• Option A: VF-C is “next to” APP-C, and a given service could use either APP-C or VF-C, depending on configuration. This is the “starting point” from the ONS architecture presentation, and is also covered in Lingli’s presentation as Option 2.
• Option B: APP-C becomes a gVNFM under VF-C. Jamil proposed this during the May Face-to-face.
• Option C: VF-C is subordinate under APP-C. This was Vimal’s Option 2.

Under Option A, we would need to update SO to support the OS-NFVO southbound interface to VFC, support a configuration parameter specifying whether to use APPC, VFC, or another manager in the future, and include an updated BPMN workflow for VFC (so there may be two or more workflows – existing APPC, new VFC, new TOSCA, etc.).  Both the VFC and APPC path could bring up and manage a VNF.  The VFC path could be used for ETSI NFV-aligned services, or when a VNFM is required.  The APPC path could be used in other circumstances. 

• This option provides the greatest level of operator flexibility and maximum backwards compatibility for both ECOMP and OPEN-O deployments. Operators could specify whether to use APPC or VFC in SDC when creating the service, and SO would understand how to call the appropriate manager.  Operators could use 100% APPC, 100% VFC, or some mix in the middle, as required.
• Where required, it provides ETSI NFV alignment
• We could minimize VNF vendor challenges using a common VNF packaging format and common TOSCA template, and convert to HEAT where applicable.
• It requires more work in SO up front, but would require fewer changes to VFC and APPC
• There could be some divergence between VFC (gVNFM) and APPC functionality, but it should be transparent to other ONAP components, so we would have to provide guidance to operators as to the ramifications of each choice.
• This would probably give us the greatest level of extensibility, as a similar approach could be used to add different types of managers (e.g., IoT manager, cloud manager, etc.) in the future

Under Option B, we would have to update SO to support the OS-NFVO interface and update the BPMN workflow.  We would also need to update APPC to support the OR-VNFM northbound interface.  APPC would provide all gVNFM functionality, but sVNFMs could also be used when required.  Architecturally, I think this is similar to Vimal’s option 1 (he showed SO and VFC combined, but I’m not sure that works since the codebases are too different).

• Like Option A, this option would provide ETSI NFV services
• It would require less work in SO and more work in APPC to support the changes. There would be less overall work in VFC, assuming all VNFM work would now be done in APPC.
• With one path through the system, it would reduce VNF vendor challenges.
• It would be less backwards compatible than Option A. 

After mapping modules to functionality, I don’t understand the value of Option C.  We would be using a service orchestrator to call a VNFM to call an NFVO to call another VNFM. There would be a lot of functional overlap.  However, applying the same analysis as above, I think it would require APPC to implement the OS-NFVO interface.

• When APPC invokes VFC, it would support ETSI NFV services
• It would require no work in SO and more work in APPC.
• We could again minimize VNF vendor challenges. Services could be configured in SDC to be instantiated by APPC itself or by VFC via APPC. 
• This option, again, would not be as backwards compatible as C.

So, in my opinion, it comes down to Option A or Option B: do we want APPC to connect directly to SO or do we want it to attach to VFC as a VNFM? From a development perspective, I think Option B shows promise, but Option A will provide the greatest level of operator flexibility and extensibility at the expense of more work up front.