3 Designing and Onboarding Network Services, VNFs, and PNFs

About Network Service Descriptor Files

Network Service descriptor files describe the deployment requirements, operational behavior, and policies required by network services based on them. You use one descriptor file for each network service.

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

You use the network service descriptor file to do the following:

• Describe the descriptor information. See "Describing Descriptor Information" for more information.

• Describe the VNF descriptor references. See "Describing VNF Descriptor References" for more information.

• Describe the PNF descriptor references. See "Describing PNF Descriptor References" for more information.

• Describe the networks by either creating them or by referencing existing networks and specifying network types. For each network, specify the VNF connection points that terminate on the network. See "Describing Networks" for more information.

• Describe the service flavors for the network service. See "Describing Service Flavors" for more information.

• Describe the endpoints that the network service can have. See "Describing Endpoints" for more information.

• Describe the rules to determine how the network traffic is routed in the network service. See "Describing Rules" for more information.

• Describe the policies and their mappings to the network forwarding paths (NFPs). See "Describing Policies" for more information.

• Describe the VNF forwarding graphs (VNFFGs) that include one or more network forwarding paths (NFPs) that determine how network traffic is routed in a network service. See "Describing VNF Forwarding Graphs" for more information.

Describing Descriptor Information

In the network service descriptor file, you describe descriptor information, such as descriptor ID, descriptor name, vendor name, and descriptor version.

The following text shows the elements that enable you to provide information about the network service descriptor XML file:

<nsd id="network_service_descriptor_id" name="network_service_descriptor_name">
<vendor>vendor_name</vendor>
<version>descriptor_version</version>

Table 3-1 describes the parameters you specify to provide information about the network service descriptor XML file.

The following text shows the elements that provide descriptor information in the NPaas.xml sample network service descriptor file:

<nsd id="NPaas" name="NPaas">
<vendor>Oracle</vendor>
<version>1.0</version>

Describing VNF Descriptor References

In the network service descriptor file, you reference the descriptors of all the VNFs that you want to include in the network service.

You reference the VNF descriptors in the network service descriptor file as follows:

<vnfd-reference ref-id="vnf_descriptor_id"/>

where:

• vnf_descriptor_id is the ID of the VNF descriptor that you want to include in the network service.

The following is an example of the vnfd-reference element in the NPaas.xml sample network service descriptor file:

<!-- Multiple VNFs are supported. -->
<vnfd-reference ref-id="Juniper_vSRX"/>
<vnfd-reference ref-id="Checkpoint_NG_FW"/>

Describing PNF Descriptor References

In the network service descriptor file, you reference the descriptors of all the PNFs that you want to include in the network service.

You reference the PNF descriptors in the network service descriptor file as follows:

<pnfd-reference ref-id="pnf_descriptor_id"/>

where:

• pnf_descriptor_id is the ID of the PNF descriptor that you want to include in the network service.

The following is an example of the pnfd-reference element in the ResidentialGateway.xml sample network service descriptor file:

<!-- Multiple PNFs are supported. -->
<pnfd-reference ref-id="Cisco_xRV"/>

Describing Networks

In the network service descriptor 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.

The following text shows the parameters that you specify for a virtual link in a network service descriptor XML file:

<virtual-link id= "virtual_link_id" name="virtual_link_name" isReferenced="value_reference" isDHCPEnabled="value_DHCP" ipVersion="ip_version">     
  <connection-point-reference ref-id="connection_point_id" 
   vnfd-ref-id="vnf_descriptor_id"/>
  <connection-point-reference ref-id="connection_point_id" 
   vnfd-ref-id="vnf_descriptor_id"/>
   <extension type="extension_type" handler="extension_handler">
       <parameter name="parameter_name" value="parameter_value"/>
   </extension>
</virtual-link>

Table 3-2 describes the parameters you specify for a virtual link in the network service descriptor XML file.

vim_Id.network_service_descriptor.network_name

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

<!-- Multiple virtual links are supported. -->
<!-- isReferenced="true" means that network is not managed by NFV Orchestration e.g. External networks in Provider Network -->
<virtual-link id="ManagementNetwork" name="ManagementNetwork" isReferenced="true" isDHCPEnabled="false" ipVersion="IPv4">
   <connection-point-reference ref-id="CP03" vnfd-ref-id="Juniper_vSRX"/>
   <connection-point-reference ref-id="CP03" vnfd-ref-id="Checkpoint_NG_FW"/>
</virtual-link>

<virtual-link id="Data_IN" name="Data_IN" isReferenced="false" isDHCPEnabled="false" ipVersion="IPv4">
   <connection-point-reference ref-id="CP01" vnfd-ref-id="Juniper_vSRX"/>
   <connection-point-reference ref-id="CP01" vnfd-ref-id="Checkpoint_NG_FW"/>

<!-- If no handler is provided, NFV Orchestration will use its default VirtualLinkAddressHandler. -->
 <!-- Otherwise provide the fully qualified class name of the handler implementation class. e.g., handler="com.oracle.impl.VLHandlerImpl" -->
   <extension type="CreateVirtualLink">
       <parameter name="subnetAddress" value="192.0.2.1/27"/>
   </extension>
</virtual-link>
 
