To be archived

Overview

The vFirewall is the easiest amongst all the use cases and is used heavily for automated regression by the Integration team and by ONAP users who test and try out the platform. Currently, the use case does not fully support integration of newer ONAP features and components. The goal is to bring it up to standard with other use cases within the scope of closeloop domain.

Problem Statement

Heat Template Structure

Today, the vFirewall use case is composed on two VNFs: i) one with the vFirewall and vSink VNF components (VNF-Cs), and ii) one with the packet generator (vPacketGen). Each VNF has its own Heat template. The Heat template that describes the vFirewall/vSink VNF also contains the private networks that connect elements in the overall service. Since Casablanca the heat templates have been restructured as follows: (https://github.com/onap/demo/tree/master/heat/vFW_NextGen/templates)

• One base Heat templates that includes the private networks and all the other common resources;
• One non-base Heat template per VNF-C, i.e. one template for the vFirewall, one for the vSink, and one for the vPacketGen.

This change to the Heat template structure has an impact on the way the Policy Engine will execute closed loop. Today, when a policy violation in the vFirewall use case is detected, the Policy Engine tells APPC to execute a corrective action against the vPacketGen VNF by providing the VNF UUID of the vPacketGen itself. Policy Engine will need to use the VF module UUID of the vPacketGen instead of the VNF UUID.

Leveraging CDS and Data Dictionary for Instantiation

The Controller Design Studio (CDS) has been supported in ONAP since Casablanca release. CDS allows a service designer to automate preload and to configure VF modules once they are created. SDNC will support collection of resource instantiation artifacts modelled at design time using CDS. SDNC will leverage the NETBOX capability to automate IP assignment and a Naming microservice for policy-driven resource naming generation. Default name values can also be used, if preferred. When the automated capabilities are used, SDNC automatically creates and assigns a name to a resource (e.g. a VM, network, etc.), based on predefined resolution strategies indicated in the Data Dictionary (DD). DD allows service designers and users to define how the parameters defined in the instantiation model can be resolved (automated capability, static value, or default value) and where the to retrieve resolution information from (MDSAL or database or other). Thanks to model-driven automation, the users can choose not to preload SDNC with VF module specific configuration before instantiating a VF module, but to rely on a fully automated approach.

Since Casablanca, we are using CDS to model the instantiation configuration of the VF modules that are part of the vFW use case. We won't need to preload configuration in SDNC before instantiating a VF module. We will create a blueprint that will allow CDS to automatically generate configuration at instantiation time. The CDS blueprints for vFW usecase can be accessed at: https://github.com/onap/ccsdk-apps/tree/casablanca/ms/controllerblueprints/application/load/blueprints/vFW. Tutorial on how to use CDS for vFW instantiation can be found here: vFW CDS Casablanca

Define ModifyConfig action in CDS for Post-Instantiation

Create CDS package (CBA: controller blueprint archive) that defines ModifyConfig action. The inputs that we envision are VNF ID, Port number and credentials for authentication. As a part of this package designer will define the ModifyConfig action by providing golden templates (XML Netconf template) along with a mapping file defining what values to resolve and a python script to resolve the configlet and apply it using NETCONF. An example of deploying configuration to a NETCONF server using CDS can be found here: https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/blueprint-model/test-blueprint/golden/Scripts/python/ConfigDeploy.py

The recording can be accessed at: Presentation#ONSNA2019

Removing ModifyConfig Parameters from the Policy Template

Today, Policy now allows the Control Loop Designer to specify the payload for APPC API calls through CLAMP. Policy will copy the entire payload of the operation that APPC has to execute against the VNF during closed loop into the APPC LCM request.

ModifyConfig action including the parameters and their resolution will be defined in CDS as described above. We will implement CDS API model implementation and actor implementation in policy so that we can either directly invoke CDS to push the NETCONF payload to the vPacketGen VNF or invoke APPC to execute ModifyConfig against the traffic generator VNF.

Pamela Dragosh - we want to also deprecate the old API for ModifyConfig and use APPC's LCM API interface if possible.

For example, as described above: a user can define ModifyConfig parameters in CDS using DD and specify the parameter resolution. During closed loop, Policy will just tell APPC to execute ModifyConfig against a specific VNF. APPC will then look at the VNF template (built with CDS) to retrieve the ModifyConfig parameters and use DD for their resolution. If DD will not be available, then ModifyConfig parameters could be defined in CLAMP and pushed to Policy during closed loop creation. Policy will then pass these parameters to APPC during closed loop execution. This is how the automated scale out use case is designed for Casablanca.

Note: The architecture subcommittee is discussing the common controller API, and we will need to replace the current ModifyConfig APPC action with the common controller API

Adding of Guard Policies (Stretch)

Guard policies can be added (stretch goal) to regulate the frequency of operations in a given time frame, for example restricting the number of traffic adjustments in the next X minutes. (Frequency limiter guard policy)

Additional Closed Loop (Stretch)

In Frankfurt we can extend the set of closed loops and actions executed against the VNF. One possible scenario is to restart the VM that hosts the traffic generator VNF (vPacketGen) if/when it stops sending traffic. Other closed loops (e.g. monitoring the health status of the VNF via APPC) are under consideration, but they represent a stretch goal at the moment.

Additional Control Loop Coordination - for multiple closed loops (Stretch)

Control Loop Coordination is useful when multiple closed loop are defined and the Policy Engine must ensure that no more than one control loop runs at a time. This extension is being evaluated for Dublin. See the following for more details: https://wiki.onap.org/pages/viewpage.action?pageId=35523671&preview=/35523671/36965215/CLC_11_July_2018.pdf for understanding Control Loop Coordination.

Additional Change Management (Future)

For vPacketGen, there is a bug in that VNF where it stops send traffic (see Additional Closed Loop). A nice added feature to test is utilizing Change Management to upgrade the VNF and then test/verify the problem is fixed.

Dependency: vPacketGen package has pre-cooked static configuration and needs to be upgraded to support change management operations.
Implications: How do we represent the SW upgrade for example via SDC models?

Control Loop Retirement Functionality (Future, depends on Change Management)

If change management is successful in upgrading the VNF, then it is possible to retire the additional control loop associated with restarting that VNF when it fails to send packets.

a parent page to track all the items where we would use the vFW usecase to demonstrate new features and interactions in the closeloop domain.

Current controlloop workflow for vFW usecase

CDS actor support in Policy

Upgrading vFWCL Integration Test Case to Include DCAE-DS and CLAMP in El Alto/Frankfurt

Stretch and future items

Business Requirement

Use the vFW usecase to demonstrate new ONAP features and component interoperability within the scope of controlloop.

Participating Companies

AT&T, Bell, Samsung

Goals

1. CDS actor support in Policy: To bring in integration of CDS into policy as another actor and demonstrate this integration using the vFirewall end-to-end closeloop usecase (design-time + runtime: instantiation and closeloop)
2. ....