What's on this page

Implement VNFC

The following steps are required to implement a VNFC and are further described below.

Create lifecycle scripts

The next step is to map the standardised lifecycles (start, stop, configure, install, integrity and uninstall) to the specific commands for that VDU. This means that each VNFC will have the same interface so that the Intent Engine can use these in its automated opinionated patterns.

For each of the lifecycle steps and operations (to be used in relationships) a ‘script’ needs to be created. For example if you are using the Ansible Resource Manager, each lifecycle script maps to an Ansible playbook that is called the same as the lifecycle step. More information about Ansible playbooks can be found here

The following scripts should be created for the specific VNFC and be placed in the lifecycle folder in the VNFC:

Configure.yml
Install.yml
Integrity.yml
Start.yml
Stop.yml
Uninstall.yml

A VNFC does not need to implement all lifecycle scripts. These can be simply removed from the folder if not used.

Create operations scripts

In addition to the standard lifecycle scripts, specific operations may also be added. Operations are bespoke transitions that are invoked by the Resource manager when Stratoss™ Lifecycle Manager (LM) is establishing relationships between two VNFCs. These allow for action to take place between the VNFCs to enable a Network Service to work. Operations and their definitions are part of the public interface of a VNFC.

Create an operation by creating the script in the lifecycle folder where the name of the operation is the name of the script.

Create VNFC Descriptor

Each VNFC requires a descriptor in the YAML format. This descriptor is stored in ‘descriptor’ directory of the VNFC. The format of these files is defined by the Stratoss LM Resource Descriptor YAML Specification.

Each VNFC must have a name and a version - it is advisable to name the VNFC assuming other people might use the same name i.e. companyname.resourcename. Any change to any part of the VNFC should result in creating a new VNFC with an updated version number.

Each VNFC may have a set of properties. These can be required or optional. Default values can be supplied. Below are some of the sections in the VNFC descriptor:

Name Required
Description Unique name and version name of the VNFC
Properties Properties and values for the VNFC such as image location, networks, information for metrics and ID
Lifecycle Lifecycles that apply for this VNFC
Metrics Metrics such as integrity and publication period
Policies Policies using these metrics such as heal based in the integrity metric
Operations Transitions that are invoked when establishing relationships

An Example of a VNFC (resource) Descriptor

Below is an example of a VNFC descriptor:

name: resource::simple_vnfc::1.0.0
description: A VNFC for a simple example
properties:
  device_id:
    description: The ID of the Device
    type: string
    value: ${instance.id}
    
  device_name:
    description: The name of the  Device
    type: string
    required: true
  mgmt_network:
    description: The management network used to manage the device
    type: string
    default: mgmt
  mgmt_address:
    description: The management network ip address of the the device
    type: string
    read-only: true
  instance_name:
    value: ${instance.name}

lifecycle:
- Install
- Configure
- Start
- Integrity
- Stop
- Uninstall

operations:
  addRule:
    properties:
      mgmt_address:
        type: string
        description: the ip_address of the instance
        value: ${mgmt_address}
      rule_name:
        type: string
        description: The name of the rule
        required: true
      rule_type:
        type: string
        description: The type of rule
        default: Other
        required: true
       
  deleteRule:
    properties:
      mgmt_address:
        type: string
        description: the ip_address of the instance
        value: ${mgmt_address}
      rule_name:
        type: string
        description: The name of the rule
        required: true
      rule_type:
        type: string
        description: The type of rule
        default: Other
        required: true
  addNetworkInterface:
    properties:
      network_name:
        type: string
        description: The name of the network
        required: true
      interface_name:
        type: string
        description: the name of the vnic to be used
        default: vnic0
      device_name:
        type: string
        description: The name of this device
        required: true       
  deleteNetworkInterface:
    properties:
      network_name:
        type: string
        description: The name of the network
        required: true
      interface_name:
        type: string
        description: the name of the vnic to be used
        default: vnic0
      device_name:
        type: string
        description: The name of this device
        required: true

metrics:
  h_load:
    type: metric::load
    publication_period: 60
  h_integrity:
    type: "metric::integrity"
    publication-period: "10"
policies:
  heal:
    metric: "h_integrity"
    type: "policy::heal"
    properties:
      smoothing:
        value: ${integrity_smoothing}

NOTE: The resource_id property that has a value set to “${instance.id}”. When the resource is created this will have the ID for the resource that the LM has assigned it. Other options are “${instance.id}” that will have the LM name for the resource and “${instance.index}” which will have the unique index number for a resource when more than one can be created by the LM within an assembly.

Metrics in the VNFC descriptor

Each VNFC may emit metric information to help in its management. Stratoss LM is expecting all collected metrics from the VNFCs to be made available on Kafka. Stratoss LM listens to specific Kafka topics for events containing metrics. Metrics should be associated with necessary identifiers including timestamps, names of the metric and “Metric Identifiers” specifying the source resource of the metrics.

Metrics for Integrity and Load are defined in the VNFC Descriptor. The Integrity metric is used to heal a broken VNFC. The Load metric is used in the VNF or Network Service to scale a VNF:

metrics:
 lb_integrity:
 type: metric::integrity
 publication-period: ${integrity_publication_period}
 lb_load:
 type: metric::load
 publication-period: ${load_publication_period}

Heal Policy in the VNFC descriptor

The Integrity or Heal policy in the VNFC Descriptor can be seen in the example below:

metrics:
  h_integrity:
    type: "metric::integrity"
    publication-period: "10"
policies:
  heal:
    metric: "h_integrity"
    type: "policy::heal"
    properties:
      smoothing:
        value: ${integrity_smoothing}

This shows the metrics section in the VNFC Descriptor that defines the metric called h_integrity. For the Integrity metric a policy is also included that defines the number of smoothing periods that will pass before the VNFC will be either marked as BROKEN when the BROKEN integrity messages have sent, or if the VNFC has been missing.

NOTE: the policy for Scaling is defined in the VNF or Network Service Descriptor and not in the VNFC Descriptor.

Operations in the VNFC descriptor

The Operation scripts that are put in the Lifecycle folder of the VNFC are used in the VNFC Descriptor by calling that operation name and specifying properties. Below an example of an addToDispatchList operation for the voice gateway that requires the IP address and port of the Asterisk voice server. This operation is then later used once in the Network Service Design.

operations:
  addToDispatchList:
    properties:
      ipaddr:
        type: string
        description: address of the asterisk to add to pool
        required: true
      port:
        type: string
        description: port of the asterisk to add to pool
        default: 5060
        required: true

Onboard VNFC

Once you have completed the above steps, you are ready to onboard your VNFC, so that it can be used in there Stratoss LM Designer to create the VNF.

To onboard your VNFC, enter the following LMCTL command in the project folder. This command will onboard the VNFC to the “dev” environment and it will appear as a resource in your Stratoss LM Designer:

lmctl project push dev