<virtual-link id="Data_OUT" name="Data_OUT" isReferenced="false" isDHCPEnabled="false" ipVersion="IPv4">
   <connection-point-reference ref-id="CP02" vnfd-ref-id="Juniper_vSRX"/>
   <connection-point-reference ref-id="CP02" vnfd-ref-id="Checkpoint_NG_FW"/>
   <extension type="CreateVirtualLink">
       <parameter name="subnetAddress" value="192.0.2.21/30"/>
   </extension>
 </virtual-link>

Describing Service Flavors

In the network service descriptor file, you can describe service flavors wherein you specify constituent VNFs, reference the VNF deployment flavors defined for the constituent VNFs in their respective VNF descriptors, and specify the minimum and maximum VNF instances that must be included in the network service.

The following text shows the pattern in which you describe the service flavors in a network service descriptor file.

<service-flavor id="service_flavor_id" name="service_flavor_name">
   <constituent-vnfd>
       <vnfd-reference ref-id="vnf_descriptor_id"/>
       <deployment-flavor-reference ref-id="vnf_deployment_flavor_id"/>
       <min-instances>min_vnf_instances</min-instances>
       <max-instances>max_vnf_instances</max-instances>
   </constituent-vnfd>
</service-flavor>

Table 3-3 describes the parameters you specify for a service flavor in the network service descriptor XML file.

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

<service-flavor id="Checkpoint" name="Checkpoint">
<!-- Multiple VNFs are supported.>
   <constituent-vnfd>
       <vnfd-reference ref-id="Checkpoint_NG_FW"/>
       <deployment-flavor-reference ref-id="premium"/>
       <min-instances>1</min-instances>
       <max-instances>1</max-instances>
   </constituent-vnfd>
</service-flavor>

<service-flavor id="Juniper" name="Juniper">
   <constituent-vnfd>
       <vnfd-reference ref-id="Juniper_vSRX"/>
       <deployment-flavor-reference ref-id="standard"/>
       <min-instances>1</min-instances>
       <max-instances>1</max-instances>
   </constituent-vnfd>
</service-flavor>

Describing Endpoints

In the network service descriptor file, you can specify the number of endpoints the networks can have.

The following text shows the pattern in which you describe the network service endpoints in a network service descriptor file.

<endpoint id="endpoint_id" name="endpoint_name" <type>endpoint_type</type>
  <vld-reference ref-id="virtual_link_descriptor_id"/>
  <connection-point-reference ref-id="connection_point_id" vnfd-ref-id="vnf_descriptor_id"/>
</endpoint>

Table 3-4 describes the parameters you specify for network service endpoints in the network service descriptor XML file.

The following text shows an endpoint element in the NPaaS.xml sample network service descriptor file:

<endpoint id="SERVICE_EP1" name="SERVICE_EP1" type="FLOATING">
  <vld-reference ref-id="Data"/>
  <connection-point-reference ref-id="CP01" vnfd-ref-id="Juniper_vSRX"/>
</endpoint>
<endpoint id="SERVICE_EP2" name="SERVICE_EP2" type="FLOATING">
  <vld-reference ref-id="Data"/>
  <connection-point-reference ref-id="CP02" vnfd-ref-id="Juniper_vSRX"/>
</endpoint>

Describing Rules

In the network service descriptor file, you can define rules that enable you to specify specific conditions as name-value pairs to control the type of the network traffic in a network service.

The following text shows the pattern in which you describe the rules in a network service descriptor file.

<rule id="rule_id" name="rule_name" type="rule_type">
  <parameter name="name" value="value"/>
  <parameter name="name" value="value"/>
</rule>

Table 3-5 describes the parameters you specify for rules in the network service descriptor XML file.

The following text shows a rule element in the NPaaS.xml sample network service descriptor file:

<!-- Multiple rules are supported. -->
<!-- Rules define the conditions or constraints.  -->
<rule id="rule1" name="rule1" type="traffic-classification>
  <parameter name="type" value="video"/>
  <parameter name="protocol" value="UDP"/>
 </rule>
<rule id="rule2" name="rule2" type="traffic-classification>
  <parameter  name="QOS" value="5">
  <parameter  name="protocol" value="TCP">
</rule>

Describing Policies

In the network service descriptor file, you can define traffic classification policies that enable you to specify the type of network traffic to be carried on the forwarding paths.

The following text shows the pattern in which you describe the policies for a network service in a network service descriptor file.

<policy id="policy_id" name="policy_name" type="policy_type" default="default">
  <rule-reference ref-id="rule_id" action="nfp_id" vnffg-ref-id="vnffg_id"/>
  <rule-reference ref-id="rule_id" action="nfp_id" vnffg-ref-id="vnffg_id"/>
</policy>

Table 3-6 describes the parameters you specify for policies in the network service descriptor XML file.

The following text shows a policy element in the NPaaS.xml sample network service descriptor file:

<!-- Multiple policies are supported. -->
<!-- Policies define the rules and the corresponding action to be taken.  -->
<policy id="premium" name="premium" type="traffic-classification default="true">
<rule-reference ref-id="rule1" action="nfp-ref-id:nfp1" vnffg-ref-id="vnffg1"/>
<rule-reference ref-id="rule2" action="nfp-ref-id:nfp2" vnffg-ref-id="vnffg1"/>
</policy>
<policy id="standard" name="standard" type="traffic-classification>
<rule-reference ref-id="rule1" action="nfp1" vnffg-ref-id="vnffg1"/>
</policy>

