3 Designing and Onboarding Network Services and VNFs

This chapter provides information about designing and onboarding network services and VNFs.

About the Design Components

The design components constitute resources that you create in Oracle Communications Design Studio. The Network Service Orchestration solution uses different types of files that you create in Design Studio to describe the behavior of your network services and VNFs.

Entity Specifications. You create specifications in Design Studio that you use to create instances of VNFs and network services in Oracle Communications Unified Inventory Management (UIM).

See Design Studio Help for information about creating entity specifications in Design Studio.
Descriptor files. The descriptor files describe the attributes of the VNF and Network Service specifications.

See "About the Descriptor Files" for more information about the descriptor files.
Technical actions files. The technical actions files describe the actions for the VNFs and Network Services in the VIM. There is one technical actions file for each network service and VNF.

See "About the Technical Actions File" for more information about the technical actions files.
Configuration and template files. The configuration files contain the configuration and post-configuration details for the VNFs.

See "About the VNF Configuration Files" for more information about the descriptor files.
Custom extensions. See "Extending the Network Service Orchestration Solution" for information about implementing custom extensions with the solution.

About the Descriptor Files

The descriptor files contain metadata about the network services and VNFs. The solution defines network service and VNF descriptors in the form of Design Studio specifications.The Network Service Orchestration solution uses these specifications to manage the life cycles of network services and VNFs.

Network services are assembled from the defined units of behavior provided by the VNFs in the cartridges. Network Service descriptors structure how these network services are populated in the cartridges. VNF descriptors describe the behavior of virtual functions that are defined in the Network Service Orchestration cartridges. There is one descriptor file for each network service and a VNF.

About the Network Service Descriptor Files

Network Service descriptor files describe the deployment requirements, operational behavior, and policies required by network services based on them.

When you instantiate, scale, or terminate a network service, the network service deploys, scales, and undeploys the constituent VNFs based on the parameters and policies specified in the descriptor file.

In the network service descriptor file, you:

Define the networks by either creating them or by referencing existing networks and specifying network types. See "Describing Networks" for more information.
For each network, specify the VNFs the network service should use.
Specify the network forwarding path for the network traffic. See "Describing Forwarding Graphs" for more information.
For each VNF in the network service, specify parameters related to CPU utilization and other factors related to performance of the virtual machine on which the VNF is deployed. See "Describing Deployment Flavors" for more information.
Specify when you want the solution to heal a VNF and scale the network service.

The solution includes the sample NPaaS_NSD.xml network service descriptor file.

Note:

If you create your own descriptor file for a network service, ensure that the name of the descriptor file ends with NSD. For example, if you want to create a network service descriptor file for an IP Multimedia Subsystem (IMS) network service with the name IMSaaS, create it as IMSaaS_NSD. This enables the solution to filter and return search results for network service descriptors only.

Describing Networks

In the network service descriptor XML file, you define networks by creating them or by referencing existing networks and specifying their types. You represent networks as virtual links. You can create or reference any number of networks based on your service requirements. You can also specify the number of end points the networks can have.

The following text shows the pattern in which you describe a virtual link descriptor, which corresponds to a network in the sample NPaaS_NSD.xml network service descriptor file:

-<virtualLinkDescriptors>
  -<virtualLinkDescriptor name="network_name" type="network_type" isReferenced="value">
    <numberOfEndPoints>number_of_endpoints</numberOfEndPoints>
    -<connectionPoints>
      <!-- The format is VNFD:ConnectionPoint -->
      <connectionPoint name="vnf_descriptor_name:connection_point_name" type="connection_point_type" order="connectionPoint_order"/>
    </connectionPoints>
  </virtualLinkDescriptor>
</virtualLinkDescriptors>

where:

network_name is the name of the network that you want to create or reference.
network_type is the type of the network that you want to create or reference.
value indicates whether you want to create or reference the network. Specify true or false.
number_of_endpoints is the number of endpoints that the network provides.
vnf_descriptor_name:connection_point_name is the name of the VNF descriptor XML file and the name of the VNF connection point.
connection_point_type is the type of the connection point.
connectionPoint_order is the order of the connection points for the VNF.

