You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Overview

The vFirewall is the easiest to use 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 is out-of-date. The goal is to bring it up to standard with other use cases.

Updating the 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. For Dublin, we are considering to reshape the Heat templates in the following way:

  • 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 structure will allow users to leverage the macro instantiation workflow in SO, which deploys all the VNFs in a service in a single call. The macro instantiation workflow will install the base template first, and then all the other non-base templates.

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. If we decide to reshape the Heat templates as described above, Policy Engine will have to use the VF module UUID of the vPacketGen instead of the VNF UUID. Policy doesn't have this capability right now, so reshaping the Heat templates is currently under investigation. A possible approach could be to reshape only the vFirewall/vSink Heat template and leave the vPacketGen Heat template as is. This, however, may complicate the adoption of CDS technologies (see below), which would have to deal with cross references in Heat templates of elements at different levels (i.e. VF module vs. VNF).

Finally, Heat templates should be follow the ONAP VNF Guidelines and pass VNF Validation.

Leveraging CDS and Data Dictionary

The Controller Design Studio (CDS) will be contributed to ONAP as part of Casablanca release. CDS extends the current capabilities of the Controller Design Tool (CDT), allowing a service designer to create both a VNF template (as in Beijing) and a configuration template that will be used to configure VF modules once they are created. SDNC will support collection of resource instantiation artifacts modeled at design time using CDS. SDNC will leverage the NETBOX capability (planned for Casablanca) 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 (MSDAL or database). 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.

For Dublin, we plan to use CDS and DD (if available) to model the instantiation configuration of the VF modules that are part of the vFW use case. In this way, 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.

Modeling VNF Interfaces with CDT

Being the ONAP controllers VNF-agnostic and model-based, the user is required to create a VNF template using the Controller Design Tool (CDT). The template describes the operations that can be executed against a VNF (e.g. scale out, health check, modify configuration, etc.), the protocols that a VNF supports, port numbers, VNF APIs, and credentials for authentication. ONAP controllers use these templates to “learn” about specific VNFs and the supported operations. 

For Dublin, we will model the vFW interfaces with CDS (extension of current CDT). This will deprecate the current APPC ModifyConfig API call from Policy to APPC and upgrade to APPC's latest LCM API. 

Removing ModifyConfig Parameters from the Policy Template

Today, Policy hardcodes the entire body of the operation that APPC has to execute against the VNF during closed loop. For Dublin, we plan to remove this limitation. Further details about Policy/APPC interaction will be defined later, depending on which technologies we can leverage for Dublin release.

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

For example, if DD will be available, a user can define ModifyConfig parameters in CDS (extension of current CDT) and specify the parameter resolution in DD. 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.

Adding of Guard Policies

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.

Additional Closed Loop

In Dublin 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

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.

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

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



  • No labels