Describing VNF Forwarding Graphs

In the network service descriptor file, you can describe VNF forwarding graphs (VNFFGs) that include one or more network forwarding paths (NFPs) that define how the network traffic should be routed through the VNF connection points in a network service.

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

<vnffg id="vnffg_id" name="vnffg_name" default="default">
   <vnfd-reference ref-id="vnf_descriptor_id"/>

   <vld-reference ref-id="virtual_link_descriptor_id"/>

   <endpoint-reference ref-id="endpoint_id"/>
   <endpoint-reference ref-id="endpoint_id"/>

   <network-forwarding-path id="nfp_id" name="nfp_name">
       <forwarding-policy>forwarding_policy_type</forwarding-policy>
       <source-endpoint-reference ref-id="source_endpoint_id"/>
       <connection-point-reference ref-id="connection_point_id" vnfd-ref-id="vnf_descriptor_id" order="connection_point_order"/>
       <connection-point-reference ref-id="connection_point_id" vnfd-ref-id="vnf_descriptor_id" order="connection_point_order"/>
       <destination-endpoint-reference ref-id="destination_endpoint_id"/>
   </network-forwarding-path>
</vnffg>

Table 3-7 describes the parameters you specify for a VNF forwarding graph (VNFFG) in the network service descriptor XML file.

<network-forwarding-path id="nfp1" name="nfp1">
  <forwarding-policy>SYMMETRIC</forwarding-policy>
  <source-endpoint-reference ref-id="CP01"/>
  <connection-point-reference ref-id="CP11" vnfd-ref-id="VNFD1" order="1"/>
  <connection-point-reference ref-id="CP11" vnfd-ref-id="VNFD1" order="2"/>
  <connection-point-reference ref-id="CP21" vnfd-ref-id="VNFD2" order="3"/>
  <connection-point-reference ref-id="CP24" vnfd-ref-id="VNFD2" order="4"/>
  <connection-point-reference ref-id="CP31" vnfd-ref-id="VNFD3" order="5"/>
  <connection-point-reference ref-id="CP32" vnfd-ref-id="VNFD3" order="6"/>
  <destination-endpoint-reference ref-id="CP41"/>
</network-forwarding-path>

The following text shows a VNFFG element in the NPaaS.xml sample network service descriptor file:

<vnffg id="data-vnffg1" name="data-vnffg1" default="true">
   <vnfd-reference ref-id="Juniper_vSRX"/>

   <vld-reference ref-id="Data"/>

   <endpoint-reference ref-id="Service_EP1"/>
   <endpoint-reference ref-id="Service_EP2"/>

<!-- Multiple network forwarding paths are supported. -->
   <network-forwarding-path id="nfp1" name="nfp1">
       <forwarding-policy>SYMMETRIC</forwarding-policy>
       <source-endpoint-reference ref-id="Service_EP1"/>
       <connection-point-reference ref-id="CP01" vnfd-ref-id="VNFD1" order="1"/>
       <connection-point-reference ref-id="CP02" vnfd-ref-id="VNFD1" order="2"/>
       <destination-endpoint-reference ref-id="Service_EP2"/>
   </network-forwarding-path>
</vnffg>

About VNF Descriptor Files

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

NFV Orchestration includes the following sample VNF descriptor files:

• Juniper_vSRX.xml. This is the descriptor file for the Juniper vSRX firewall VNF.

• Checkpoint_NG_FW.xml. This is the descriptor file for the Checkpoint NG firewall VNF.

You use virtual network function descriptor file to do the following:

• Describe the VNF descriptor information. See "Describing VNF Descriptor Information" for more information.

• Describe the EMS and Heat interface details. See "Describing the EMS and Heat Interface Details" for more information.

• Describe the connection points for the VNF. See "Describing VNF Connection Points" for more information.

• Describe the internal virtual links for the internal connection points of the Virtual Network Function Components (VNFCs). See "Describing Internal Virtual Links" for more information.

• Describe the Virtual Deployment Unit (VDU) flavors. See "Describing Virtual Deployment Unit Flavors" for more information.

• Describe the VDU images. See "Describing VDU Images" for more information.

• Describe the VDUs on which you want to install the VNFCs. See "Describing Virtual Deployment Units" for more information.

• Describe the VNF deployment flavors. See "Describing VNF Deployment Flavors" for more information.

Describing VNF Descriptor Information

In the VNF descriptor file, you provide the VNF descriptor information, such as descriptor ID, descriptor name, vendor name, VNF descriptor version, and VNF version.

The following text shows the elements that enable you to provide information about the VNF descriptor XML file:

<nsd id="network_service_descriptor_id" name="network_service_descriptor_name">
<vendor>vendor_name</vendor>
<version>descriptor_version</version>
<vnf-version>vnf_version</vnf-version>

Table 3-8 describes the parameters you specify to provide information about the VNF descriptor XML file.

The following text shows the elements that provide descriptor information in the Juniper_vSRX.xml sample VNF descriptor file:

<vnfd id="Juniper_vSRX" name="Juniper_vSRX">
<vendor>Oracle</vendor>
<version>1.0</version>
<vnf-version>1.0</vnf-version>

Describing the EMS and Heat Interface Details

In the VNF descriptor file, you can specify the EMS that manages the configuration of a VNF. You can also specify whether you want to use Heat templates to orchestrate the VNF. If an EMS manages a VNF's configuration, you must register that EMS before performing any lifecycle actions on the VNF.

The following text shows the pattern in which you describe the EMS and VIM interface details in a VNF descriptor file.

<integration>
    <ems>ems_name</ems>
    <hasheattemplate>value_heat_template</hasheattemplate>
</integration>

Table 3-9 describes the parameters you specify for the EMS and VIM details in the VNF descriptor XML file.

The following text shows an integration element in the Juniper_vSRX.xml sample VNF descriptor file:

<integration>
    <ems>IPSA</ems>
    <hasheattemplate>true</hasheattemplate>
</integration>

Describing VNF Connection Points

In the VNF descriptor file, you can specify the internal, external, and management connection points for the VNF.

The following text shows the pattern in which you describe the internal, external, and management connection points in a VNF descriptor file.

<connection-point id="connection_point_id" name="connection_point_name" type="connection_point_type"/>

Table 3-10 describes the parameters you specify for internal and external connection points in the VNF descriptor XML file.

The following text shows a connection point element in the Juniper_vSRX.xml sample VNF descriptor file:

<!-- Multiple connection points are supported. -->
<connection-point id="CP03" name="CP03" type="MANAGEMENT"/>
<connection-point id="CP01" name="CP01" type="EXTERNAL"/>
<connection-point id="CP02" name="CP02" type="EXTERNAL"/>

Describing Internal Virtual Links

In the VNF descriptor file, you can define the connectivity between the components within a VNF as internal virtual links. For each internal virtual link, specify the internal connection points that connect the internal virtual link to different components within a VNF.

The following text shows the pattern in which you describe the internal virtual links in a VNF descriptor file.

<virtual-link id="virtual_link_id" name="virtual_link_name">
    <connection-point-reference ref-id="connection_point_id"/>
    <connection-point-reference ref-id="connection_point_id">
        <extension type="extension_type" handler="extension_handler">
          <parameter name="parameter_name" value="parameter_value" />
          <parameter name="parameter_name" value="parameter_value" />
        </extension>
</virtual-link>

Table 3-11 describes the parameters you specify for internal virtual links in the VNF descriptor XML file.

The following text shows a virtual link element that you specify for an internal virtual link of a VNF in a sample VNF descriptor file:

<!-- Multiple Internal Virtual Links are supported. -->
<!-- Specifying Internal Virtual Links is Optional -->
<virtual-link id="InternalVL" name="InternalVL">
    <connection-point-reference ref-id="CP04"/>
    <connection-point-reference ref-id="CP05"/>
       <security enabled="true">
           <extension type="SecurityGroups" handler="com.oracle.impl.ExtnImpl">
          <!-- Multiple security groups are supported. -->
          <parameter name="security_groups" value="open, default"/>
       </security>
</virtual-link>

Describing Virtual Deployment Unit Flavors

In the VNF descriptor file, you can define VDU deployment flavors that represent specific deployment of a VDU supporting specific key performance indicators (KPIs), such as compute, memory, and storage capacity.

The following text shows the pattern in which you describe the VDU flavor in a VNF descriptor file.

<vdu-flavor id="vdu_flavor_id" name="vdu_flavor_name">
   <cpu>cpu</cpu>
   <memory>memory</memory>
   <storage>disk_space</storage>
</vdu-flavor>

Table 3-12 describes the parameters you specify for a VDU flavor in the VNF descriptor XML file.

The following text shows a vdu-flavor element in the Juniper_vSRX.xml sample VNF descriptor file:

<vdu-flavor id="vsrx.small" name="vsrx.small">
   <cpu>2</cpu>
   <memory>2GB</memory>
   <storage>20GB</storage>
</vdu-flavor>
<vdu-flavor id="vsrx.medium" name="vsrx.medium">
   <cpu>2</cpu>
   <memory>4GB</memory>
   <storage>20GB</storage>
</vdu-flavor>
<vdu-flavor id="m1.medium" name="m1.medium">
   <cpu>2</cpu>
   <memory>4GB</memory>
   <storage>40GB</storage>
</vdu-flavor>

Describing VDU Images

In the VNF descriptor file, you can specify the VDU images that you want to instantiate for a VNF.

The following text shows the pattern in which you describe the VDU images in a VNF descriptor file.

<image id="image_id">
    <software-image name="image_name" version="image_version">
        <extension type="extension_type" handler="extension_handler">
            <parameter name="parameter_name" value="parameter_value"/>
            <parameter name="parameter_name" value="parameter_value"/>
        </extension>
    </software-image>
</image>

Table 3-13 describes the parameters you specify for a VDU image in the VNF descriptor XML file.

The following text shows an image element in the Juniper_vSRX.xml sample VNF descriptor file:

<image id="vsrx-v1.0" >
        <software-image name="vsrx-12.1X47-D20.7-npaas-v0.3" version="1.0" >
                <extension type="ImageCredentials" handler="oracle.communications.inventory.nso.extensions.impl.ImageCredentialsHandlerImpl">
                    <parameter name="username" value="root" />
                    <parameter name="password" value="labms01" />
                </extension>
        </software-image>
    </image>

Describing Virtual Deployment Units

In the VNF descriptor file, you can describe Virtual Deployment Units, which represent the virtual machines on which VNF components (VNFCs) can be deployed.

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

<vdu id="vdu_id" name="vdu_name"> 
   <image-reference ref-id="image_id"/>
   <vnfc id="vnfc_id" name="vnfc_name"> 
      <connection-point-reference ref-id="connection_point_id" order="connection_point_order"/>
      <connection-point-reference ref-id="connection_point_id" order="connection_point_order">  
      <connection-point-reference ref-id="connection_point_id" order="connection_point_order">  
   </vnfc>
   <security enabled="security_value">
   <!-- Security group values can be provided dynamically during instantiation -->
         <extension type="extension_type" handler="extension_handler">
             <!-- Multiple security groups are supported. -->
             <parameter name="parameter_name" value="parameter_value">
             <parameter name="parameter_name" value="parameter_value">
         </extension>
   </security>
</vdu>

Table 3-14 describes the parameters you specify for a VDU in the VNF descriptor XML file.

The following text shows a vdu element in the Juniper_vSRX.xml sample VNF descriptor file:

<!-- Multiple VDUs are supported. -->
<vdu id="Juniper_vSRX_VDU" name="Juniper_vSRX_VDU"> 
   <image-reference ref-id="vsrx-v1.0"/>
   <vnfc id="vsrxc" name="vsrxc"> 
     <connection-point-reference ref-id="CP03" order="1"/> <!-- Management port will not have VL reference -->
     <connection-point-reference ref-id="CP01" order="2"/> <!-- External CP does not have VL reference -->
     <connection-point-reference ref-id="CP01" order="3"/> <!-- External CP does not have VL reference -->
   </vnfc>
   <security enabled="true">
   <!-- Security group values can be provided dynamically during instantiation -->
   <!-- If no handler is provided, NFV Orchestration will use its default SecurityGroupHandler. -->
   <!-- Otherwise provide the fully qualified class name of the handler implementation class. e.g., handler="com.oracle.impl.SecurityGroupHandlerImpl" -->
         <extension type="SecurityGroups">
             <!-- Multiple security groups are supported. -->
             <parameter name="type" type="VDU">
             <parameter name="security_groups" type="open, default">
         </extension>
         <extension type="SecurityGroups">
             <!-- Multiple security groups are supported. -->
             <parameter name="type" type="CP">
             <parameter name="security_groups" type="all">
             <parameter name="connection_points" type="CP01, CP02">
         </extension>
     </extensions>
   </security>
</vdu>

Describing VNF Deployment Flavors

Deployment flavors give you the flexibility to choose which VDUs should be deployed for the VNF and, in turn, which VNF components should be deployed on those VDUs.

In the VNF descriptor file, you can describe deployment flavors wherein you specify constituent VDUs of the VNF. For each VDU, specify the constituent VNF components, including the minimum and maximum number of VNF component instances that the VDU can have. You can also specify the VDU flavors, including the minimum and maximum VDU instances that the deployment flavor can have.

In addition, you can also define the assurance parameters for various factors. For example, you can define assurance parameters to heal a VNF or scale a VNF in the network service, depending on the CPU utilization of the virtual machine on which the VDUs of a VNF are deployed.

The following text shows the pattern in which you describe the deployment flavor in a VNF descriptor file.

<deployment-flavor id="deployment_flavor_id" name="deployment_falvor_name" default="default">
   <constituent-vdu>
      <vdu-reference ref-id="vdu_id"/>
      <constituent-vnfc>
         <vnfc-reference ref-id="vnfc_id"/>
         <min-instances>min_vnfc_instances</min-instances>
         <max-instances>max_vnfc_instances</max-instances>
      </constituent-vnfc>
      <vdu-flavor-reference ref-id="vdu_flavor_id"/>
      <min-instances>min_vdu_instances</min-instances>
      <max-instances>max_vdu_instances</max-instances>
      <scale-quantity>scale_quantity</scale_quantity>

      <assurance-parameter id="assurance_parameter_id" description="assurance_parameter_description">
          <parameter name="parameter_name" value="parameter_value"/>
          <parameter name="parameter_name" value="parameter_value"/>
          <parameter name="parameter_name" value="parameter_value"/>
      </assurance-parameter>
   </constituent-vdu>
</deployment-flavor>

Table 3-15 describes the parameters you specify for deployment flavors in the VNF descriptor XML file.

The following text shows the deployment flavor element in the Juniper_vSRX.xml sample VNF descriptor file:

<!-- Multiple deployment flavors are supported. -->
<deployment-flavor id="standard" name="standard" default="true">
<!-- Each deployment flavor can further choose which VDU, and which VNFC in the VDU to deploy. -->
<!-- For example: depFlavor1 only selects VDUTypeA, VNFCTypeX to deploy, but not VNFCTypeY. -->

   <constituent-vdu>
      <vdu-reference ref-id="Juniper_vSRX_VDU"/>
      <constituent-vnfc>
         <vnfc-reference ref-id="vsrxc"/>
         <min-instances>1</min-instances>
         <max-instances>1</max-instances>
      </constituent-vnfc>
      <vdu-flavor-reference ref-id="vsrxc"/>
      <min-instances>1</min-instances>
      <max-instances>1</max-instances>
      <scale-quantity>2</scale-quantity>

      <assurance-parameter id="ap1" description="Low CPU Utilization">
          <parameter name="meter_name" value="cpu_util"/>
          <parameter name="value" value="0.0"/>
          <parameter name="condition" value="eq"/>
          <parameter name="action" value="heal"/>
      </assurance-parameter>

      <assurance-parameter id="ap2" description="High CPU Utilization">
          <parameter name="meter_name" value="cpu_util"/>
          <parameter name="value" value="80.0"/>
          <parameter name="condition" value="gt"/>
          <parameter name="action" value="scale"/>
      </assurance-parameter>
   </constituent-vdu>
