The Cisco NSO orchestration engine software modules handle the Network Functions Virtualization Orchestrator (NFVO) functions. The NFV solution follows the ETSI NFV Management and Orchestration (MANO) model, as shown in the following figure.

The following diagram illustrates, at a high-level, the components and frameworks involved in the solution.

Components

The following are some of the important components of NSO:

• Cisco NFVO Functional Pack:

  Cisco NFVO Functional Pack contains the YANG models according to the MANO specification (SOL006).

  Cisco NFVO Functional Pack contains models for cisco-etsi-nfvo , which implements the instantiation logic of MANO descriptors on VNF Managers (VNFM) and OpenStack. Virtual Network Function (VNF) and Network Service (NS) are the main services in this package. Northbound users interact with these services to start VNFs or network services.

  It also includes models for cisco-etsi-nfvo-ro , which contains the Resource Orchestration (RO) functionality. Resource Orchestration manages the allocation of physical resources in the Virtualized Infrastructure Managers (VIMs). These physical resources are used by a VNF or an NS.

• StarOS NED for NSO:

  StarOS-based Network Element Driver (NED) interfaces with the Cisco 4G CUPS VNFs for configuration push.

• RCM NED for NSO:

  RCM-based NETCONF NED is used to establish communication between NSO and RCM devices.

• Cisco ESC SOL003 NED:

  This NED is used for ETSI SOL3 compliant devices. Elastic Services Controller (ESC) is also added as SOL3 compliant device to NSO.

• NFV Apps Mobility Package:

  This is a custom package that provides VNF life-cycle management, and VNF dashboard update.

The following are the minimum platform and software requirements to support NSO Orchestration:

• Supported VIM: OpenStack

• Supported VNFM: Cisco ESC

• Supported Orchestrator: NSO

• Network Elements:

  • RCM

  • VPC-SI (UP/CP)

  • VPC-DI (CP)

This feature supports the following ETSI MANO specifications:

Network Requirements:

The following table demonstrates the NSO and ESC network requirements:

Hardware Requirements

The following table demonstrates the specifications for NSO and ESC Virtual Machine to support maximum of 250 VNFs.

The NSO Orchestration for 4G CUPS is a licensed Cisco feature. Contact your Cisco Account representative for detailed information on specific licensing requirements.

This section describes the key call flows for the 4G CUPS orchestration functionality.

Auto-healing isn’t supported currently.

To recover from fault state to previous state, perform the following steps:

• Cancel or terminate the VNF instantiation. The system returns to its original state

• Cancel or recreate VNF termination process. The system returns to its original state

The NSO Orchestration for 4G CUPS feature has the following limitation in this release:

• Production NSO instance can run only on popular Linux flavors (for example, RedHat, Cisco Linux, Ubuntu, CentOS, and so on).

• A VNF deployment may fail if the NSO/ESC instance handling the deployment goes down. This is applicable for both ESC/NSO HA as well as standalone ESC/NSO deployments. Operator intervention is required depending on the exact nature of the failure. In case of deployment followed by automated configuration push, it’s possible that the deployment succeeds but the subsequent configuration push fails depending on the timing of the NSO failure.

Pre-population of Config Metadata is important to achieve any post-deployment configuration push from NSO in an automated mode. If there are no prepopulated data for this device, NSO instantiates the VNF and on-boards as a device in NSO.

Prepopulating of config metadata has the following structure, and population of this data is based on the network scheme and data set:

container 
metadata-store {
	        list config-metadata {
	            key device-name;
	            leaf device-name {
	                tailf:info "onboarding device name";
	                type string;
	            }
	            leaf redundancy_scheme {
	                tailf:info "cluster-topology 1:1, N:M and N+2";
	                type string;
	            }
	            leaf device-type {
	                tailf:info "Onboarding device type vpc or rcm";
	                type string;
	            }
	            list attributes {
	                key attribute-name;
	                leaf attribute-name {
	                    tailf:info "Attribute Name";
	                    type string;
	                }
	                leaf attribute-value {
	                    tailf:info "Attribute Value";
	                    type string;
	                }
	            }
	            list configuration-type {
	                key config-type;
	                tailf:info "Configuration type Day0.5, Day1 or DayN";
	                leaf config-type {
	                    type string;
	                }
	                list files {
	                    key file-name;
	                    tailf:info "file name";
	                    leaf file-name {
	                        type string;
	                    }
	                    leaf config-scheme {
	                        type string;
	                    }
	                    // CP device info
	                    list additional-files {
	                        key device;
	                        //cp device
	                        leaf device {
	                            tailf:info "device name";
	                            type string;
	                        }
	                        list additional-file {
	                            key additional-file-name;
	                            leaf additional-file-name {
	                                tailf:info "file name";
	                                type string;
	                            }
	                        }
	                    }
	                }
	            }
	        }
	    }

