+To change the volume of queries generated by the packet generator, run the following command in a shell, replacing PacketGen_IP in the HTTP argument with localhost (if you run it in the packet generator VM) or the packet generator IP address:
+
+ curl -X PUT -H "Authorization: Basic YWRtaW46YWRtaW4=" -H "Content-Type: application/json" -H "Cache-Control: no-cache" -d '{"pg-streams":{"pg-stream": [{"id":"dns1", "is-enabled":"true"}]}}' "http://PacketGen_IP:8183/restconf/config/sample-plugin:sample-plugin/pg-streams"
+
++ *{"id":"dns1", "is-enabled":"true"}* shows the stream *dns1* is enabled. The packet generator sends requests in the rate of 100 packets per 10 seconds.
+
++ To increase the amount of traffic, you can enable more streams. The packet generator has 10 streams, *dns1*, *dns2*, *dns3* to *dns10*. Each of them generates 100 packets per 10 seconds. To enable the streams, please add *{"id":"dnsX", "is-enabled":"true"}* to the pg-stream bracket of the curl command, where *X* is the stream ID.
+
+For example, if you want to enable 3 streams, the curl command will be:
+
+ curl -X PUT -H "Authorization: Basic YWRtaW46YWRtaW4=" -H "Content-Type: application/json" -H "Cache-Control: no-cache" -d '{"pg-streams":{"pg-stream": [{"id":"dns1", "is-enabled":"true"}, {"id":"dns2", "is-enabled":"true"},{"id":"dns3", "is-enabled":"true"}]}}' "http://PacketGen_IP:8183/restconf/config/sample-plugin:sample-plugin/pg-streams"
+
+When the VNF starts, the packet generator is automatically configured to run 5 streams.
+
+vVolumeGroup Use Case
+---
+
+The vVG directory contains the HEAT template (base\_vvg.yaml) and environment file (base\_vvg.env) used to spin up a volume group in OpenStack and attach it to an existing ONAP instance.
+
+The HEAT environment file contains two parameters:
+
+ volume_size: 100
+ nova_instance: 1234456
+
+volume\_size is the size (in gigabytes) of the volume group. nova\_instance is the name or UUID of the VM to which the volume group will be attached. This parameter should be changed appropriately.
+
+
+VNF component Auto Scale Out with Manual Trigger use case via VID and APPC
+---
+
+The Auto Scale Out with Manual Trigger use case shows how users/network operators can add capacity to an existing VNF. ONAP Beijing release supports scale out of VNF components in two ways, so as to demonstrate flexibility of the ONAP platform and the use case itself. One way involves triggering the scale out operations via the Virtual Infrastructure Deployment (VID) GUI, and uses the Application Controller (APPC) as a generic VNF Manager. This is demonstrated against the vLB/vDNS VNFs. The second example involves triggering scale out operations from the Use case UI (UUI) and uses Virtual Function Controller (VF-C) as generic VNF Manager. This is demonstrated against VoLTE VNFs (MME, SAE-GW, CSCF, TAS). Both scale out blueprints use the Service Orchestrator (SO) as workflow execution engine.
+
+This repository hosts the source code and scripts that implement the vLB/vDNS VNFs for the scale out blueprint that uses VID, SO, and APPC. At high level, the use case works as follows:
+ - The user/network operator triggers the scale out operation from the VID portal. VID translates the operation into a call to SO;
+ - SO instantiates a new VNF component and sends APPC a request for reconfiguring the VNF;
+ - APPC reconfigures the VNF, without interrupting the service.
+
+For this use case, we created a modified version of the vLB/vDNS, contained in vnfs/VLBMS. Unlike the vLB/vDNS VNF described before, in this modified version the vLB and the vDNS do not run any automated discovery service. Instead, the vLB has a Northbound API that allows an upstream system (e.g. ONAP) to change the internal configuration by updating the list of active vDNS instances. The Northbound API framework has been built using FD.io-based Honeycomb 1707, and supports both RESTconf and NETCONF protocols. Below is an example of vDNS instances contained in the vLB, in JSON format:
+
+ {
+ "vlb-business-vnf-onap-plugin": {
+ "vdns-instances": {
+ "vdns-instance": [
+ {
+ "ip-addr": "192.168.10.211",
+ "oam-ip-addr": "10.0.150.2",
+ "enabled": true
+ },
+ {
+ "ip-addr": "192.168.10.212",
+ "oam-ip-addr": "10.0.150.4",
+ "enabled": true
+ }]
+ }
+ }
+ }
+
+According to the flow described above, during an execution of the use case against the vLB/vDNS VNF:
+ - The user/network operator triggers the instantiation of a new vDNS from the VID GUI;
+ - VID sends the request to SO, which spins up a new vDNS and sends APPC the details about the new vDNS (i.e. ip-addr, oam-ip-addr, enabled);
+ - APPC runs a NETCONF operation against the vLB to update the list of vDNS instances with the vDNS just created.
+
+Although the VNF supports the update of multiple vDNS records in the same call, for Beijing release APPC updates a single vDNS instance at a time.
+
+The use case includes design-time and run-time operations. For Beijing release, APPC has a new component called Controller Design Tool (CDT), a design-time tool that allows users to create and on-board VNF templates into the APPC. The template describes which control operation can be executed against the VNF (e.g. scale out, health check, modify configuration, etc.), the protocols that the VNF supports, port numbers, VNF APIs, and credentials for authentication. Being VNF agnostic, APPC uses these templates to "learn" about specific VNFs and the supported operations.
+
+CDT requires two input: 1) the list of parameters that APPC will receive (ip-addr, oam-ip-addr, enabled in the example above); 2) the VNF API that APPC will use to reconfigure the VNF.
+
+Below is an example of the parameters file (yaml format), which we call parameters.yaml:
+
+ version: V1
+ vnf-parameter-list:
+ - name: ip-addr
+ type: null
+ description: null
+ required: "true"
+ default: null
+ source: Manual
+ rule-type: null
+ request-keys: null
+ response-keys: null
+ - name: oam-ip-addr
+ type: null
+ description: null
+ required: "true"
+ default: null
+ source: Manual
+ rule-type: null
+ request-keys: null
+ response-keys: null
+ - name: enabled
+ type: null
+ description: null
+ required: "true"
+ default: null
+ source: Manual
+ rule-type: null
+ request-keys: null
+ response-keys: null
+
+Here is an example of API for the vLB VNF used for this use case. We name the file after the vnf-type contained in SDNC (i.e. Vloadbalancerms..base_vlb..module-0.xml):
+
+ <vlb-business-vnf-onap-plugin xmlns="urn:opendaylight:params:xml:ns:yang:vlb-business-vnf-onap-plugin">
+ <vdns-instances>
+ <vdns-instance>
+ <ip-addr>${ip-addr}</ip-addr>
+ <oam-ip-addr>${oam-ip-addr}</oam-ip-addr>
+ <enabled>${enabled}</enabled>
+ </vdns-instance>
+ </vdns-instances>
+ </vlb-business-vnf-onap-plugin>
+
+To create the VNF template in CDT, the following steps are required:
+ - Connect to the CDT GUI: http://APPC-IP:8080 (in Heat-based ONAP deployments) or http://ANY-K8S-IP:30289 (in OOM/K8S-based ONAP deployments)
+ - Click "My VNF" Tab. Create your user ID, if necessary
+ - Click "Create new VNF" entering the VNF type as reported in VID or AAI, e.g. vLoadBalancerMS/vLoadBalancerMS 0
+ - Select "ConfigScaleOut" action
+ - Create a new template identifier using the vnf-type name in SDNC as template name, e.g. Vloadbalancerms..base_vlb..module-0
+ - Select protocol (Netconf-XML), VNF username (admin), and VNF port number (2831 for NETCONF)
+ - Click "Parameter Definition" Tab and upload the parameters (.yaml) file
+ - Click "Template Tab" and upload API template (.yaml) file
+ - Click "Reference Data" Tab
+ - Click "Save All to APPC"
+
+Finally, log into the APPC controller container and set the VNF password (ConfigScaleOut.password) in /opt/onap/appc/data/properties/appc_southbound.properties to admin. Note that in an ONAP instance created with OOM, APPC may use redundancy to make the controller resilient to failures. For Beijing, CDT only updates one replica of APPC. As such, in a multi-replica environment, the property file should be copied over to the other replicas. If redundancy is used, APPC has 3 replicas. CDT typically updates APPC-0 only, so the property file should be copied over to APPC-1 and APPC-2. This will be addressed in future ONAP releases.
+
+To trigger the scale out workflow, the user/network operator can log into VID from the ONAP Portal (demo/demo123456! as username/password), select "VNF Changes" and then the "New (+)" button. The user/network operator needs to fill in the "VNF Change Form" by selecting Subscriber, Service Type, NF Role, Model Version, VNF, Scale Out from the Workflow drop down window, and APPC from the Controller drop down window. After clicking "Next", in the following window the user/network operator has to select the VF Module to scale by clicking on the VNF and then on the appropriate VF Module checkbox. Finally, by clicking on the "Schedule" button, the scale out use case will run as described above.
+
+
+ONAP Use Cases HEAT Templates
+---
+
+USE CASE VNFs SHOULD BE INSTANTIATED VIA ONAP. THE USER IS NOT SUPPOSED TO DOWNLOAD THE HEAT TEMPLATES AND RUN THEM MANUALLY.
+
+The vFWCL directory contains two HEAT templates, one for creating a packet generator (vPKG/base\_vpkg.yaml) and one for creating a firewall and a packet sink (vFWSNK/base\_vfw.yaml). This use case supports VNF onboarding, instantiation, and closed-loop. The vFW directory, instead, contains a single HEAT template (base\_vfw) that spins up the three VFs. This use case supports VNF onboarding and instantiation only (no support for closed-loop). For Amsterdam Release, the HEAT templates in vFWCL are recommended, so that users can test and demonstrate the entire ONAP end-to-end flow.
+
+The vLB directory contains a base HEAT template (base\_vlb.yaml) that install a packet generator, a load balancer, and a DNS instance, plus another HEAT template (dnsscaling.yaml) for the DNS scaling scenario, in which another DNS server is instantiated.
+
+Before onboarding the VNFs in SDC, the user should set the following values in the HEAT environment files:
+
+ image_name: PUT THE VM IMAGE NAME HERE
+ flavor_name: PUT THE VM FLAVOR NAME HERE
+ public_net_id: PUT THE PUBLIC NETWORK ID HERE
+ dcae_collector_ip: PUT THE ADDRESS OF THE DCAE COLLECTOR HERE (NOTE: this is not required for vFWCL/vPKG/base\_vpkg.env)
+ pub_key: PUT YOUR KEY HERE
+ cloud_env: PUT openstack OR rackspace HERE
+
+image\_name, flavor\_name, \public\_net\_id, and pub\_key can be obtained as described in the ONAP Section. For deployment in OpenStack, cloud\_env must be openstack.
+
+The DNS scaling HEAT environment file for the vLoadBalancer use case also requires you to specify the private IP of the load balancer, so that the DNS can connect to the vLB:
+
+ vlb_private_ip_1: PUT THE PRIVATE ADDRESS OF THE VLB IN THE ONAP NETWORK SPACE HERE
+
+As an alternative, it is possible to set the HEAT environment variables after the VNF is onboarded via SDC by appropriately preloading data into SDNC. That data will be fetched and used by SO to overwrite the default parameters in the HEAT environment file before the VNF is instantiated. For further information about SDNC data preload, please visit the wiki page: https://wiki.onap.org/display/DW/Tutorial_vIMS+%3A+SDNC+Updates
+
+Each VNF has a MANIFEST.json file associated with the HEAT templates. During VNF onboarding, SDC reads the MANIFEST.json file to understand the role of each HEAT template that is part of the VNF (e.g. base template vs. non-base template). VNF onboarding requires users to create a zip file that contains all the HEAT templates and the MANIFEST file. To create the zip file, you can run the following command from shell:
+
+ cd VNF_FOLDER (this is the folder that contains the HEAT templates and the MANIFEST file)
+ zip ZIP_FILE_NAME.zip *
+
+For information about VNF onboarding via the SDC portal, please refer to the wiki page: https://wiki.onap.org/display/DW/Design
+
+NF Change Management use case
+---