</deployment-flavor>

About PNF Descriptor Files

PNF descriptor files describe the deployment requirements, operational behavior, and policies required by PNFs that are based on them.

In the PNF descriptor file, you specify:

• Vendor details

• The version of the PNF descriptor

• The software version of the PNF

• Connection points for the PNF

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

<pnfd id="pnf_descriptor_id" name="pnf_descriptor_name">

   <vendor>vendor_name</vendor>
   <version>descriptor_version</version>
   <pnf-version>pnf_version</pnf-version>

   <!-- Multiple connection points are supported. -->
   <connection-point id="connection_point_id" name="connection_point_name"/> 
   <connection-point id="connection_point_id" name="connection_point_name"/>  
   <connection-point id="connection_point_id" name="connection_point_name"/> 

</pnfd>

Table 3-16 describes the parameters you specify to provide information about the PNF descriptor XML file.

NFV Orchestration includes the following sample PNF descriptor file:

• Cisco_xRV.xml. This descriptor file can be used for the Cisco xRV router PNF.

The following text shows the elements in the Cisco_xRV.xml sample PNF descriptor file:

<pnfd id="Cisco_xRV" name="Cisco_xRV">

   <vendor>CISCO</vendor>
   <version>1.0</version>
   <pnf-version>1.0</pnf-version>

   <!-- Multiple connection points are supported. -->
   <connection-point id="CP01" name="CP01"/> 
   <connection-point id="CP02" name="CP02"/>  
   <connection-point id="CP03" name="CP03"/> 

</pnfd>

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:

1. In Design Studio, import all the NFV Orchestration cartridges. See "Setting Up Design Studio for Extending NFV Orchestration" for more information about importing the cartridges into Design Studio.

2. Switch to the Navigator view.

3. In the root directory of the cartridge project, create the following folder structure:

   model/content/product_home/config

4. Right-click on the config folder and create an XML file with the name ServiceSpecificationName.xml for a network service, LogicalDeviceSpecificationName.xml for a VNF, and LogicalDeviceSpecificationName.xml for a PNF.

   where:

   • ServiceSpecificationName is the name of the service specification

   • LogicalDeviceSpecificationName is the name of the logical device specification, which represents a VNF or a PNF.

5. Copy the sample content from the sample cartridge project to the XML file and modify it according to your service requirements.

Creating a Technical Actions File

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

To create a technical actions file:

1. In Design Studio, switch to the Navigator view.

2. In the root directory of the cartridge project, create the following folder structure:

   model/content/product_home/config

3. 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.

4. Copy the sample content from the sample cartridge project to the XML file and modify it according to your service requirements.

Parameters

This section defines input parameters that are required for deploying a VNF. For each parameter, you specify a data type, an optional description, and a default value, which is used if you do not specify a value for the parameter.

When specifying input parameters for the VNF in the Heat template, you are required to follow a specific naming convention. See "Naming Convention for Parameters and Resources in Heat Templates" for more information.

Resources

This section defines the resources that must be created and allocated when deploying a VNF. The resources may include servers, ports, and so on.

When specifying resources for the VNF in the Heat template, you are required to follow a specific naming convention. See "Naming Convention for Parameters and Resources in Heat Templates" for more information.

Outputs

This section defines the parameters that NFV Orchestration gets from the OpenStack and subsequently passes them on to the EMS that manages the configuration of the VNF.

Naming Convention for Parameters and Resources in Heat Templates

Table 3-18 lists the naming convention that you must follow when specifying the input parameters and resources for the VNF in the DHCP-enabled Heat template.

where:

• networkName is the name of the network, which can be Data_IN, Data_OUT, or management network.

• vduName is the name of the constituent VDU of the VNF.

• portName is the name of the VNF connection point for which you are defining a security group.

• connection_point_id is the ID of the VNF connection point for which you are defining a security group.

Naming Convention for Parameters and Resources for Internal Virtual Links in Heat Templates

If your VNF contains internal virtual links, you must follow the naming convention listed in Table 3-19 for specifying the information about the internal virtual links in the Heat template.

where:

• vnfName is the name of the VNF.

• internal_virtual_linkName is the name of the internal virtual link of the VNF.

• connection_point_id is the name of the internal connection point of the VNF.

Mixed DHCP Sample Heat Template

Example 3-2 shows a sample heat template that contains networks in a mixed DHCP configuration in which some networks are DHCP-enabled and some are DHCP-disabled.

In the sample Heat template, the management network and the Data_OUT network are DHCP-enabled; therefore, in the parameters section, the information about these two networks has been specified. However, the Data_IN network is DHCP-disabled, so details about the Data_IN network are not mentioned in the parameters section. Instead, the Heat template retrieves the information about the Data_IN network from NFV Orchestration by using the get_param function for the Data_IN network's CP01_port in the resources section.

