This section describes how to connect to an instance of NFV Access installed on a specific target, and how to setup the virtual infrastructure manually. How to add a board to the management system Add the boards running NFV Access to the management system (Devices -> Manage-> Add):

Supply information about the board running NFV Access, and set the parameters that will be used to connect to the board (port: 22; SSH username/password: root/root):

In the main screen, check that the management system has connected to the board (System -> Unplaced):

Place the new device on the map by right clicking on the map tab:

Follow the same steps listed above, to add other boards to the management system:

The uCPE Manager can list network interfaces found on a device (Device -> Configuration -> OpenVSwitch -> Host Interface Caps):

Network interfaces can be set in three modes: DPDK, SR-IOV and PCI-Passthrough.

Configuring a physical interface in DPDK mode will require a DPDK-based application (e.g. OVS-DPDK) in order to access and use the interface. An interface set as DPDK can be attached to an OVS-DPDK bridge (Device -> Configuration -> OpenVSwitch -> Host Interfaces -> Add):

For DPDK mode, the user must set following fields: Source: PCI address of the physical interface Type: dpdk Networking-type: dpdk Dpdk-type: kernel module that allow user space access of physical interface Create an OpenVSwitch bridge (ovsbr0) on the device that uses a DPDK interface, by selecting the "Add" button from Bridges tab (Device -> Configuration -> OpenVSwitch-> Bridges):

SR-IOV mode will create a number of virtual functions on host that can be used to route traffic to VMs (Device -> Configuration -> OpenVSwitch -> Host Interfaces -> Add):

For PCI Passthrough the user does not have to configure a physical interface, instead simply select the PCI address and connect it to a virtual port at the VNF instantiation step.

As the acting VNF Manager, the uCPE Manager is responsible for handling the life-cycles of VNFs that are instantiated and run on the various uCPE hosts. The VNF Manager module is written so as to be able to manage multiple VNF types. Along with it is provided a generic infrastructure to allow the end-user to introduce new VNF types dynamically into the system. This allows for third-party VNFs to be added over time to an existing network infrastructure without having to perform an expensive upgrade of the VNF Manager itself. The process of VNF Onboarding consists of providing the system with sufficient information and resources related to the VNF such that it can instantiate a flavor of the VNF on the target, configure and scale it as appropriate, heal and upgrade it when necessary and tear it down at the right moment. The VNF Manager subsystem in the uCPE Manager inserts a menu item in the toolbar, called VNF as shown in the screen-shot below.

Selecting this menu item gives you the following options: Descriptors: Choosing this option lets you manage the VNF Descriptors catalog. The VNF Manager maintains a catalog of all VNFs that can be instantiated and managed by the system. Before you can use a new VNF, you need to onboard it into the catalog. Instances: Choosing this option lets you instantiate (or destroy) VNFs on a given uCPE host (the target). As part of instantiation, the appropriate UI, which includes the UI provided by the VnfGuiProcessor described in Section 6.2 is displayed to the user to supply instantiation parameters. Events: Choosing this option displays all the events that are related to VNF lifecycle management. Whenever a VNF state changes (i.e. it is created/destroyed/stopped/started/paused/resumed), a state change event is generated in the uCPE Manager. The screen shown when this option is chosen displays all events in the system, filtered to show only VNF state change notifications.

The VNF descriptor catalog table provides a button that allows you to onboard a new (third-party) VNF bundle into the catalog.

You can onboard using one of the following methods: Onboard a VNF Package. Directly onboard a VNF VM Image (such as a QCOW) using the onboarding wizard.

How to onboard a VNF onto the uCPE Manager Click the On-board button. When prompted by the following UI, make sure the VNF Package radio button is selected. Click Choose File and choose the VNF Package ZIP archive, e.g VProbe.zip, which represents the VNF bundle. Click Send.

This will cause the VNF Manager to do the following: Upload the ZIP file and stage it in a temporary location. Unzip it and verify its contents. Extract the various components and stash them in the appropriate location(s) for use by the uCPE Manager, so that the VNF can be treated by the uCPE Manager as a device. Then to add the VNF descriptor to the VNF Descriptor Catalog. Once these operations are complete, you will be provided with a success message.

If you click the VM Image radio button at the top of the onboarding screen, you will get a pop-up containing fields which you can fill, suppling the necessary information about the VNF. After providing the information and pressing the onboard button, the uCPE Manager will create the VNF package and onboard it.