The following text shows a sample virtual link descriptor element in the sample NPaaS_NSD.xml network service descriptor file:

-<virtualLinkDescriptors>
  -<virtualLinkDescriptor name="Data_IN" type="Data" isReferenced="false">
    <numberOfEndPoints>20</numberOfEndPoints>
    -<connectionPoints>
      <!-- The format is VNFD:ConnectionPoint -->
      <connectionPoint name="Juniper_vSRX_VNFD:CP01" type="IN" order="2"/>
    </connectionPoints>
  </virtualLinkDescriptor>
</virtualLinkDescriptors>

Describing Forwarding Graphs

In the network service descriptor XML file, you describe forwarding graphs by specifying the network forwarding path for the network traffic.

The following text shows the pattern in which you describe a forwarding graph in the NPaaS_NSD.xml network service descriptor file:

-<forwardingGraphDescriptors>
  -<forwardingGraphDescriptor name="ForwardingGraphName" default="default">
   -<networkForwardingPath>
    -<vnfd name="vnf_descriptor_name">
     -<connectionPoints>
      <connectionPoint name="connection_point_name" type="type_of_connectionPoint"/>
     <connectionPoint name="connection_point_name" type="type_of_connectionPoint"/>
    </connectionPoints>
   </vnfd>
  </networkForwardingPath>
 </forwardingGraphDescriptor>
</forwardingGraphDescriptors>

where:

ForwardingGraphName is the name of the forwarding graph.
default indicates if the network service should use this forwarding graph by default or not.
vnf_descriptor_name is the name of the VNF descriptor that you want to use with the network service.
connection_point_name is the name of the connection point defined in the VNF descriptor, that you want to use for the forwarding graph.
type_of_connectionPoint is the type of the connection point.

The following text shows a sample forwarding graph element in the NPaaS_NSD.xml network service descriptor file:

-<forwardingGraphDescriptors>
  -<forwardingGraphDescriptor name="Data" default="true">
   -<networkForwardingPath>
    -<vnfd name="Checkpoint_NG_FW_VNFD">
     -<connectionPoints>
      <connectionPoint name="CP01" type="IN"/>
     <connectionPoint name="CP02" type="OUT"/>
    </connectionPoints>
   </vnfd>
  </networkForwardingPath>
 </forwardingGraphDescriptor>
</forwardingGraphDescriptors>

Describing Deployment Flavors

In the network service descriptor XML file, you describe deployment flavors by specifying parameters for CPU utilization and other factors related to the performance of the virtual machine on which the VNFs are deployed. You also specify when you want to heal a VNF and scale the network service.

The following text shows the pattern in which you describe deployment flavors in the NPaaS_NSD.xml network service descriptor file:

-<serviceDeploymentFlavors>
 -<serviceDeploymentFlavor name="flavorName">
  -<constituentVNFDs>
   -<vnf>
    <vnfd name="VNFDname"/>
     -<assuranceParameters>
      -<assuranceParameter name="assuranceParameterName" action="action">
       <id>Id</id>
       <value>value</value>
       <condition>condition</condition>
      </assuranceParameter>
    -<assuranceParameter name="assuranceParameterName" action="action">
      <id>Id</id>
      <value>value</value>
      <condition>condition</condition>
     </assuranceParameter>
    </assuranceParameters>
   </vnf>
  </constituentVNFDs>
 </serviceDeploymentFlavor>
</serviceDeploymentFlavors>

where:

flavorName is the name of the service deployment flavor.
VNFDname is the name of the VNF Descriptor.
assuranceParameterName is the name of the assurance parameter.
action is the action you want to perform on the VNF. You can specify either to heal or scale the VNF.
Id is the Id of the assurance parameter.
value is the threshold value.
condition is the condition based on which the action is performed.

The following text shows a sample service deployment flavor element in the NPaaS_NSD.xml network service descriptor file:

-<serviceDeploymentFlavors>
 -<serviceDeploymentFlavor name="Checkpoint">
  -<constituentVNFDs>
   -<vnf>
    <vnfd name="Checkpoint_NG_FW_VNFD"/>
     -<assuranceParameters>
      -<assuranceParameter name="Low CPU Utilization" action="heal">
       <id>cpu_util</id>
       <value>0.0</value>
       <condition>eq</condition>
      </assuranceParameter>
    -<assuranceParameter name="High CPU Utilization" action="scale">
      <id>cpu_util</id>
      <value>80.0</value>
      <condition>gt</condition>
     </assuranceParameter>
    </assuranceParameters>
   </vnf>
  </constituentVNFDs>
 </serviceDeploymentFlavor>
</serviceDeploymentFlavors>

About the VNF Descriptor Files

The VNF descriptor files describe the deployment requirements, operational behavior, and policies required by VNFs that are based on them.

The solution includes the following sample VNF descriptor files:

Juniper_vSRX_VNFD.xml. This is the descriptor file for the Juniper vSRX firewall VNF.
Checkpoint_NG_FW_VNFD.xml. This is the descriptor file for the Checkpoint NG firewall VNF.

Note:

If you create your own descriptor file for a VNF, ensure that the name of the descriptor file ends with VNFD. For example, if you want to create a VNF descriptor file for Cisco's VRF-aware VNF with the name CiscoVRF, create it as CiscoVRF_VNFD. This enables the solution to filter and return search results for VNF descriptors only.

In the VNF descriptor file, you specify:

Deployment flavor parameters
Connection points for the VNF
Software version of the VNF

The following text shows the pattern in which you describe a VNF in the VNF descriptor file:

-<vnfd name="VNFdescriptorName">
 -<deploymentFlavors>
  <deploymentFlavor name="deploymentFlavorName" disk="diskSpace" memory="memory" vcpus="vcpus"/>
  <deploymentFlavor name="deploymentFlavorName" disk="diskSpace" memory="memory" vcpus="vcpus"/>
  </deploymentFlavors>
  -<connectionPoints>
    <connectionPoint name="ConnectionPointName"/>
    <connectionPoint name="ConnectionPointName"/>
    <connectionPoint name="ConnectionPointName"/>
   </connectionPoints>
   <defaultDeploymentFlavor>defaultDeploymentFlavorName</defaultDeploymentFlavor>
  -<versions>
   <version imagePasswd="" imageUserName="" imageName="imageName" number="versionNumber"/>
  </versions>
</vnfd>

where:

VNFdescriptorName is the name of the VNF Descriptor.
deploymentFlavorName is the name of the VNF deployment flavor.
diskSpace is the disk space that you want to allocate for the VNF.
memory is the memory you want to allocate for the VNF.
vcpus is the number of virtual CPUs that you want to allocate for the VNF.
ConnectionPointName is the name of the connection point.
defaultDeploymentFlavorName is the name of the deployment flavor that you want to use for the VNF by default.
imageName is the name of the VNF image.
versionNumber is the version number of the VNF image.

The following text shows sample VNF elements in the Juniper_vSRX_VNFD.xml VNF descriptor file:

-<vnfd name="Juniper_vSRX_VNFD">
 -<deploymentFlavors>
  <deploymentFlavor name="vsrx.medium" disk="20" memory="4" vcpus="2"/>
   <deploymentFlavor name="m1.medium" disk="40" memory="4" vcpus="2"/>
  </deploymentFlavors>
  -<connectionPoints>
    <connectionPoint name="CP01"/>
    <connectionPoint name="CP02"/>
    <connectionPoint name="CP03"/>
   </connectionPoints>
   <defaultDeploymentFlavor>vsrx.medium</defaultDeploymentFlavor>
  -<versions>
   <version imagePasswd="" imageUserName="" imageName="vsrx-12.1X47-D20.7-npaas-v0.3" number="1.0"/>
  </versions>
</vnfd>

Creating a Descriptor File

In Design Studio, you create a descriptor file for each Network Service specification and VNF Service specification.

To create a descriptor file:

In Design Studio, import all the solution cartridges. See "Setting Up Design Studio for the Network Service Orchestration Solution Cartridges" for more information about importing the cartridges into Design Studio.
Switch to the Navigator view.
In the root directory of the cartridge, create the following folder structure:

model\content\product_home\config
Right-click on the config folder and create an XML file with the name ServiceSpecificationName_NSD.xml for a network service and ServiceSpecificationName_VNFD.xml for a VNF, where ServiceSpecificationName is the name of the service specification.
Copy the sample content from the sample cartridge to the XML file and modify it according to your service requirements.

About the Technical Actions File

The technical actions file describe the actions for the VNFs and Network Services in the VIM. There is one technical actions file for each network service and VNF.

In the technical actions file, for each technical action, you define the following elements:

action: This element declares a technical action, its signature, which contains the name and type of each parameter, and the type of its subject and target.
match: This element declares configuration differences that match an XPath expression.
generator: This element defines all the bindings of the configuration to the parameters, subject, and target of the action to be generated.

The following example shows the elements in the technical actions file:

<technicalActionCalculator
    xmlns="http://xmlns.oracle.com/communications/inventory/actioncalculator"
    xmlns:invactcalc="http://xmlns.oracle.com/communications/inventory/actioncalculator"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.oracle.com/communications/inventory/actioncalculator schemas/TechnicalActionCalculator.xsd">
    <invactcalc:action>
        <name>DEPLOY_VNF</name>
        <actionCode>DEPLOY_VNF</actionCode>
        <subject>
            <class>LogicalDevice</class>
        </subject>
        <target>
            <class>LogicalDevice</class>
        </target>
        <parameter>
            <name>serviceID</name>
            <type>string</type>
        </parameter>
        <parameter>
            <name>vnfID</name>
            <type>string</type>
        </parameter>
        <parameter>
            <name>vnfName</name>
            <type>string</type>
        </parameter>
        <parameter>
            <name>vnfdName</name>
            <type>string</type>
        </parameter>
        <parameter>
            <name>imageName</name>
            <type>string</type>
        </parameter>
    </invactcalc:action>
 
    <invactcalc:match>
        <invactcalc:diff>
            <invactcalc:path>/root/after/vnf/Assignment[@State='PENDING_ASSIGN'
                and /root/service[state!='PENDING_DISCONNECT']]/..</invactcalc:path>
        </invactcalc:diff>
        <invactcalc:action>DEPLOY_VNF</invactcalc:action>
        <invactcalc:anchor>.</invactcalc:anchor>
    </invactcalc:match>
 
    <invactcalc:generator>
        <invactcalc:action>DEPLOY_VNF</invactcalc:action>
        <invactcalc:condition>/root/after/vnf/Assignment[@State='PENDING_ASSIGN']</invactcalc:condition>
        <subject>.</subject>
        <target>.</target>
        <binding>
            <parameter>serviceID</parameter>
            <path>/root/service/id</path>
        </binding>
        <binding>
            <parameter>vnfID</parameter>
            <path>Assignment/id</path>
        </binding>
        <binding>
            <parameter>vnfName</parameter>
            <path>Assignment/name</path>
        </binding>
        <binding>
            <parameter>vnfdName</parameter>
            <path>Assignment/specification</path>
        </binding>
        <binding>
            <parameter>imageName</parameter>
            <path>Assignment/imageName</path>
        </binding>
    </invactcalc:generator>
</technicalActionCalculator>

Creating a Technical Actions File

In Design Studio, you create a technical actions file for each Network Service specification and a VNF Service specification.

To create a technical actions file:

In Design Studio, switch to the Navigator view.
In the root directory of the cartridge, create the following folder structure:

model\content\product_home\config
Right-click on the config folder and create an XML file with the name ServiceSpecificationName_TechnicalActions.xml, where ServiceSpecificationName is the name of the service specification.
Copy the sample content from the sample cartridge to the XML file and modify it according to your service requirements.

About the VNF Configuration Files

Depending on the functionality that they deliver, some VNFs in a network service may require configuration after they are deployed. After a VNF is deployed, you can configure the VNF based on its configuration requirements.

Note:

Post-deployment configuration of VNFs is not always required.

To configure a VNF, the solution requires the following configuration files to be created:

VNFD_NameTemplate.conf

This is a VNF-specific configuration template in which you specify the placeholder fields for instance-specific parameters.
VNFD_NameConfig.xml

This is a configuration file in which you specify the VNF instance-specific configuration parameter values as name-value pairs.

The solution generates the VNFD_Name.conf configuration file based on the VNFD_NameTemplate.conf file and the VNFD_NameConfig.xml file.

The solution reads all the name-value pairs in the VNFD_NameConfig.xml file and replaces the placeholder fields in the VNFD_NameTemplate.conf file and generates the VNFD_Name.conf file.

The following text shows a sample configuration template for the Juniper vSRX VNF in the Juniper_vSRX_VNFDTemplate.conf configuration file:

   <rpc>
    <edit-config>
        <target>
            <candidate/>
        </target>
        <config>
            <configuration>
                <security> 
                    <utm>        
                        <custom-objects>          
                            <url-pattern>            
                                <name>bad-sites</name>            
                                <value>{{site-name}}</value>          
                            </url-pattern>        
                        </custom-objects>      
                    </utm>    
                </security>
            </configuration> 
        </config>
    </edit-config>
    </rpc>

The following example shows a sample configuration for the Juniper vSRX VNF in the Juniper_vSRX_VNFDConfig.xml configuration file:

<vnfConfiguration>
    <config>
        <param>
            <name>site-name</name>
            <value>www.example.com</value>
        </param>
        <sbiToPushConfiguration>
            <interface>netconf</interface>
            <interface-script></interface-script>
        </sbiToPushConfiguration>        
        <action>null</action>
    </config>
    </vnfConfiguration>

About the Sample Network Protection Service Model

The Network Service Orchestration solution provides the following sample cartridges that you can use as references for designing and implementing network protection as a service on your network:

Juniper_vSRX_VNF. This sample cartridge contains the functionality to implement a Juniper vSRX firewall as a VNF.
Checkpoint_NG_FW_VNF. This sample cartridge that contains the functionality to implement a Checkpoint firewall as a VNF.
NPaaS_NetworkService. This sample cartridge contains the functionality to implement a Network Protection service that constitutes the Juniper vSRX firewall VNF and the Checkpoint firewall VNF.

Figure 3-1 shows how a VNF service is modeled in the sample VNF cartridge.

Figure 3-1 VNF Service Model

Figure 3-2 shows the Details view of the Juniper vSRX VNF service configuration specification in Design Studio.

Figure 3-2 VNF Service Configuration Details

Table 3-1 lists the specifications that are associated to the configuration items in the Juniper vSRX VNF service configuration.

Table 3-1 VNF Service Configuration Specifications

Configuration Item	Associated Specification
vnf	Juniper_vSRX_VNFD logical device specification as assignment. This specification is included in the Juniper sample cartridge.
ConnectionPoint	CPD device interface specification as reference. This specification is included in the OracleComms_NSO_BaseCartridge cartridge.
port	IPV4Address specification as reference. This specification is included in the in OracleComms_NSO_BaseCartridge cartridge.
capabilities	Juniper_vSRX_Capability _ServiceDescriptor specification as assignment. This specification is included in the Juniper sample cartridge.

Figure 3-3 shows the ruleset extension points that are associated to the Juniper vSRX VNF service configuration specification.

Figure 3-3 Rules Associated to the Juniper vSRX VNF Service Configuration Specification

Figure 3-4 shows how a VNF capability service is modeled.

Figure 3-4 VNF Capability Service Model

Figure 3-5 shows the Details view of the VNF capability service configuration in Design Studio.

Figure 3-5 VNF Capability Service Configuration Details

Table 3-2 shows the specifications that are associated to the configuration items in the VNF Capability service configuration.

Table 3-2 VNF Capability Service Configuration Speciations

Configuration Item	Associated Specification
capabilities	Juniper_vSRX_VNFD logical device specification as reference. This specification is included in the Juniper sample cartridge.
WebFilter	Juniper_vSRX_VNFD logical device specification as reference. This specification is included in the Juniper sample cartridge.

Configuration Item

Associated Specification

capabilities

Juniper_vSRX_VNFD logical device specification as reference.

This specification is included in the Juniper sample cartridge.

WebFilter

Juniper_vSRX_VNFD logical device specification as reference.

This specification is included in the Juniper sample cartridge.

Figure 3-6 shows the ruleset extension points that are associated with the VNF capability service configuration.

Figure 3-6 Rules Associated to the VNF Capability Service Configuration

Figure 3-7 shows how the Network Protection service is modeled in the sample Network Service cartridge.

Figure 3-7 Network Protection Service Model

Description of ''Figure 3-7 Network Protection Service Model''

Figure 3-8 shows the details view of the Network Protection service configuration in Design Studio.

Figure 3-8 Network Protection Service Configuration Details

Table 3-3 shows the specifications that are associated to the configuration items in the Network Protection service configuration.

Table 3-3 Network Protection Service Configuration Specifications

Configuration Item	Associated Specification
virtualLink	IPV4Subnet specification as reference This specification is included in the OracleComms_NSO_BaseCartridge cartridge.
vnf	Juniper_vSRX_VNFD logical device specification as reference This specification is included in the Juniper sample cartridge.
endPoint	NSSubscriber custom object specification as reference. This specification is included in the OracleComms_NSO_BaseCartridge cartridge.

Configuration Item

Associated Specification

virtualLink

IPV4Subnet specification as reference

This specification is included in the OracleComms_NSO_BaseCartridge cartridge.

vnf

Juniper_vSRX_VNFD logical device specification as reference

This specification is included in the Juniper sample cartridge.

endPoint

NSSubscriber custom object specification as reference.

This specification is included in the OracleComms_NSO_BaseCartridge cartridge.

Figure 3-9 shows the ruleset extension points that are associated with the Network Protection service configuration.

Figure 3-9 Rules Associated to the Network Protection Service Configuration

The solution includes sample descriptor files for the sample Network Protection service and the constituent VNFs. The descriptor files enable you to define the behavior of the network service and the VNFs.

NPaaS_NSD.xml. This is the descriptor file for the Network Protection service.
Juniper_vSRX_VNFD.xml. This is the descriptor file for the Juniper vSRX firewall VNF.
Checkpoint_NG_FW_VNFD.xml. This is the descriptor file for the Checkpoint NG firewall VNF.

You open the descriptor files in Design Studio and specify the deployment requirements, operational behavior, and policies required by network services.

In the descriptor file:

Specify the networks that you want to create or reference. In the descriptor file, networks are represented as virtual link descriptors.
Specify the VNFs and the flow path that you want the network traffic to pass through.
Specify the CPU utilization and other parameters for each VNF in the network service.

See "About the Descriptor Files" for more information about the Network Service descriptor file.

See "About the VNF Descriptor Files" for more information about the VNF descriptor file.

The solution includes sample technical actions files for the VNFs. The technical actions files enable you to describe the actions for the VNFs in the VIM.

NPaaS_NSD_TechnicalActions.xml. This is the technical actions file for the Network Protection service.
Juniper_vSRX_ServiceDescriptor_TechnicalActions.xml. This is the technical actions file for the Juniper vSRX firewall VNF.
Checkpoint_NG_FW_ServiceDescriptor_TechnicalActions.xml. This is the technical actions file for the Checkpoint NG virtual firewall.

Implementing a Network Service By Using the Sample Cartridges

The sample network protection service uses the following software components:

UIM 7.3.3 and the Network Service Orchestration Solution 1.1.1 cartridges
OpenStack VIM, with Open vSwitch capability
OpenDaylight SDN Controller
Software images for the firewall VNFs

Note:

By default, the UIM_Home/config/nso.properties file displays the username and password of the Network Service Orchestration solution user in plain text. You must encrypt the password by running the EncryptText ruleset in UIM.

To encrypt the password:

Create a text file and type the password.
Save and close the file.
In UIM, in the Administration group of the navigation section, click Execute Rulesets.
In the Ruleset list, select the EncryptText ruleset, and enter the path and file name of the text file that contains the password in plain text and click Process.

UIM displays the encrypted password.

To implement the network protection service:

In OpenStack, create a tenant or reference an existing tenant with administrator privileges.
Create a management network with the name nfvo-mgmt or reference an existing management network that can be shared by all the components of the solution. For example,

The management network requires, at a minimum:
- One IP address for each:
  - Machine on which UIM is installed
  - Virtual machine on which Open vSwitch is installed
  - Machine on which OpenDaylight is installed
- One IP address for each virtual machine on which you want to bring up the VNFs
Connect the management network and the external network to a virtual router. This enables you to use floating IP addresses for providing access to the data center.
Create a customer-side network that facilitates the customer's network traffic to reach the VNFs.

Table 3-4 shows examples of IP addresses and IP address ranges of network and subnet configuration for the customer-side network.

Table 3-4 Example of Network and Subnet Configuration for Customer-side Network

CIDR IP Allocation Pool Gateway IP DHCP Enabled Additional Routes DNS Name Server

192.168.2.0/24

Start 192.0.2.145

End 192.0.2.250

192.0.2.1

Yes

None

None
Create an Internet-side network that facilitates the traffic from the customer-side network to the Internet.

Table 3-5 shows examples of IP addresses and IP address ranges of network and subnet configuration for the Internet-side network.

Table 3-5 Example of Network and Subnet Configuration for Internet-side Network

CIDR IP Allocation Pool Gateway IP DHCP Enabled Additional Routes DNS Name Server

192.168.2.0/24

Start 192.0.2.2

End 192.0.2.254

192.0.2.1

No

None

None
Create packet-in and packet-out networks.

Table 3-6 shows examples of IP addresses and IP address ranges of network and subnet configuration for the packet-in network.

Table 3-6 Example of Network and Subnet Configuration for Packet-in Network

CIDR IP Allocation Pool Gateway IP DHCP Enabled Additional Routes DNS Name Server

192.168.2.128/25

Start 192.0.2.129

End 192.0.2.140

-

Yes

None

None

Table 3-7 shows examples of IP addresses and IP address ranges of network and subnet configuration for the packet-out network.

Table 3-7 Example of Network and Subnet Configuration for Packet-out Network

CIDR IP Allocation Pool Gateway IP DHCP Enabled Additional Routes DNS Name Server

192.168.2.0/25

Start 192.0.2.115

End 192.0.2.126

192.0.2.1

Yes

None

None
Start the OpenDaylight virtual machine on the management network.
Start the Open vSwitch virtual machines on the management network, customer-side network, Internet-side network, packet-in network, and packet-out network.
On the Open vSwitch virtual machine, run the following commands:
- Create a steering bridge:
```
ovs-vsctl add-br steering
```
  where steering is the name of the integration bridge.
- Add the interfaces of the networks you created to the steering bridge:
```
ovs-vsctl add-port steering networkInterface
```
  where networkInterface is the name of the network interface. For example, eth1.
```
ovs-vsctl add-port steering eth1
ovs-vsctl add-port steering eth2
ovs-vsctl add-port steering eth3
ovs-vsctl add-port steering eth4
ovs-vsctl add-port steering eth5
```
- Set the IP address and port number of the OpenDaylight virtual machine as the controller to the steering bridge:
  
  ovs-vsctl set-controller steering tcp:OpenDaylight_IPAddress
  
  ovs-vsctl set bridge steering protocols="OpenFlow13"
  
  where OpenDaylight_IPAddress is the IP address of the OpenDaylight virtual machine.
- Get the port numbers:
  
  ovs-vsctl -- --columns=name_of_port list Interface
  
  where name_of_port is the name of the Open vSwitch port.
Open the UIM_Home/config/nso.properties file and update the following parameters.
- startIpAddress. Specify the subnet start IP address. By default, when the solution creates a network, the subnet IP address starts with 192.168.0.0.
- NSO_HOST: IPv4address. Specify the host on which UIM is installed. By default, the solution considers the host on which the UIM server is running. If the server is running on a private network that is unavailable to external network, specify a reachable IP address for the server.
- NSO_USERNAME: username
  
  where username is the username of the server on which UIM is installed.
- NSO_PASSWORD: encrypted_password
  
  where encrypted_password is the encrypted password of the server on which UIM is installed.

CIDR	IP Allocation Pool	Gateway IP	DHCP Enabled	Additional Routes	DNS Name Server
192.168.2.0/24	Start 192.0.2.145 End 192.0.2.250	192.0.2.1	Yes	None	None