The following table provides a description of the parameters:

The following is an example of NSO action to populate or modify the config meta-data:

container 
  config-metadata {
	        // config true;
	        tailf:action config-metadata-request {
	            tailf:info "Invoke upgrade action on the selected devices";
	            tailf:actionpoint config-metadata-request;
	            input {
	                list config-metadata {
	                    key device-name;
	                    leaf device-name {
	                        tailf:info "onboarding device name";
	                        type string;
	                    }
	                    leaf device-type {
	                        tailf:info "Onboarding device type vpc or rcm";
	                        type enumeration {
	                            enum vpc;
	                            enum rcm;
	                        }
	                    }
	                    leaf redundancy_scheme {
	                        tailf:info "cluster-topology 1:1, N:M and N+2";
	                        type enumeration {
	                            enum 1:1;
	                            enum N:M;
	                            enum RCUPS;
	                        }
	                    }
	

	                    list configuration-type {
	                        key config-type;
	                        tailf:info "Configuration type Day0.5, Day1 or DayN";
	                        leaf config-type {
	                            type enumeration {
	                                enum Day0.5;
	                                enum Day1;
	                                enum DayN;
	                            }
	                        }
	                        list files {
	                            key file-name;
	                            tailf:info "file name";
	                            leaf file-name {
	                                type string;
	                            }
	                            leaf config-scheme {
	                                type enumeration {
	                                    enum common;
	                                    enum host-specific;
	                                    enum host-specific-common;
	                                }
	                            }
	                            // CP device info
	                            list additional-files {
	                                key device;
	                                //cp device
	                                leaf device {
	                                    tailf:info "device name";
	                                    type string;
	                                }
	                                list additional-file {
	                                    key additional-file-name;
	                                    leaf additional-file-name {
	                                        tailf:info "file name";
	                                        type string;
	                                    }
	                                }
	

	                                }
	                            }
	                        }
	                    }
	                    list attributes {
	                        key attribute-name;
	                        leaf attribute-name {
	                            tailf:info "Attribute Name";
	                            type string;
	                        }
	                        leaf attribute-value {
	                            tailf:info "Attribute Value";
	                            type string;
	                        }
	                    }
	                }
	                leaf delete-config-data {
	                    type boolean;
	                    default false;
	                }
	            }
	            output {
	                leaf status {
	                    type string;
	                }
	                leaf message {
	                	type string;
	                }
	            }
	        }
	    }

You can call this action from RESTCONF, as shown in the following example:

URI: http://<NSO-IP>:<NSO-REST-PORT>/restconf/data/mobility-common:config-metadata/config-metadata-request

Method: POST

Content-Type: application/yang-data+json

Payload:

{
        "config-metadata": { 
            "device-name": "test2",
     "schema" : "1:1",
            "attributes":{
                "attribute-name":"test",
                 "attribute-value": "gh"
                  },
            "configuration-type":{
                "config-type": "Day0.5",
                "files":{
                    "file-name":"/home/ubuntu/tmo_action/test.txt"
                    },
                "files":{
                    "file-name":"/home/ubuntu/tmo_action/day0.5.txt"
                    }
                    
            }
        }
}

Result:

{
    "mobility-common:output": {
        "status": "Success
/home/ubuntu/tmo_action/test.txt ==> syntax error: unknown command,Error: on line 3: kkkl,
/home/ubuntu/tmo_action/day0.5.txt ==> Success"
    }
}

You can call this action using NCS CLI, as shown in the following example:

ubuntu@ncs> request config-metadata config-metadata-request config-metadata { device-name staros-1 attributes { attribute-name hostname attribute-value TEST } configuration-type { config-type Day0.5 files { file-name /home/ubuntu/tmo_action/test.txt } files { file-name /home/ubuntu/tmo_action/day0.5.txt } } schema 1:1  }
status Success
/home/ubuntu/tmo_action/test.txt ==> syntax error: unknown command,Error: on line 3: kkkl,
/home/ubuntu/tmo_action/day0.5.txt ==> Success
[ok][2021-07-12 08:05:01]

NOTES:

• Config-metadata-request action has internal config validator. Config validator allows detection of syntax or certain semantic errors (for example, out of range values) in advance before pushing the configuration. Config validation requires at least a device which is onboarded in NSO (Either real-one or NetSim).

  The configurable parameter is as follows:

  container 
  configurable-parameters {
  	  leaf config-pre-validation-vpc-device-name {
  	          type string;
  	  leaf config-pre-validation-rcm-device-name {
  	          type string;
  	  }
  }
  

  This config validation of files is also optional. If you do not want to validate the configs, you can turn-off this feature using configurable parameter. If config validation is turned off, then any error in the configuration files results in a config push error, and should be rolled back.

  container 
  configurable-parameters {
  	  leaf config-pre-validation-required {
  	          type boolean;
  	          default false;
  	  }
  	  } 
  	 }
  

  This config metadata contains all configurable parameters.

For ESC installation, see ESC documentation. Prior to configuration or onboarding and instantiation of VNFs, perform the following setup steps:

NSO and ESC Environment Setup for NFV

1. SSH to ESC host using username and password

   ssh esc@<esc-ip>

2. Become Sudo user

   sudo su 

3. Edit the following file: vi /opt/cisco/esc/esc_database/etsi-production.properties