Main fields VM Image File. This is the Virtual Machine image file for the VNF itself. Typically, it is a QCOW image. Press Choose File and select the image to be uploaded. Image Format. Select the format which matches the image file. VNF Type Name. This is the name that will be used to identify this VNF. It will be shown in the VNF tables. Description. This field contains any description you want to provide. It is only displayed in the GUI tables in the uCPE Manager. Version. This is the version of the current VNF that you are hosting. It's used to distinguish this VNF from other versions of the same type. Memory in MB. This is the amount of memory (in Megabytes) that will be provided to this type of VNF when it is instantiated. To determine the value for this field, consult the VNF vendor. Num of CPUs. The number of CPUs that will be dedicated to an instance of this VNF when created. To determine the value for this field, consult the VNF vendor. Storage in GB. How much disk space to provide an instance of this VNF. To determine the value for this field, consult the VNF vendor. Interfaces Table

Click on the Interfaces tab to show the Interfaces table. This table will contain the interfaces required by this VNF to be configured, when creating an instance. Consult the VNF vendor to determine which and how many are required. Each interface requires a name, and optionally a description, used by the uCPE Manager only. Cloud-Init Tab You must provide Clout-Init configuration for the VNF. Click the Clout Init tab.

Shown in the picture above are three fields that need to be populated: Cloud-Init Datasource, Cloud-Init Disk Type and the Content Files Table. To onboard the VNF you must specify the Cloud-Init datasource that the VNF uses. You can get this information from the VNF Vendor. Choose one of the following methods to specify the datasource: ConfigDrive. This method allows you to provide any number of content-data files containing Cloud-Init data. NoCloud. This is a simpler method that uses only one cloud init file (User-Data). The Cloud-Init Disk Type field must be set to either Disk, or CD ROM, depending on what the VNF requires. You can get this information from the VNF Vendor. The Content Files Table is used ONLY if you chose ConfigDrive as the Cloud-Init Datasource. For each content file added, you must provide a Path. When a user uses the uCPE Manager to create an instance of one of these VNFs, they will be prompted to provide a data file for each entry in this table. Each type of VNF will require different cloud-init files, e.g.: a license file. Consult with the VNF vendor to determine what is required for the VNF you are onboarding.

Properties Tab In this table, you can enter values for properties that will be used during instantiation of the VNF. The values will augment the default values in the Domain.XML file used by libvert/virsh (running in NFV Access) when creating an instance of the VNF. These property names are well known to the uCPE NFV Access software, and more will be added in future versions. You will need to consult with the VNF Vendor or ENEA support for values needed by specific VNFs.

Property Values numHugePages defines the number of huge memory pages the VNF uses (for DPDK). Needed for Clavister COS Stream.

Once the VNF bundle has been onboarded, you can instantiate a VNF on a specific uCPE host: Launch the VNF instance table by choosing the Instances option from the VNF menu. This will display the table of VNF instances controlled by the VNF Manager. Hit the Add button to create a new instance, as shown below:

There are a number of parameters to be supplied before the VNF can be instantiated: VNF Type. The VProbe VNF, in this case. VIM. This stands for Virtual Infrastructure Manager, the target host on which to instantiate a VNF, i.e. the target uCPE host that will run this VNF. Name. The name of the VNF. VNF Flavor. The flavor of VNF (as specified in the descriptor) you would like to instantiate. Device Name. The name by which the VNF will be known in the uCPE Manager, if the Manage Device checkbox is checked. If unchecked, the VNF will not be shown as a managed device in the uCPE Manager. Instantiation Parameters. This section contains all the parameters a user needs to supply when instantiating a VNF of this type. The VProbe VNF needs to specify network information (network name and IP address) for two separate interfaces (enp0s9 and enp0s10 respectively). Every VNF type will have a different UI section here. This section is populated by the getInstanceGui() method in the VnfGuiProcessorIf interface, see Section 6.1 to understand exactly how the VProbe method causes the above GUI section to be displayed. Auto-start. If checked, the VNF will be stopped and started when unreachable. When the VIM reports that it has lost connection to the VNF, the uCPE Manager will ask the VIM to terminate the VM and then start it up again. If unchecked, only a Disconnected notification will appear in the uCPE Manager. Hitting the Create button will cause the VNF to be instantiated and run on the uCPE target specified above. The following operations will now take place: Check if the uCPE already has the VNF Flavor definition in its flavor store; if not create a new Flavor definition on the uCPE. Check if the uCPE already has the VNF image in its image store; if not, upload the image and create a new Image definition on the uCPE. Take in the user parameters and create the following: Networking information. Use the VnfGuiProcessorIf class getConnectionInfo() method to convert user parameters into networking information objects (refer to Section 6.1 for the VProbe VNF). Cloud-init. Use generic VNF instance information in conjunction with the networking information objects from above and invoke the getCloudInitData() method on the VnfProcessorIf class (refer to Section 6.2 for how this is done for the VProbe VNF). The cloud-init data is the script that will be executed by the VNF when it starts up for the first time only. It is responsible for setting up the initial system configuration to what is required by the VNF to run correctly, setting up the network interfaces, static IP addresses, etc. Make the uCPE create the VNF with the specified image, flavor and cloud-init data via a NETCONF request and waits for it to be created and started up. If successful, optionally add the newly created VNF as a device in the uCPE Manager. Selecting the VNF -> Events menu will show that the VNF was created and a connection was established:

Zero-Touch Provisioning (ZTP) is an alternative to Manual configuration. ZTP refers to the process by which, when a device starts up for the first time, its initial configuration is pushed down by an external management system, so that it is setup for proper operation without additional manual intervention by an operator. A variety of operations can occur as part of ZTP such as initial device setup, configuration of managed objects, etc. The goal is to set up a device to the maximum possible extent without forcing an operator to be physically present (initially) to manage the device. In order to create a static configuration supporting ZTP, the uCPE Manager user needs to identify the Device ID of the machine running NFV Access. During the automatic installation process when the Automatic install step is reached, enter the option menu Customize kernel parameters and set the uCPE Manager IP address. Please check , step 7 for how to set the uCPE Manager IP address at boot time. The Device ID will be listed in the installer under the Customize kernel parameters menu. With the address parameter set, run list_deviceID.sh after NFV Access is installed and booted, to get the device ID of the target. It is possible to let NFV Access know the uCPE Manager IP address at run-time by setting vcpemgr=<IP> as a kernel boot parameter in the grub configuration file. Reboot is required after this update. This step needs to be done each time the uCPE Manager host changes the IP address. An offline configuration can be prepared in advance for the uCPE Manager to setup the infrastructure on the device.

The uCPE Manager must be configured to bring the target device under management. This is done by using the Devices -> Manage -> Add menu:

The relevant parameters on this screen are described below: Type. The type of device to be added, i.e Enea universal uCPE . Name. The name by which the device is referred to in the uCPE Manager. IP Address. IP address of the device. If a device is installed under a local/private network and not directly visible to the uCPE Manager machine, the Gateway IP of the private network must be used. SSH Port. The NETCONF Port used for communications. This is a relevant parameter if the standard NETCONF SSH (i.e. not Call-Home) is being used. Default is set to 22. SSH User Name. The user name for SSH connectivity. Default user is root. SSH Password/Private Key/Passphrase. The Authentication Credentials, use one of the aforementioned as appropriate. Default password is empty. Device Calls Home. This checkbox indicates the direction of device communications. When cleared, the uCPE Manager will initiate a connection to the device. When checked, the device will initiate a connection by opening a socket to the uCPE Manager for NETCONF traffic (over SSH), while the uCPE Manager waits for device connection. Device ID. The unique instance ID of the device. This is what links a device to its day-0 configuration (stored in the offline configuration system). It is a required field if you want to perform Zero-Touch Provisioning.

The Offline Configuration subsystem (which is designed as a uCPE Manager Application Module) is used to pre-populate a configuration for a device that will be brought under management at a future point in time. When creating an offline configuration store, an optional Device ID can be specified - this ID uniquely identifies the device to be initialized. Use the GUI (shown below) launched by the Applications -> Offline Config -> Add menu:

Specify the exact value of the Device ID in the required field. This will tag the device needed for the initial configuration provided by the offline configuration store. Choose Merge as the Default Upload Method if you do not want any boot configuration set on the device, to be wiped out. Selecting Replace will set the entire device configuration to match values in the offline configuration. After creating the Offline Config Store, access the device through Applications -> offline config -> Config App and provision it with the required initial configuration. This operation mirrors what happens during regular offline configuration. Now that the store has been provisioned successfully, it is ready to send this configuration to the device when it first comes online.

There are two possible paths to this process, depending upon whether or not NETCONF Call-Home functionality is used: If Call-Home is not enabled/supported, the uCPE Manager creates a SSH session to the device over the port configured through the Add Device process (default 830). It then initiates NETCONF communications over this session. If the device uses Call-Home, it creates a socket connection to port 4334 on the management system which runs the uCPE Manager. The uCPE Manager then creates a SSH session over this socket and initiates NETCONF communications as a client. Once communications with the device have been established, the Device Manager will try and connect to it.