heat_template_version: 2014-10-16
 
description: Hot Template to deploy a Juniper_vSRX server
 
parameters:
  Juniper_vSRX_ManagementNetwork:
    type: string
    description: management Network Name
    default: nfvo-poc3-mgmt
  Juniper_vSRX_Data_OUT:
    type: string
    description: data Network Name
  Juniper_vSRX_ManagementNetwork_Cidr:
    type: string
    description: Management Network cidr
  Juniper_vSRX_ManagementNetwork_gatewayip:
    type: string
    description: Management Network Gateway IP address
  Juniper_vSRX_ManagementNetwork_Startip:
    type: string
    description: Management Network Start Ip address
  Juniper_vSRX_ManagementNetwork_endip:
    type: string
    description: Management Network end ip address
  Juniper_vSRX_Data_OUT_Cidr:
    type: string
    description: Data Network cidr
  Juniper_vSRX_Data_OUT_gatewayip:
    type: string
    description: Data Network Gateway IP address
  Juniper_vSRX_Data_OUT_Startip:
    type: string
    description: Data Network Start Ip address
  Juniper_vSRX_Data_OUT_endip:
    type: string
    description: Data Network end ip address
  Juniper_vSRX_VDU_image:
    type: string
    constraints:
      - custom_constraint: glance.image
    default: ufw-v0.1
  Juniper_vSRX_VDU_instName:
    type: string
    default: vsrxHeatInst
  Juniper_vSRX_VDU_security_group:
    type: comma_delimited_list
  Juniper_vSRX_VDU_zone:
    type: string
    default: nova
  Juniper_vSRX_VDU_flavor:
    type: string
    constraints:
      - custom_constraint: nova.flavor
    default: m1.major
  CP01_port:
    type: string
 
resources: 
  ufw:
    type: OS::Nova::Server
    properties:
      name: { get_param: Juniper_vSRX_VDU_instName}
      image: { get_param: Juniper_vSRX_VDU_image}
      flavor: { get_param: Juniper_vSRX_VDU_flavor}
      availability_zone: { get_param: Juniper_vSRX_VDU_zone}
      networks:
       - port: {get_resource: CP03_port}
       - port: {get_param: CP01_port}
       - port: {get_resource: CP02_port}
  CP03_port:
    properties: 
      network: {get_param: Juniper_vSRX_ManagementNetwork} 
      name: CP03
      security_groups: { get_param: Juniper_vSRX_VDU_security_group }
    type: OS::Neutron::Port
  CP02_port:
    properties: 
      network: {get_param: Juniper_vSRX_Data_OUT}
      name: CP02
      security_groups: { get_param: Juniper_vSRX_VDU_security_group }
    type: OS::Neutron::Port
 
outputs:
  server_ipaddress: 
    description: Name of the instance
    value: { get_attr: [ufw, first_address]}

Non-DHCP Sample Heat Template

Example 3-3 shows a sample heat template that contains networks in a DHCP-disabled configuration.

heat_template_version: 2014-10-16
 
description: Hot Template to deploy a Juniper_vSRX server
 
parameters:
  Juniper_vSRX_VDU_image:
    type: string
    constraints:
      - custom_constraint: glance.image
    default: ufw-v0.1
  Juniper_vSRX_VDU_instName:
    type: string
    default: vsrxHeatInst
  Juniper_vSRX_VDU_zone:
    type: string
    default: nova
  Juniper_vSRX_VDU_flavor:
    type: string
    constraints:
      - custom_constraint: nova.flavor
    default: m1.major
  Juniper_vSRX_VDU_security_group:
    type: comma_delimited_list
  CP01_port:
    type: string
  CP02_port:
    type: string
  CP03_port:
    type: string
 
resources: 
  ufw:
    type: OS::Nova::Server
    properties:
      name: { get_param: Juniper_vSRX_VDU_instName}
      image: { get_param: Juniper_vSRX_VDU_image}
      flavor: { get_param: Juniper_vSRX_VDU_flavor}
      availability_zone: { get_param: Juniper_vSRX_VDU_zone}
      networks:
       - port: {get_param: CP03_port}
       - port: {get_param: CP01_port}
       - port: {get_param: CP02_port}
 
outputs:
  server_ipaddress: 
    description: Name of the instance
    value: { get_attr: [ufw, first_address]}

Logical Device Specification

Create a Logical Device specification to represent the VNF. This specification must include the characteristics listed in Table 3-22. These characteristics are provided in the OracleComms_NSO_BaseCartridge cartridge. You can optionally define and include additional characteristics.

Create a Logical Device specification to represent the VDU. This specification must include the characteristics listed in Table 3-23. These characteristics are provided in the OracleComms_NSO_BaseCartridge cartridge. You can optionally define and include additional characteristics.

See the Design Studio Help and the section on ”Working with Characteristics” in the chapter, ”Design Studio Overview” in UIM Concepts for more information about characteristics.

There are no rulesets required for the VNF and VDU Logical Device specifications. You can create custom rulesets to extend the default capabilities, however.

A VNF Logical Device specification must include the specification relationships listed in Table 3-24.

Associate the VNF tag to the VNF Logical Device specification to ensure that UIM correctly handles entities based on this specification. The VNF tag is provided in the OracleComms_NSO_BaseTags cartridge. See "Tagging NFV Orchestration Specifications" for more information.

Associate the VDU tag to the VDU Logical Device specification to ensure that UIM correctly handles entities based on this specification. The VDU tag is provided in the OracleComms_NSO_BaseTags cartridge. See "Tagging NFV Orchestration Specifications" for more information.

Service Specification

Create a Service specification to represent the VNF service. No characteristics or rulesets are required, but you can optionally add them to extend the default capabilities.

Figure 3-2 illustrates the VNF service model.

Figure 3-2 VNF Service Model

A VNF Service specification must include the specification relationships listed in Table 3-25.

Apply the VNF tag to the VNF Service specification to ensure that UIM correctly handles entities based on this specification. The VNF tag is provided in the OracleComms_NSO_BaseTags cartridge. See "Tagging NFV Orchestration Specifications" for more information.

Service Configuration Specification

Create a Service Configuration specification to accompany the VNF Service specification. The Service Configuration specification must include the configuration items listed in Table 3-26.

Define the specification options for the configuration items as shown in Table 3-27.

Associate the following rulesets with the Service Configuration specification. These rulesets are included in the OracleComms_NSO_BaseCartridge cartridge:

• IssueVNFServiceConfig_NSOBaseRulesetExtPt

• AutomateVNFServiceConfig_NSOBaseRulesetExtPt

• Cancel_VNFServiceConfigRulesetExtPt

• CompleteVNFServiceConfig_NSOBaseRulesetExtPt

Logical Device Specification

Create a Logical Device specification to represent the PNF. This specification must include the characteristics listed in Table 3-28. These characteristics are provided in the OracleComms_NSO_BaseCartridge cartridge. You can optionally define and include additional characteristics. See the Design Studio Help and the section on ”Working with Characteristics” in the chapter, ”Design Studio Overview” in UIM Concepts for more information about characteristics.

Associate the following rulesets with the PNF Logical Device specification. These rulesets are included in the OracleComms_NSO_BaseCartridge cartridge.

• CreatePNF_Ruleset. This ruleset validates the create PNF request.

• UpdatePNF_Ruleset. This ruleset validates the update PNF request.

• CreateEMS_Ruleset . This ruleset validates the create EMS request.

• UpdateEMS_Ruleset . This ruleset validates the update EMS request.

A PNF Logical Device specification must include the specification relationships listed in Table 3-29.

Apply the following tags to the PNF Logical Device specification to ensure that UIM correctly handles entities based on this specification. These tags are provided in the OracleComms_NSO_BaseTags cartridge.

• PNF

• EMS

See "Tagging NFV Orchestration Specifications" for more information.

Service Specification

Create a Service specification to represent the PNF service. No characteristics or rulesets are required, but you can optionally add them to extend the default capabilities.

Figure 3-3 shows how a PNF service is modeled.

Figure 3-3 PNF Service Model

A PNF Service specification must include the specification relationships listed in Table 3-30.

Apply the PNF tag to the PNF Service specification to ensure that UIM correctly handles entities based on this specification. The PNF tag is provided in the OracleComms_NSO_BaseTags cartridge. See "Tagging NFV Orchestration Specifications" for more information.

Service Configuration Specification

Create a Service Configuration specification to accompany the PNF Service specification. The Service Configuration specification must include the configuration items listed in Table 3-31.

Define the specification options for the configuration items as shown in Table 3-32.

Associate the following rulesets with the Service Configuration Version specification. These rulesets are included in the OracleComms_NSO_BaseCartridge cartridge.

• IssuePNFServiceConfig_NSOBaseRulesetExtPt

• AutomatePNFServiceConfig_NSOBaseRulesetExtPt

• Cancel_PNFServiceConfigRulesetExtPt

• CompletePNFServiceConfig_NSOBaseRulesetExtPt

Network Service Specification

Create a Network Service specification to represent the network service.

Figure 3-4 illustrates the network service model.

Figure 3-4 Network Service Model

The Network Service specification must include the characteristics listed in Table 3-33. These characteristics are provided in the OracleComms_NSO_BaseCartridge cartridge.

The Network Service specification does not require any rulesets, but you can create custom rulesets to extend the default capabilities.

The Network Service specification must include the specification relationships listed in Table 3-34.

Apply the NetworkService tag to the Network Service specification to ensure that UIM correctly handles entities based on this specification. This tag is provided in the OracleComms_NSO_BaseTags cartridge. See "Tagging NFV Orchestration Specifications" for more information.

Network Service Configuration Specification

Create a Service Configuration specification to accompany the Network Service specification.

The Service Configuration specification must include the configuration items listed in Table 3-35.

Define the specification options for the configuration items as shown in Table 3-36.

Associate the following rulesets with the Service Configuration Version specification. These rulesets are provided in the OracleComms_NSO_BaseCartridge cartridge.

• AutomateNetworkServiceConfig_NSOBaseRulesetExtPt

• IssueNetworkServiceConfig_NSOBaseRulesetExtPt

• CompleteNetworkServiceConfig_NSOBaseRulesetExtPt

• CancelNetworkServiceConfig_NSOBaseRulesetExtPt