4. Edit the information as shown below and save the file (Don't change anything in spring user and password). Change the NSO details accordingly. Use only local subnet management IP for communication, and not the floating-IP between ESC/NSO communication.

   spring.security.user.name=esc
   spring.security.user.password=$1$J7BUBX$Ce4vqA6JcrWCggRpYrPYg1
    
   security.pam.service=
   server.additionalConnector.port=8253
   server.additionalConnector.key-alias=esc
   server.esc.key-alias=esc
    
   nfvo.apiRoot=<NSO-IP>:9191
   nfvo.httpScheme=http
   nfvo.userName=<NSO-User-name>
   nfvo.password=<NSO-Password>
   nfvo.authenticationType=BASIC
    
   server.host=<ESC-Orch-IP>
   http.enabled=true
   https.enabled=false
   certificate.validation=false
   spring.datasource.password=${PGSQL_PASSWORD}
   spring.flyway.password=${PGSQL_PASSWORD}
   

5. Restart the escadm service, as shown below:

   escadm restart 
   Stopping esc_service: [OK]
   Stopping escadm service: [OK]
   Starting escadm service: [OK]
   #
   

6. Check for the escadm health till it becomes healthy, as shown below (It may take few minutes):

   escadm health 
   ============== ESC =================
   vimmanager (pgid 18651) is running
   monitor (pgid 18688) is running
   mona (pgid 18741) is running
   snmp is disabled at startup
   etsi (pgid 19316) is running
   pgsql (pgid 18944) is running
   portal (pgid 19355) is running
   confd (pgid 18978) is running
   escmanager (pgid 19131) is running
   =======================================
   ESC HEALTH PASSED
   

7. Login to the NSO and modify the configs according to the environment and save it into a file:

   <config xmlns="http://tail-f.com/ns/config/1.0">
     <nfv xmlns="urn:etsi:nfv:yang:etsi-nfv-descriptors">
     <settings xmlns="http://cisco.com/ns/nso/cfp/cisco-etsi-nfvo">
       <image-server>
         <ip-address><NSO-IP></ip-address>
         <port>8010</port>
         <document-root>/var/opt/ncs/vnfpackages</document-root>
       </image-server>
       <etsi-sol3>
         <server>
           <ip-address><NSO-IP></ip-address>
           <port>9191</port>
           <use-ssl>false</use-ssl>
           <document-root>/var/opt/ncs</document-root>
           <auth-enabled>true</auth-enabled>
           <auth-types>
             <basic>
               <username><NSO-USERNAME></username>
               <password><NSO-PASSWORD></password>
             </basic>
           </auth-types>
         </server>
         <vnfm-behaviour>
           <vnfm-behaviour-override>
             <id>default-sol3</id>
             <rpc-behaviour>
               <rpc>
                 <include>
                   <vim-info>false</vim-info>
                 </include>
               </rpc>
               <modify>
                 <pre>
                   <rpc>false</rpc>
                 </pre>
                 <post>
                   <rpc>true</rpc>
                 </post>
               </modify>
             </rpc-behaviour>
             <grant>
               <store-history>false</store-history>
               <heal>
                 <authorise-grant>true</authorise-grant>
               </heal>
             </grant>
             <onboarding>
               <store-details>true</store-details>
             </onboarding>
           </vnfm-behaviour-override>
         </vnfm-behaviour>
       </etsi-sol3>
     </settings>
     </nfv>
   </config>
   

8. Compile all the packages in package folder and perform package reload.

   ubuntu@test-nso:/var/opt/ncs/packages$ ncs_cli -C
   User ubuntu last logged in 2021-09-23T08:00:34.649202+00:00, to test-nso, from 209.165.200.225 using cli-ssh
   ubuntu connected from 209.165.200.225 using ssh on test-nso
   ubuntu@ncs# packages reload
    

9. Load merge the file, as shown below. This step enables NSO as NFVO and runs NFVO service in 9191 port:

   ubuntu@test-nso:~$ vi config.xml
   ubuntu@test-nso:~$ ncs_cli -C
    
   User ubuntu last logged in 2021-08-04T09:10:55.819283+00:00, to test-nso, from 209.165.200.226 using cli-ssh
   ubuntu connected from 209.165.200.227 using ssh on test-nso
   ubuntu@ncs# config 
   Entering configuration mode terminal
   ubuntu@ncs(config)# load merge config.xml 
   Loading.
   1.54 KiB parsed in 0.01 sec (128.38 KiB/sec)
   ubuntu@ncs(config)# commit 
   

10. Update NACM rule by adding NSO username to “ncsadmin” group

    ubuntu@test-nso:~$ ncs_cli -C
     
    User ubuntu last logged in 2021-08-06T09:56:26.370979+00:00, to test-nso, from 209.165.200.227 using cli-ssh
    ubuntu connected from 209.165.200.227 using ssh on test-nso
    ubuntu@ncs# config 
    Entering configuration mode terminal
    ubuntu@ncs(config)# nacm groups group ncsadmin user-name ubuntu 
    ubuntu@ncs(config-group-ncsadmin)# commit 
    

11. Copy the necessary packages to the standard location on the NSO (typically /var/opt/ncs/packages).

12. Perform package reload and check for package status. Status should be UP for all packages.

    ubuntu@test-nso:~$ ncs_cli -C
     
    User ubuntu last logged in 2021-08-06T09:58:39.866838+00:00, to test-nso, from 209.165.200.227 using cli-ssh
    ubuntu connected from 209.165.200.227 using ssh on test-nso
    ubuntu@ncs# packages reload
    ubuntu@ncs# show packages package oper-status
    
    NAME                  UP  PROGRAM CODE ERROR  JAVA UNINITIALIZED PYTHON UNINITIALIZED * 
    -----------------------------------------------------------------------------
    cisco-etsi-nfvo        X      -                     -              -              
    cisco-rcm-nc-1.0       X      -                     -              -              
    cisco-staros-cli-5.38  X      -                     -              -              
    esc                    X      -                     -              -              
    etsi-sol003-gen-1.13   X      -                     -              -              
    mobility-common        X      -                     -              -              
    mop-automation         X      -                     -              -              
    mop-common             X      -                     -              -              
    nfv-common             X      -                     -              -             
    nfv-device-onboarding  X      -                     -              -              
    nfv-vim                X      -                     -              -              
    nfv-vnf-lcm            X      -                     -              -              
    openstack-cos-gen-4.2  X      -                     -              -              
    

13. Setup the notification stream: Update /etc/ncs/ncs.conf file to add "nfv-events" stream.

    <ncs-config>
        <event-streams>
          <notifications>
            <stream>
              <name>nfv-events</name>
              <description>Generic netconf notification stream for NFV events</description>
              <replay-support>true</replay-support>
              <builtin-replay-store>
                <enabled>true</enabled>
                <dir>${NCS_RUN_DIR}/state</dir>
                <max-size>S10M</max-size>
                <max-files>50</max-files>
              </builtin-replay-store>
            </stream>
          </event-streams>
        </notifications>
    </ncs-config>
    

14. Restart NSO as sudo user.

    /etc/init.d/ncs stop   
    Stopping ncs (via systemctl):                              [  OK  ]
    /etc/init.d/ncs start  
    Starting ncs (via systemctl):                              [  OK  ]  
    

15. Onboard NETCONF, ESC, ETSI SOL003 ESC, and Openstack as devices in NSO via device onboarding APIs.

    1. Onboard Openstack as a device. The following is an example. Customize to the specific deployment. This can be configured via NSO CLI in the configuration mode. See NSO documentation for information about authgroup.

       devices device openstack
       address 209.165.200.228
       port 5000
       authgroup openstack
       device-type generic ned-id openstack-cos-gen-4.2
       

    2. Onboard ESC ETSI interface as a device. The following is an example. Customize to the specific deployment.

       devices device esc-etsi
       address 209.165.200.229
       port 8250
       authgroup esc-etsi
       device-type generic ned-id etsi-sol003-gen-1.13
       

    3. Onboard ESC native NETCONF interface as a device. The following is an example. Customize to the specific deployment.

       devices device esc-netconf
       address 209.165.200.229
       ssh host-key ssh-rsa
       key-data "AAAAB3NzaC1yc2EAAAADAQABAAABAQDYwNCaa3ghJtnJSvn/
       aSPjCuoMKmssZds+J5d9JCOS\n3h3V/fCtJwiH7qMgMXnNc0LEr1fZhxQ4kg5o/
       IafmoYD7N+w/ECqWEp68sjeN+AftiZ9J74D\n+/KDonffgBCHxIVEo0XHYlojrtmpg/
       EH9/N3fQgoSzEhGItGG4uMaAzbWr1pO8AApOPlPi4r\nciL4Qemi6u4i/
       HGFr8MqQp5qcMFd8O30OlB1q1vKn9sq/9sL6EzqyUd2lMounDglEQYMgi8J\
       nyG6upsOFuvhiYRC9qfHML45quyepsJdVi2Li2QwUJLa89EDh148RlhLTJs4s2iAwBGNdvLdK\ntzLu2VGyWKqH"
       !
       authgroup esc-netconf
       device-type netconf ned-id esc
       

16. Track the device addition status as shown below (for different devices):

    ubuntu@test-nso:~$ ncs_cli -C
     
    User ubuntu last logged in 2021-08-06T10:09:23.550686+00:00, to test-nso, from 209.165.200.227 using cli-ssh
    ubuntu connected from 209.165.200.227 using ssh on test-nso
    ubuntu@ncs# show vnf-status instances esc-netconf
                                           
    INSTANCE ID  TIMESTAMP   FUNCTION TYPE OPERATION  STATUS   STATUS MESSAGE
    -----------------------------------------------------------------------------------
    esc-netconf  2021-07-21 *    -          init   success   Device Onboarding initialized
                 2021-07-21 *    -          init   success   Device Onboarding initialized
                 2021-07-21 *    - fetch-ssh-keys  success   fetch-ssh-keys was successful
                 2021-07-21 *    -         connect success   connect was successful
                 2021-07-21 *    -       sync-from success   sync-from was successful
                 2021-07-21 *    - device-config   success   Subscribed to ESC Netconf    notification escEvent Stream
                 2021-07-21 *    -          ready  success   Device Successfully onboarded                                                                                                 
    

Before submitting the VNF deployment request, make the following configuration changes:

1. Configurable parameters

   Set the following configurable parameters, if required:

   • configurable-parameters device-ping-sleeptimesec 30 (default value is 30 sec)

   • configurable-parameters device-ping-retries 150 (default value is 30. In case of RCM, configure it to some higher value, for example, 150)

   • configurable-parameters p2p-required true (default value is false)

   • configurable-parameters p2p-soFile-path /var/opt/ncs/patch_libp2p-2.64.1418.so.tgz

2. Prepopulating of config metadata

   When you configure Config-metadata, the device name must be the same as VNF instance name.

   You can call this action from RESTCONF, as shown in the following example:

   URI: http://<NSO-IP>:<NSO-REST-PORT>/restconf/data/mobility-common:config-metadata/config-metadata-request

   Method: POST

   Content-Type: application/yang-data+json

   Sample Payload:

   {
           "config-metadata": { 
               "device-name": "test2",
        "schema" : "1:1",
               "attributes":{
                   "attribute-name":"test",
                    "attribute-value": "gh"
                     },
               "configuration-type":{
                   "config-type": "Day1",
                   "files":{
                       "file-name":"/home/ubuntu/tmo_action/test.txt"
                       },
                   "files":{
                       "file-name":"/home/ubuntu/tmo_action/day0.5.txt"
                       }
                       
               }
           }
       }
   

Ensure to follow the criteria described in the following figure while pre-populating config metadata:

VNF is instantiated upon configuration. So, to instantiate the VNF, you must load the VNF configuration into the NSO. The VNF has references to the SOL006 VNFD. It also has references to VIM artifacts like Openstack tenant networks, and IP addresses. For details about YANG definition of VNF, see Appendix A.

Instantiating a VNF involves many components:

• An ETSI SOL001 VNFD template packaged as a TOSCA VNF package

• An ETSI SOL006 VNFD with the same name or ID as the VNF package

• A VNF instance that is proprietary to the NSO

The Mobility function pack ships with some example VNF packages, which also contain the corresponding SOL006 VNFD. These examples can be used as a base, but additional customization is required to fit the deployment. An example VNF configuration is given below:

{
   "nfv-vnf-lcm:nfv-vnf":[
      {
         "network-function-type":"VPC-SI",
         "name":"test026",
         "vnfd":"VPC-SI-2P-IMAGE-BOOT",
         "instantiation-level":"default",
         "deployment-flavor":"default",
         "mgmt-user-name":"admin",
         "mgmt-password":"Csco@123",
         "host-name":"vpc-si",
         "domain-name":"cisco.com",
         "ntp-server":"209.165.201.1",
         "name-server":"209.165.201.2",
         "location":{
            "vim":{
               "name":"openstack",
               "project":"test",
               "zone-id":"nova"
            },
            "vnfm":"esc-etsi"
         },
         "network":[
            {
               "type":"VIM_NETWORK_MANAGEMENT",
               "extent":"external",
               "name":"test-mgmt",
               "subnet-name":"test-mgmt-subnet"
            },
            {
               "type":"VIM_NETWORK_ORCHESTRATION",
               "extent":"external",
               "name":"test-orch",
               "subnet-name":"test-orch-subnet"
            },
            {
               "type":"VIM_NETWORK_SERVICE_1",
               "extent":"external",
               "name":"service1",
               "subnet-name":"service1"
            },
            {
               "type":"VIM_NETWORK_SERVICE_2",
               "extent":"external",
               "name":"service2",
               "subnet-name":"service2"
            }
         ],
         "unit":[
            {
               "type":"VPC-SI",
               "image":"core-si-21.23",
               "flavor":"core-si",
               "connection-point":[
                  {
                     "name":"nic0",
                     "ip-address":[
                        {
                           "id":0,
                           "fixed-address":[
                              "209.165.201.3"
                           ]
                        }
                     ],
                     "security-group":[
                        "default"
                     ],
                     "network-type":"VIM_NETWORK_ORCHESTRATION"
                  },
                  {
                     "name":"nic1",
                     "ip-address":[
                        {
                           "id":0,
                           "fixed-address":[
                              "209.165.201.4"
                           ]
                        }
                     ],
                     "security-group":[
                        "default"
                     ],
                     "network-type":"VIM_NETWORK_MANAGEMENT"
                  },
                  {
                     "name":"nic2",
                     "ip-address":[
                        {
                           "id":0,
                           "fixed-address":[
                              "209.165.201.5"
                           ]
                        }
                     ],
                     "security-group":[
                        "default"
                     ],
                     "network-type":"VIM_NETWORK_SERVICE_1"
                  },
                  {
                     "name":"nic3",
                     "ip-address":[
                        {
                           "id":0,
                           "fixed-address":[
                              "209.165.201.6"
                           ]
                        }
                     ],
                     "security-group":[
                        "default"
                     ],
                     "network-type":"VIM_NETWORK_SERVICE_2"
                  }
               ]
            }
         ],
         "extra-parameters":[
            {
               "name":"BOOTUP_TIME",
               "value":"100"
            },
            {
               "name":"LICENSE_KEY",
               "value":"\"VER=1|DOI=1624646484|DOE=1640457684|ISS=3|NUM=212017|
CMT=SWIFT_License|LSG=5000000|LEC=10000000|LGT=5000000|FIS=Y|FR4=Y|FTC=Y|FSR=Y|
FPM=Y|FID=Y|FI6=Y|FLI=Y|FFA=Y|FCA=Y|FTP=Y|FTA=Y|FDR=Y|FDC=Y|FGR=Y|FAA=Y|FDQ=Y|
FEL=Y|BEP=Y|FAI=Y|FCP=Y|LCF=5000000|LPP=5000000|LSF=5000000|FLS=Y|FSG=Y|
LGW=5000000|HIL=XT2|LSB=5000000|LMM=5000000|FIB=Y|FND=Y|FAP=Y|FRE=Y|FHE=Y|
FUO=Y|FUR=Y|FOP=Y|FRB=Y|FCF=Y|FVO=Y|FST=Y|FSI=Y|FRV=Y|F6D=Y|F13=Y|FIM=Y|
FLP=Y|FSE=Y|FMF=Y|FEE=Y|FHH=Y|FIT=Y|FSB=Y|FDS=Y|LSE=5000000|FLR=Y|FLG=Y|
FMC=Y|FOC=Y|FOS=Y|FIR=Y|FNE=Y|FGD=Y|LIP=5000000|FOE=Y|FAU=Y|FEG=Y|FL2=Y|
FSH=Y|FLF=Y|FSP=Y|FNI=Y|FCI=Y|FME=Y|FCN=Y|FUB=Y|FSF=Y|FGO=Y|FPE=Y|FWI=Y|
FAC=Y|FIE=Y|FSM=Y|FAG=Y|FNQ=Y|FEW=Y|FAR=Y|FOX=Y|FPW=Y|FAM=Y|FGX=Y|FWT=Y|
FUA=Y|LDT=5000000|LEX=5000000|LVL=5000000|LQP=5000000|LMP=5000000|
LCU=10000000|LUU=10000000|FXS=Y|FLC=Y|FRT=Y|FSX=Y|FBS=Y|FRD=Y|FXM=Y|
LTO=10000000|FNS=Y|LNS=5000000|SIG=MC0CFBge/
0TZha2Ta7c1L5CLOL2tgDIDAhUAhIKwZxXEJJpr9Xk5buNyzZStrNM\""
            }
         ]
      }
   ]
}

The following is another example to instantiate RCM VNF:

{
    "nfv-vnf-lcm:nfv-vnf": [
      {
        "network-function-type": "RCM",
        "name": "RCM-ahhashem-sol003-78",
        "vnfd": "RCM-IMAGE-BOOT",
        "instantiation-level": "default",
        "deployment-flavor": "default",
        "mgmt-user-name": "luser",
        "mgmt-password": "$8$40/jVMTHJY+Jrd7mZiwqdrKEIz6Kc5Pt2Qvnwi0/65g=;”
        "host-name": "rcm",
        "domain-name": "cisco.com",
        "ntp-server": "209.165.201.1",
        "name-server": "209.165.201.1",
        "location": {
          "vim": {
            "name": "openstack",
            "project": "ahhashem",
            "zone-id": "nova"
          },
          "vnfm": "esc-etsi"
        },
        "network": [
          {
            "type": "VIM_NETWORK_MANAGEMENT",
            "name": "ahhashem-mgmt",
            "extent": "external",
            "subnet-name": "ahhashem-mgmt-subnet"
          },
          {
            "type": "VIM_NETWORK_ORCHESTRATION",
            "name": "ahhashem-orch",
            "extent": "external",
            "subnet-name": "ahhashem-orch-subnet"
          },
          {
            "type": "VIM_NETWORK_SERVICE_1",
            "name": "service1",
            "extent": "external",
            "subnet-name": "service1"
          } ,
          {
            "type": "VIM_NETWORK_SERVICE_2",
            "name": "service2",
            "extent": "external",
            "subnet-name": "service2"
          }
        ],
        "unit": [
          {
            "type": "RCM",
            "image": "core-rcm-21.23",
            "flavor": "mkal-rcm-hugepages",
            "connection-point": [
              {
                "name": "nic0",
                "ip-address":{
                    "id": 1,
                    "fixed-address": ["209.165.201.7"]
                },
                "security-group": ["default"],
                "network-type": "VIM_NETWORK_ORCHESTRATION"
              },
              {
                "name": "nic1",
                "ip-address":{
                    "id": 1,
                    "fixed-address":["209.165.201.8"]
                } ,
                "security-group": ["default"],
                "network-type": "VIM_NETWORK_MANAGEMENT"
              },
              {
                "name": "nic2",
                "ip-address": {
                    "id": 1,
                    "fixed-address": ["209.165.201.9"]
                },
                "security-group": ["default"],
                "network-type": "VIM_NETWORK_SERVICE_1"
              } ,
              {
                "name": "nic3",
                "ip-address": {
                    "id": 1,
                    "fixed-address": ["209.165.201.10"]
                },
                "security-group": ["default"],
                "network-type": "VIM_NETWORK_SERVICE_2"
              }

            ]
          }
        ],
        "extra-parameters": [
          {
            "name": "VIM_VM_NAME",
            "value": "RCM-ahhashem-sol003-78"
          },
          {
            "name": "HOST_NAME",
            "value": "rcm"
          },
            {
              "name": "NIC0_TYPE",
              "value": "virtual"
            },
            {
              "name": "NIC1_TYPE",
              "value": "virtual"
            },
            {
              "name": "NIC2_TYPE",
              "value": "direct"
            },
            {
              "name": "NIC3_TYPE",
              "value": "direct"
            },
            {
              "name": "MGMT_USER_NAME",
              "value": "luser"
            },
            {
              "name": "MGMT_PASSWORD_ROUND4096",
              "value": "$6$rounds=4096$P2wdTbEBO0LHmHi$OwbVEIarMbt
Qxbu5Us5kW0n0MOWp3QN9eVRX7WjvLm4xTJvFpl6vHez3XkKm39XJJ7dGRRIsZqXfcZRjQBA7E."
            },
            {
                "name": "SERVICE_INTERFACE_IP_1",
                "value": "209.165.201.9"
            },
            {
                "name": "SERVICE_INTERFACE_IP_2",
                "value": "209.165.201.11"
            }, 
            {
              "name": "NTP_SERVER",
              "value": ["209.165.201.12","209.165.201.13","209.165.201.14"]
            }

        ]
      }
    ]
  }

The following flow diagram illustrates the complete flow of end-to-end deletion automation.

Detailed Steps:

1. Network operator decides to decommission or delete the existing instance, which is in running or failed state.

   This step includes the following tasks:

   • Network operator provides the VNF-name with type for the deletion

   • NSO does the validation of the VNF existence

2. NSO checks for the VNF instance status, and if there is a failed instance at NSO end, NSO invokes ESC for deletion from VIM or perform rollback.

   This step includes the following tasks:

   • NSO decides to push it to ESC or perform rollback (in case of failed instance within NSO)

   • NSO does the asynchronous request to ESC and waits for notifications.

3. ESC does the clean-up and removes the VNF monitors.

4. ESC generates ETSI/NETCONF notifications to NSO.

5. NSO processes ESC notifications and performs the following:

   • Invokes the device-onboarding package for deletion of the instance

   • Removes entry from “nfv-vnf-inventory”

6. Device onboarding package deletes the device from NSO, and the status is updated in the VNF ledger.

The Automation process includes the following sections: