5.2.4. ONAP Heat Networking

ONAP defines two types of networks: External Networks and Internal Networks.

5.2.4.1. External Networks

An ONAP external network is created by using VID or by invoking SO directly to instantiate the network. External networks are orchestrated separately, independent of VNFs. A network instantiated via VID or by invoking SO directly is managed by ONAP and is inventoried in AAI.

An external network can be created by using one of the following resources:

  • OS::Neutron::Net

  • OS::Neutron::ProviderNet

  • OS::ContrailV2::VirtualNetwork

An external network MAY be used to

  • Connect a VM in a VNF to VMs in another VNF

  • Connect a VM in a VNF to an external gateway or external router

  • Connect a VM in a VNF to other VMs in the same VNF

An external network may be designed to perform

  • All three functions listed above or

  • Perform only two functions listed above or

  • Perform only one function listed above

Requirement: R-16968 ../../_images/arrow-right-circle.svg
target: VNF
keyword: MUST NOT
updated: frankfurt
validation_mode: static

A VNF’s Heat Orchestration Templates MUST NOT include heat resources to create an ONAP external network.

An ONAP external network MUST be instantiated by using VID or by invoking SO directly.

Requirement: R-00606 ../../_images/arrow-right-circle.svg
target: VNF
keyword: MAY
updated: frankfurt

A VNF MAY be connected to zero, one or more than one ONAP external network.

Requirement: R-57424 ../../_images/arrow-right-circle.svg
target: VNF
keyword: MAY
updated: frankfurt
validation_mode: none

A VNF’s port connected to an ONAP external network MAY use the port for the purpose of

  • Connecting a VM in the VNF to VMs in another VNF and/or

  • Connecting a VM in the VNF to an external gateway or external router and/or

  • Connecting a VM in the VNF to other VMs in the same VNF

Requirement: R-99794 ../../_images/arrow-right-circle.svg
target: VNF
keyword: MUST
updated: frankfurt
validation_mode: none

An ONAP external network MUST have one subnet. An external network MAY have more than one subnet.

ONAP enforces a naming convention for resource IDs and resource property parameters associated with external networks. ONAP Heat Resource ID and Parameter Naming Convention provides additional details.

5.2.4.2. Internal Networks

An ONAP internal network is created by the VNF’s Heat Orchestration Template. That is, the VNF’s Heat Orchestration Template contains the heat resources to instantiate the network. An ONAP internal network is not inventoried by AAI and can not be managed independently of the VNF.

An ONAP internal network MUST only be used for connecting a VM in the VNF to other VMs in the same VNF.

An ONAP internal network MUST NOT be used for connecting a VM in the VNF to VMs in another VNF or connecting a VM in the VNF to an external gateway and/or external router.

The reason for this is for operational simplicity. An ONAP internal network will be deleted when the VNF that created the network (referred to as VNF A) is deleted. If a different VNF (referred to as VNF B) attaches to the ONAP internal network created by VNF A, then VNF B must be deleted prior VNF A.

In addition, if an ONAP internal network is used to connect two (or more) VNFs, there is no record in AAI inventory. This could lead to additional operational complications.

Requirement: R-87096 ../../_images/arrow-right-circle.svg
target: VNF
keyword: MAY
updated: frankfurt

A VNF MAY contain zero, one or more than one ONAP internal network.

Requirement: R-35666 ../../_images/arrow-right-circle.svg
target: VNF
keyword: MUST
updated: frankfurt
validation_mode: static

If a VNF has an ONAP internal network, the VNF’s Heat Orchestration Template MUST include the heat resources to create the ONAP internal network.

A VNF’s ONAP internal network is created using Neutron Heat Resources (e.g., OS::Neutron::Net, OS::Neutron::Subnet, OS::Neutron::ProviderNet) and/or Contrail Heat Resources (e.g., OS::ContrailV2::VirtualNetwork, OS::ContrailV2::NetworkIpam).

Requirement: R-52425 ../../_images/arrow-right-circle.svg
target: VNF
keyword: MUST
updated: frankfurt
validation_mode: none

A VNF’s port connected to an ONAP internal network MUST use the port for the purpose of reaching VMs in the same VNF.

Requirement: R-46461 ../../_images/arrow-right-circle.svg
target: VNF
keyword: MUST NOT
updated: frankfurt
validation_mode: none

A VNF’s port connected to an ONAP internal network MUST NOT use the port for the purpose of reaching VMs in another VNF and/or an external gateway and/or external router.

Requirement: R-16241 ../../_images/arrow-right-circle.svg
target: VNF
keyword: MUST
updated: frankfurt
validation_mode: static

A VNF’s ONAP internal network MUST have one subnet. A VNF’s ONAP internal network MAY have more than one subnet.

Requirement: R-86972 ../../_images/arrow-right-circle.svg
target: VNF
keyword: SHOULD
updated: frankfurt

A VNF SHOULD create the ONAP internal network in the VNF’s Heat Orchestration Template’s Base Module.

Requirement: R-22688 ../../_images/arrow-right-circle.svg
target: VNF
keyword: MUST
updated: frankfurt
validation_mode: static

When a VNF’s Heat Orchestration Template creates an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666) and the ONAP internal network needs to be shared between modules within a VNF, the ONAP internal network MUST be created either in the

  • the base module

  • a nested YAML file invoked by the base module

and the base module MUST contain an output parameter that provides either the network UUID or network name.

  • If the network UUID value is used to reference the network, the output parameter name in the base module MUST follow the naming convention int_{network-role}_net_id

  • If the network name in is used to reference the network, the output parameter name in the base template MUST follow the naming convention int_{network-role}_net_name

The {network-role} MUST be the network-role of the ONAP internal network created in the Base Module.

The Base Module Output Parameter MUST be declared in the parameters: section of the Incremental Module(s) where the OS::Neutron::Port resource(s) is attaching to the ONAP internal network.

ONAP does not programmatically enforce a naming convention for parameters for internal network. However, a naming convention is provided that must be followed. ONAP Heat Resource ID and Parameter Naming Convention provides additional details.