CIDR	IP Allocation Pool	Gateway IP	DHCP Enabled	Additional Routes	DNS Name Server
192.168.2.0/24	Start 192.0.2.2 End 192.0.2.254	192.0.2.1	No	None	None

CIDR	IP Allocation Pool	Gateway IP	DHCP Enabled	Additional Routes	DNS Name Server
192.168.2.128/25	Start 192.0.2.129 End 192.0.2.140	-	Yes	None	None

CIDR	IP Allocation Pool	Gateway IP	DHCP Enabled	Additional Routes	DNS Name Server
192.168.2.0/25	Start 192.0.2.115 End 192.0.2.126	192.0.2.1	Yes	None	None

Open the UIM_Home/config/NPaaS_NSD.properties file and specify values for the parameters listed in Table 3-8:

Table 3-8 Parameters in the NPaaS Network Service Descriptor Properties File

Parameter	Description
NPaaS_NSD.default.serviceArea	Specify a default service area for the NPaaS_NSD network service descriptor.
NPaaS_NSD.default.dataCenter	Specify a default data center for the NPaaS_NSD network service descriptor.
NPaaS_NSD.ManagementNetwork	Specify the name of the management network. The management network is the VLD Name that is specified in the NPaaS_NSD.xml file.
NPaaS_NSD.Data_IN	Specify the name of the data-in network.
NPaaS_NSD.Data_OUT	Specify the name of the data-out network.
sdnController.NPaaS_NSD	Specify an implementation class for the SDN controller interface. The default implementation class is com.oracle.communications.inventory.nso.nfvi.sdn.ODLManager.
npaas.ovs.pktInToOVSPort	Specify the Open vSwitch port number of the packet-in network.
npaas.ovs.pktOutToOVSPort	Specify the Open vSwitch port number of the packet-out network.
npaas.ovs.custNetToOVSPort	Specify the Open vSwitch port number of the customer-side network.
npaas.ovs.internetToOVSPort	Specify the Open vSwitch port number of the internet-side network.
npaas.ovs.bridge_id	Specify the bridge ID for the Open VSwitch and prefix it with openflow. For example, openflow:OpenFlow_ID, where OpenFlow_ID is the OpenFlow ID. To retrieve the OpenFlow ID, in OpenDaylight call the following OpenDaylight REST API: http://odlIPaddress:port/restconf/operational/opendaylight-inventory:nodes/ where odlIPaddress is the IP address and port is the port number of the OpenDaylight virtual machine.

Redeploy the Network Service Orchestration solution cartridges in Design Studio. See "Configuring UIM for the Network Service Orchestration Solution" for information about deploying the cartridges in the specified order.
Register the VIM by calling the corresponding RESTful API. See "Registering the VIM" for instructions.
Discover the VIM resources. See "Discovering VIM Resources" for instructions.

Designing New Network Services and VNF Services

You can define and model network services and VNFs depending on the network functions that you want to virtualize on your network.

To define and model network services and VNFs, you work in Design Studio. In Design Studio, you define specifications and properties for your network services, VNFs, and their hierarchical and related components.

To model a network service with a VNF, you create two cartridges in Design Studio: one cartridge for the VNF and one cartridge for the network service.

In the cartridge for the Network Service, do the following:

Specify the following UIM entity specifications:
- One Service specification for the Network Service
- One Service Configuration specification for the network service
Create a technical actions file for the Network Service specification. See "Creating a Technical Actions File" for more information.
Create a network service descriptor file for the Network Service specification. See "Creating a Descriptor File" for more information.
Create a custom properties file for the Network Service specification.
Create custom code for extension.

In the cartridge for the VNF Descriptor, do the following:

Specify the following UIM entity specifications:
- One Service specification for the VNF
- One Service Configuration specification for the VNF
- A Logical Device specification for the VNF
Create a technical actions file for the VNF Service specification. See "Creating a Technical Actions File" for more information.
Create a VNF descriptor file for the VNF Service specification. See "Creating a Descriptor File" for more information.
Create a configuration file for the VNF.
Create a post-configuration template configuration file for the VNF. See "About the VNF Configuration Files" for more information.
Create a template file for the VNF.
Create custom code for extension.