1 **5. VNF Modeling Requirements**
2 =====================================
11 This reference document is the VNF TOSCA Template Requirements for
12 OpenO, which provides recommendations and standards for building VNF
13 TOSCA templates compatible with OpenO– initial implementations of
14 Network Cloud. It has the following features:
16 1. VNF TOSCA template designer supports GUI and CLI.
18 2. VNF TOSCA template is aligned to the newest TOSCA protocol, “Working
19 Draft 04-Revision 06”.
21 3. VNF TOSCA template supports EPA features, such as NUMA, Hyper
22 Threading, SRIOV， etc.
27 This document is intended for persons developing VNF TOSCA templates
28 that will be orchestrated by OpenO.
33 OpenO implementations of Network Cloud supports TOSCA Templates, also
34 referred to as TOSCA in this document.
36 OpenO requires the TOSCA Templates to follow a specific format. This
37 document provides the mandatory, recommended, and optional requirements
38 associated with this format.
43 The document includes three charters to help the VNF vendors to use the
44 VNF model design tools and understand the VNF package structure and VNF
47 In the OPENO, VNF Package and VNFD template can be designed by manually
48 or via model designer tools. VNF model designer tools can provide the
49 GUI and CLI tools for the VNF vendor to develop the VNF Package and VNFD
52 The VNF package structure is align to the NFV TOSCA protocol, and
55 The VNFD and VNF package are all align to the NFV TOSCA protocol, which
56 supports multiple TOSCA template yaml files, and also supports
57 self-defined node or other extensions.
62 TOSCA templates supported by OPENO must follow the requirements
63 enumerated in this section.
68 TOSCA defines a Meta model for defining IT services. This Meta model
69 defines both the structure of a service as well as how to manage it. A
70 Topology Template (also referred to as the topology model of a service)
71 defines the structure of a service. Plans define the process models that
72 are used to create and terminate a service as well as to manage a
73 service during its whole lifetime.
75 A Topology Template consists of a set of Node Templates and Relationship
76 Templates that together define the topology model of a service as a (not
77 necessarily connected) directed graph. A node in this graph is
78 represented by a *Node Template*. A Node Template specifies the
79 occurrence of a Node Type as a component of a service. A *Node Type*
80 defines the properties of such a component (via *Node Type Properties*)
81 and the operations (via *Interfaces*) available to manipulate the
82 component. Node Types are defined separately for reuse purposes and a
83 Node Template references a Node Type and adds usage constraints, such as
84 how many times the component can occur.
87 Figure 1: Structural Elements of Service Template and their Relations
89 TOSCA Modeling Principles & Data Model
90 --------------------------------------
92 This section describing TOSCA modeling principles and data model for
93 NFV, which shall be based on [TOSCA-1.0] and [TOSCA-Simple-Profile-YAML
94 V1.0], or new type based on ETSI NFV requirements, etc.
96 VNF Descriptor Template
97 -----------------------
99 The VNF Descriptor (VNFD) describes the topology of the VNF by means of
100 ETSI NFV IFA011 [IFA011] terms such as VDUs, Connection Points, Virtual
101 Links, External Connection Points, Scaling Aspects, Instantiation Levels
102 and Deployment Flavours.
104 The VNFD (VNF Descriptor) is read by both the NFVO and the VNFM. It
105 represents the contract & interface of a VNF and ensures the
106 interoperability across the NFV functional blocks.
108 The main parts of the VNFD are the following:
110 - VNF topology: it is modeled in a cloud agnostic way using virtualized
111 containers and their connectivity. Virtual Deployment Units (VDU)
112 describe the capabilities of the virtualized containers, such as
113 virtual CPU, RAM, disks; their connectivity is modeled with VDU
114 Connection Point Descriptors (VduCpd), Virtual Link Descriptors (Vld)
115 and VNF External Connection Point Descriptors (VnfExternalCpd);
117 - VNF deployment aspects: they are described in one or more deployment
118 flavours, including instantiation levels, supported LCM operations,
119 VNF LCM operation configuration parameters, placement constraints
120 (affinity / antiaffinity), minimum and maximum VDU instance numbers,
121 and scaling aspect for horizontal scaling.
123 The following table defines the TOSCA Type “derived from” values that
124 SHALL be used when using the TOSCA Simple Profile for NFV version 1.0
125 specification [TOSCA-Simple-Profile-NFV-v1.0] for NFV VNFD.
127 +-----------------------------------------+---------------------------------------+-----------------------+
128 | **ETSI NFV Element** | **TOSCA VNFD** | **Derived from** |
130 | **[IFA011]** | **[TOSCA-Simple-Profile-NFV-v1.0]** | |
131 +=========================================+=======================================+=======================+
132 | VNF | tosca.nodes.nfv.VNF | tosca.nodes.Root |
133 +-----------------------------------------+---------------------------------------+-----------------------+
134 | VDU | tosca.nodes.nfv.VDU | tosca.nodes.Root |
135 +-----------------------------------------+---------------------------------------+-----------------------+
136 | Cpd (Connection Point) | tosca.nodes.nfv.Cpd | tosca.nodes.Root |
137 +-----------------------------------------+---------------------------------------+-----------------------+
138 | VduCpd (internal connection point) | tosca.nodes.nfv.VduCpd | tosca.nodes.nfv.Cpd |
139 +-----------------------------------------+---------------------------------------+-----------------------+
140 | VnfVirtualLinkDesc (Virtual Link) | tosca.nodes.nfv.VnfVirtualLinkDesc | tosca.nodes.Root |
141 +-----------------------------------------+---------------------------------------+-----------------------+
142 | VnfExtCpd (External Connection Point) | tosca.nodes.nfv.VnfExtCpd | tosca.nodes.Root |
143 +-----------------------------------------+---------------------------------------+-----------------------+
144 | Virtual Storage | | |
145 +-----------------------------------------+---------------------------------------+-----------------------+
146 | Virtual Compute | | |
147 +-----------------------------------------+---------------------------------------+-----------------------+
148 | Software Image | | |
149 +-----------------------------------------+---------------------------------------+-----------------------+
150 | Deployment Flavour | | |
151 +-----------------------------------------+---------------------------------------+-----------------------+
152 | Scaling Aspect | | |
153 +-----------------------------------------+---------------------------------------+-----------------------+
154 | Element Group | | |
155 +-----------------------------------------+---------------------------------------+-----------------------+
156 | Instantiation Level | | |
157 +-----------------------------------------+---------------------------------------+-----------------------+
159 +--------------------------------------------------------------------+
160 | +--------------------------------------------------------------+ |
161 | | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 | |
163 | | description: VNFD TOSCA file demo | |
167 | | - TOSCA\_definition\_nfv\_1\_0.yaml | |
169 | | - TOSCA\_definition\_nfv\_ext\_1\_0.yaml | |
171 | | | **node\_types: | |
172 | | tosca.nodes.nfv.VNF.vOpenNAT: | |
173 | | derived\_from:** tosca.nodes.nfv.VNF | |
174 | | | **requirements: | |
175 | | **- **sriov\_plane: | |
176 | | capability:** tosca.capabilities.nfv.VirtualLinkable | |
177 | | | **node:** tosca.nodes.nfv.VnfVirtualLinkDesc | |
178 | | | **relationship:** tosca.relationships.nfv.VirtualLinksTo | |
179 | +--------------------------------------------------------------+ |
180 +====================================================================+
181 +--------------------------------------------------------------------+
186 1. SR-IOV Passthrought
188 Definitions of SRIOV\_Port are necessary if VDU supports SR-IOV. Here is
191 +------------------------------------------------+
200 | tosca\_name: SRIOV\_Port |
204 | virtual\_network\_interface\_requirements: |
208 | support\_mandatory: false |
210 | description: sriov |
218 | description: sriov port |
220 | layer\_protocol: ipv4 |
224 | - virtual\_binding: |
226 | capability: virtual\_binding |
232 | type: tosca.relationships.nfv.VirtualBindsTo |
236 | node: tosca.nodes.Root |
238 | type: tosca.nodes.nfv.VduCpd |
240 | substitution\_mappings: |
250 | node\_type: tosca.nodes.nfv.VNF.vOpenNAT |
251 +------------------------------------------------+
255 Definitions of mem\_page\_size as one property shall be added to
256 Properties and set the value to large if one VDU node supports
257 huagepages. Here is an example.
259 +----------------------------------+
268 | tosca\_name: Huge\_pages\_demo |
272 | mem\_page\_size:large |
273 +==================================+
274 +----------------------------------+
278 Likewise, we shall add definitions of numa to
279 requested\_additional\_capabilities if we wand VUD nodes to support
280 NUMA. Here is an example.
282 +-------------------------------------------------+
283 | topology\_template: |
291 | virtual\_compute: |
297 | numa\_enabled: true |
299 | virtual\_mem\_size: 2 GB |
301 | requested\_additional\_capabilities: |
305 | support\_mandatory: true |
307 | requested\_additional\_capability\_name: numa |
309 | target\_performance\_parameters: |
311 | hw:numa\_nodes: "2" |
313 | hw:numa\_cpus.0: "0,1" |
315 | hw:numa\_mem.0: "1024" |
317 | hw:numa\_cpus.1: "2,3,4,5" |
319 | hw:numa\_mem.1: "1024" |
320 +-------------------------------------------------+
324 Definitions of Hyper-Theading are necessary as one of
325 requested\_additional\_capabilities of one VUD node if that node
326 supports Hyper-Theading. Here is an example.
328 +-------------------------------------------------------------+
329 | topology\_template: |
337 | virtual\_compute: |
343 | numa\_enabled: true |
345 | virtual\_mem\_size: 2 GB |
347 | requested\_additional\_capabilities: |
349 | hyper\_threading: |
351 | support\_mandatory: true |
353 | requested\_additional\_capability\_name: hyper\_threading |
355 | target\_performance\_parameters: |
357 | hw:cpu\_sockets : "2" |
359 | hw:cpu\_threads : "2" |
361 | hw:cpu\_cores : "2" |
363 | hw:cpu\_threads\_policy: "isolate" |
364 +-------------------------------------------------------------+
368 Definitions of ovs\_dpdk are necessary as one of
369 requested\_additional\_capabilities of one VUD node if that node
370 supports dpdk. Here is an example.
372 +------------------------------------------------------+
373 | topology\_template: |
381 | virtual\_compute: |
387 | numa\_enabled: true |
389 | virtual\_mem\_size: 2 GB |
391 | requested\_additional\_capabilities: |
395 | support\_mandatory: true |
397 | requested\_additional\_capability\_name: ovs\_dpdk |
399 | target\_performance\_parameters: |
401 | sw:ovs\_dpdk: "true" |
402 +------------------------------------------------------+
404 NFV TOSCA Type Definition
405 -------------------------
407 tosca.capabilites.nfv.VirtualCompute
408 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
410 +---------------------------+-----------------------------------------+
411 | **Shorthand Name** | VirtualCompute |
412 +===========================+=========================================+
413 | **Type Qualified Name** | tosca: VirtualCompute |
414 +---------------------------+-----------------------------------------+
415 | **Type URI** | tosca.capabilities.nfv.VirtualCompute |
416 +---------------------------+-----------------------------------------+
417 | **derived from** | tosca.nodes.Root |
418 +---------------------------+-----------------------------------------+
423 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
424 | Name | Required | Type | Constraints | Description |
425 +=====================================+============+=====================================================+===============+=========================================================+
426 | request\_additional\_capabilities | No | tosca.datatypes.nfv.RequestedAdditionalCapability | | Describes additional capability for a particular VDU. |
427 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
428 | virtual\_memory | yes | tosca.datatypes.nfv.VirtualMemory | | Describes virtual memory of the virtualized compute |
429 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
430 | virtual\_cpu | yes | tosca.datatypes.nfv.VirtualCpu | | Describes virtual CPU(s) of the virtualized compute. |
431 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
432 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
434 +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+
439 +-----------------------------------------------------------+
440 | tosca.capabilities.nfv.VirtualCompute: |
442 | derived\_from: tosca.capabilities.Root |
446 | requested\_additional\_capabilities: |
452 | type: tosca.datatypes.nfv.RequestedAdditionalCapability |
458 | type: tosca.datatypes.nfv.VirtualMemory |
464 | type: tosca.datatypes.nfv.VirtualCpu |
467 +-----------------------------------------------------------+
469 tosca.nodes.nfv.VDU.Compute
470 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
472 The NFV Virtualization Deployment Unit (VDU) compute node type
473 represents a VDU entity which it describes the deployment and
474 operational behavior of a VNF component (VNFC), as defined by **[ETSI
477 +-----------------------+-------------------------------+
478 | Shorthand Name | VDU.Compute |
479 +=======================+===============================+
480 | Type Qualified Name | tosca:VDU.Compute |
481 +-----------------------+-------------------------------+
482 | Type URI | tosca.nodes.nfv.VDU.Compute |
483 +-----------------------+-------------------------------+
484 | derived\_from | tosca.nodes.Compute |
485 +-----------------------+-------------------------------+
498 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
499 | Name | Type | Constraints | Description |
500 +=========================+=================================================+===============+=====================================================================================================+
501 | virtual\_compute | tosca.capabilities.nfv.VirtualCompute | | Describes virtual compute resources capabilities. |
502 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
503 | monitoring\_parameter | tosca.capabilities.nfv.Metric | None | Monitoring parameter, which can be tracked for a VNFC based on this VDU |
505 | | | | Examples include: memory-consumption, CPU-utilisation, bandwidth-consumption, VNFC downtime, etc. |
506 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
507 | Virtual\_binding | tosca.capabilities.nfv.VirtualBindable | | Defines ability of VirtualBindable |
509 | | editor note: need to create a capability type | | |
510 +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+
515 +-----------------------------------------------------------------------------------------------------+
516 | tosca.nodes.nfv.VDU.Compute: |
518 | derived\_from: tosca.nodes.Compute |
536 | type: list # explicit index (boot index) not necessary, contrary to IFA011 |
544 | nfvi\_constraints: |
554 | configurable\_properties: |
560 | type: tosca.datatypes.nfv.VnfcConfigurableProperties |
566 | private\_address: |
568 | status: deprecated |
572 | status: deprecated |
576 | status: deprecated |
580 | status: deprecated |
584 | virtual\_compute: |
586 | type: tosca.capabilities.nfv.VirtualCompute |
588 | virtual\_binding: |
590 | type: tosca.capabilities.nfv.VirtualBindable |
592 | #monitoring\_parameter: |
594 | # modeled as ad hoc (named) capabilities in VDU node template |
600 | # cpu\_load: tosca.capabilities.nfv.Metric |
602 | # memory\_usage: tosca.capabilities.nfv.Metric |
604 | host: #Editor note: FFS. How this capabilities should be used in NFV Profile |
606 | type: `*tosca.capabilities.Container* <#DEFN_TYPE_CAPABILITIES_CONTAINER>`__ |
608 | valid\_source\_types: [`*tosca.nodes.SoftwareComponent* <#DEFN_TYPE_NODES_SOFTWARE_COMPONENT>`__] |
610 | occurrences: [0,UNBOUNDED] |
614 | occurrences: [0,0] |
618 | occurrences: [0,0] |
620 | scalable: #Editor note: FFS. How this capabilities should be used in NFV Profile |
622 | type: `*tosca.capabilities.Scalable* <#DEFN_TYPE_CAPABILITIES_SCALABLE>`__ |
626 | occurrences: [0,UNBOUND] |
630 | - virtual\_storage: |
632 | capability: tosca.capabilities.nfv.VirtualStorage |
634 | relationship: tosca.relationships.nfv.VDU.AttachedTo |
636 | node: tosca.nodes.nfv.VDU.VirtualStorage |
638 | occurences: [ 0, UNBOUNDED ] |
640 | - local\_storage: #For NFV Profile, this requirement is deprecated. |
642 | occurrences: [0,0] |
650 | type: tosca.artifacts.nfv.SwImage |
651 +-----------------------------------------------------------------------------------------------------+
655 +-----------+------------+-------------------------------+---------------+------------------------------------------------+
656 | Name | Required | Type | Constraints | Description |
657 +===========+============+===============================+===============+================================================+
658 | SwImage | Yes | tosca.artifacts.nfv.SwImage | | Describes the software image which is |
659 | | | | | directly realizing this virtual storage |
660 +-----------+------------+-------------------------------+---------------+------------------------------------------------+
670 The TOSCA Cpd node represents network connectivity to a compute resource
671 or a VL as defined by [ETSI GS NFV-IFA 011]. This is an abstract type
672 used as parent for the various Cpd types.
674 +-----------------------+-----------------------+
675 | Shorthand Name | Cpd |
676 +=======================+=======================+
677 | Type Qualified Name | tosca:Cpd |
678 +-----------------------+-----------------------+
679 | Type URI | tosca.nodes.nfv.Cpd |
680 +-----------------------+-----------------------+
686 +--------+------------+--------+---------------+---------------+
687 | Name | Required | Type | Constraints | Description |
688 +========+============+========+===============+===============+
689 +--------+------------+--------+---------------+---------------+
704 +----------------------------------------------------------------------+
705 | tosca.nodes.nfv.Cpd: |
707 | derived\_from: tosca.nodes.Root |
717 | - valid\_values: [ethernet, mpls, odu2, ipv4, ipv6, pseudo\_wire ] |
721 | role: #Name in ETSI NFV IFA011 v0.7.3 cpRole |
727 | - valid\_values: [ root, leaf ] |
743 | type: tosca.datatype.nfv.AddressData |
746 +----------------------------------------------------------------------+
748 Additional Requirement
749 ^^^^^^^^^^^^^^^^^^^^^^
753 tosca.nodes.nfv.VduCpd
754 ~~~~~~~~~~~~~~~~~~~~~~
756 The TOSCA node VduCpd represents a type of TOSCA Cpd node and describes
757 network connectivity between a VNFC instance (based on this VDU) and an
758 internal VL as defined by [ETSI GS NFV-IFA 011].
760 +-----------------------+--------------------------+
761 | Shorthand Name | VduCpd |
762 +=======================+==========================+
763 | Type Qualified Name | tosca: VduCpd |
764 +-----------------------+--------------------------+
765 | Type URI | tosca.nodes.nfv.VduCpd |
766 +-----------------------+--------------------------+
772 +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
773 | Name | Required | Type | Constraints | Description |
774 +===============================+============+==========================================+==========================================================================+
775 | bitrate_requirement | no | integer | | Bitrate requirement on this connection point. |
776 +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
777 | virtual\_network\_interface_\ | no | VirtualNetworkInterfaceRequirements | | Specifies requirements on a virtual network |
778 | requirements | | | | realising the CPs instantiated from this CPD |
779 +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
789 +--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
790 | Name | Required | Type | Constraints | Description |
791 +====================+============+==========================================+===============+==========================================================+
792 | virtual\_binding | yes | tosca.capabilities.nfv.VirtualBindable | | Describe the requirement for binding with VDU |
793 +--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
794 | virtual\_link | no | tosca.capabilities.nfv.VirtualLinkable | | Describes the requirements for linking to virtual link |
795 +--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
800 +----------------------------------------------------------------+
801 | tosca.nodes.nfv.VduCpd: |
803 | derived\_from: tosca.nodes.nfv.Cpd |
807 | bitrate\_requirement: |
813 | virtual\_network\_interface\_requirements |
819 | type: VirtualNetworkInterfaceRequirements |
827 | capability: tosca.capabilities.nfv.VirtualLinkable |
829 | relationship: tosca.relationships.nfv.VirtualLinksTo |
831 | node: tosca.nodes.nfv.VnfVirtualLinkDesc - virtual\_binding: |
833 | capability: tosca.capabilities.nfv.VirtualBindable |
835 | relationship: tosca.relationships.nfv.VirtualBindsTo |
837 | node: tosca.nodes.nfv.VDU |
838 +----------------------------------------------------------------+
840 tosca.nodes.nfv.VDU.VirtualStorage
841 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
843 The NFV VirtualStorage node type represents a virtual storage entity
844 which it describes the deployment and operational behavior of a virtual
845 storage resources, as defined by **[ETSI NFV IFA011].**
847 **[editor note]** open issue: should NFV profile use the current storage
848 model as described in YAML 1.1. Pending on Shitao proposal (see
849 NFVIFA(17)000110 discussion paper)
851 **[editor note]** new relationship type as suggested in Matt
852 presentation. Slide 8. With specific rules of “valid\_target\_type”
854 +---------------------------+--------------------------------------+
855 | **Shorthand Name** | VirtualStorage |
856 +===========================+======================================+
857 | **Type Qualified Name** | tosca: VirtualStorage |
858 +---------------------------+--------------------------------------+
859 | **Type URI** | tosca.nodes.nfv.VDU.VirtualStorage |
860 +---------------------------+--------------------------------------+
861 | **derived\_from** | tosca.nodes.Root |
862 +---------------------------+--------------------------------------+
864 tosca.artifacts.nfv.SwImage
865 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
867 +---------------------------+------------------------------------+
868 | **Shorthand Name** | SwImage |
869 +===========================+====================================+
870 | **Type Qualified Name** | tosca:SwImage |
871 +---------------------------+------------------------------------+
872 | **Type URI** | tosca.artifacts.nfv.SwImage |
873 +---------------------------+------------------------------------+
874 | **derived\_from** | tosca.artifacts.Deployment.Image |
875 +---------------------------+------------------------------------+
880 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
881 | Name | Required | Type | Constraints | Description |
882 +==========================================+============+====================+===============+====================================================================================================+
883 | name | yes | string | | Name of this software image |
884 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
885 | version | yes | string | | Version of this software image |
886 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
887 | checksum | yes | string | | Checksum of the software image file |
888 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
889 | container\_format | yes | string | | The container format describes the container file format in which software image is provided. |
890 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
891 | disk\_format | yes | string | | The disk format of a software image is the format of the underlying disk image |
892 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
893 | min\_disk | yes | scalar-unit.size | | The minimal disk size requirement for this software image. |
894 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
895 | min\_ram | no | scalar-unit.size | | The minimal RAM requirement for this software image. |
896 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
897 | Size | yes | scalar-unit.size | | The size of this software image |
898 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
899 | sw\_image | yes | string | | A reference to the actual software image within VNF Package, or url. |
900 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
901 | operating\_system | no | string | | Identifies the operating system used in the software image. |
902 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
903 | supported \_virtualization\_enviroment | no | list | | Identifies the virtualization environments (e.g. hypervisor) compatible with this software image |
904 +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+
909 +-----------------------------------------------------+
910 | tosca.artifacts.nfv.SwImage: |
912 | derived\_from: tosca.artifacts.Deployment.Image |
914 | properties or metadata: |
938 | container\_format: |
952 | type: scalar-unit.size # Number |
958 | type: scalar-unit.size # Number |
964 | type: scalar-unit.size # Number |
974 | operating\_system: |
980 | supported\_virtualisation\_environments: |
989 +-----------------------------------------------------+
994 openovnf\_\_vOpenNAT.yaml
995 ~~~~~~~~~~~~~~~~~~~~~~~~~
997 +-------------------------------------------------------------+
1000 | - openonfv\_\_tosca.capabilities.Scalable.yaml |
1002 | - openonfv\_\_tosca.capabilities.nfv.Metric.yaml |
1004 | - openonfv\_\_tosca.capabilities.network.Bindable.yaml |
1006 | - openonfv\_\_tosca.capabilities.Attachment.yaml |
1008 | - openonfv\_\_tosca.capabilities.nfv.VirtualBindable.yaml |
1010 | - openonfv\_\_tosca.requirements.nfv.VirtualStorage.yaml |
1012 | - openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml |
1014 | - openonfv\_\_tosca.relationships.nfv.VirtualBindsTo.yaml |
1016 | - openonfv\_\_tosca.nodes.nfv.VDU.Compute.yaml |
1018 | - openonfv\_\_tosca.artifacts.nfv.SwImage.yaml |
1020 | - openonfv\_\_tosca.capabilities.nfv.VirtualCompute.yaml |
1022 | - openonfv\_\_tosca.capabilities.Container.yaml |
1024 | - openonfv\_\_tosca.capabilities.nfv.VirtualStorage.yaml |
1026 | - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
1028 | - openovnf\_\_tosca.nodes.nfv.VNF.vOpenNAT.yaml |
1030 | - openonfv\_\_tosca.capabilities.Endpoint.Admin.yaml |
1032 | - openonfv\_\_tosca.capabilities.OperatingSystem.yaml |
1034 | - openonfv\_\_tosca.nodes.nfv.VduCpd.yaml |
1036 | - openonfv\_\_tosca.relationships.nfv.VDU.AttachedTo.yaml |
1040 | vnfProductName: openNAT |
1042 | vnfdVersion: 1.0.0 |
1044 | vnfProvider: intel |
1048 | csarVersion: 1.0.0 |
1050 | vnfdId: openNAT-1.0 |
1052 | csarProvider: intel |
1054 | vnfProductInfoDescription: openNAT |
1062 | localizationLanguage: '[english, chinese]' |
1066 | defaultLocalizationLanguage: english |
1068 | vnfProductInfoName: openNAT |
1070 | vnfSoftwareVersion: 1.0.0 |
1072 | topology\_template: |
1074 | node\_templates: |
1082 | file: /swimages/xenial-snat.qcow2 |
1084 | type: tosca.artifacts.nfv.SwImage |
1088 | name: vNatVNFImage |
1092 | checksum: "5000" |
1094 | container\_format: bare |
1096 | disk\_format: qcow2 |
1098 | min\_disk: 10 GB |
1104 | sw\_image: /swimages/xenial-snat.qcow2 |
1106 | operating\_system: unbantu |
1110 | tosca\_name: vdu\_vNat |
1114 | virtual\_compute: |
1118 | virtual\_memory: |
1120 | numa\_enabled: true |
1122 | virtual\_mem\_size: 2 GB |
1124 | requested\_additional\_capabilities: |
1128 | support\_mandatory: true |
1130 | requested\_additional\_capability\_name: numa |
1132 | target\_performance\_parameters: |
1134 | hw:numa\_nodes: "2" |
1136 | hw:numa\_cpus.0: "0,1" |
1138 | hw:numa\_mem.0: "1024" |
1140 | hw:numa\_cpus.1: "2,3,4,5" |
1142 | hw:numa\_mem.1: "1024" |
1144 | hyper\_threading: |
1146 | support\_mandatory: true |
1148 | requested\_additional\_capability\_name: hyper\_threading |
1150 | target\_performance\_parameters: |
1152 | hw:cpu\_sockets : "2" |
1154 | hw:cpu\_threads : "2" |
1156 | hw:cpu\_cores : "2" |
1158 | hw:cpu\_threads\_policy: "isolate" |
1162 | support\_mandatory: true |
1164 | requested\_additional\_capability\_name: ovs\_dpdk |
1166 | target\_performance\_parameters: |
1168 | sw:ovs\_dpdk: "true" |
1172 | cpu\_architecture: X86 |
1174 | num\_virtual\_cpu: 2 |
1178 | configurable\_properties: |
1182 | additional\_vnfc\_configurable\_properties: |
1188 | descrption: the virtual machine of vNat |
1196 | - virtual\_storage: |
1198 | capability: virtual\_storage |
1200 | node: vNAT\_Storage |
1206 | location: /mnt/volume\_0 |
1208 | type: tosca.relationships.nfv.VDU.AttachedTo |
1210 | - local\_storage: |
1212 | node: tosca.nodes.Root |
1214 | type: tosca.nodes.nfv.VDU.Compute |
1220 | tosca\_name: SRIOV\_Port |
1224 | virtual\_network\_interface\_requirements: |
1228 | support\_mandatory: false |
1230 | description: sriov |
1238 | description: sriov port |
1240 | layer\_protocol: ipv4 |
1244 | - virtual\_binding: |
1246 | capability: virtual\_binding |
1252 | type: tosca.relationships.nfv.VirtualBindsTo |
1254 | - virtual\_link: |
1256 | node: tosca.nodes.Root |
1258 | type: tosca.nodes.nfv.VduCpd |
1264 | tosca\_name: vNAT\_Storage |
1268 | id: vNAT\_Storage |
1270 | size\_of\_storage: 10 GB |
1272 | rdma\_enabled: false |
1274 | type\_of\_storage: volume |
1276 | type: tosca.nodes.nfv.VDU.VirtualStorage |
1278 | substitution\_mappings: |
1288 | node\_type: tosca.nodes.nfv.VNF.vOpenNAT |
1290 | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
1291 +-------------------------------------------------------------+
1293 openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml
1294 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1296 +------------------------------------------------------------+
1299 | - openonfv\_\_tosca.capabilities.nfv.VirtualStorage.yaml |
1303 | tosca.nodes.nfv.VDU.VirtualStorage: |
1307 | virtual\_storage: |
1309 | type: tosca.capabilities.nfv.VirtualStorage |
1311 | derived\_from: tosca.nodes.Root |
1319 | size\_of\_storage: |
1329 | type\_of\_storage: |
1333 | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
1334 +------------------------------------------------------------+
1336 openonfv\_\_tosca.nodes.nfv.VduCpd.yaml
1337 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1339 +-----------------------------------------------------------------+
1342 | tosca.datatypes.nfv.L3AddressData: |
1346 | number\_of\_ip\_address: |
1352 | ip\_address\_assignment: |
1356 | ip\_address\_type: |
1360 | - valid\_values: |
1370 | floating\_ip\_activated: |
1374 | tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements: |
1384 | support\_mandatory: |
1402 | tosca.datatype.nfv.AddressData: |
1410 | - valid\_values: |
1418 | l2\_address\_data: |
1422 | type: tosca.datatypes.nfv.L2AddressData |
1424 | l3\_address\_data: |
1428 | type: tosca.datatypes.nfv.L3AddressData |
1430 | tosca.datatypes.nfv.L2AddressData: {} |
1434 | - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
1436 | - openonfv\_\_tosca.requirements.nfv.VirtualBinding.yaml |
1440 | tosca.nodes.nfv.VduCpd: |
1442 | derived\_from: tosca.nodes.Root |
1446 | virtual\_network\_interface\_requirements: |
1450 | type: tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements |
1460 | - valid\_values: |
1470 | bitrate\_requirement: |
1482 | layer\_protocol: |
1486 | - valid\_values: |
1506 | type: tosca.datatype.nfv.AddressData |
1514 | - virtual\_binding: |
1516 | capability: tosca.capabilities.nfv.VirtualBindable |
1524 | - virtual\_link: |
1526 | capability: tosca.capabilities.nfv.VirtualBindable |
1534 | tosca\_definitions\_version: tosca\_simple\_yaml\_1\_0 |
1535 +-----------------------------------------------------------------+
1537 .. |image1| image:: Image1.png
1540 .. |image2| image:: Image2.png
1551 The Heat templates supported by ONAP must follow the requirements
1552 enumerated in this section.
1557 In order to enable ONAP to understand the relationship between Heat
1558 files, the following Heat file naming convention must be followed.
1560 - The file name for the base module Heat template must include “base”
1563 - Examples: *base\_xyz.yml* or *base\_xyz.yaml*; *xyz\_base.yml* or
1566 - There is no explicit naming convention for the add-on modules.
1568 - Examples: *module1.yml* or *module1.yaml*
1570 - All Cinder volume templates must be named the same as the
1571 corresponding Heat template with “\_volume” appended to the file
1574 - Examples: *base\_xyz\_volume.yml* or *base\_xyz\_volume.yaml*;
1575 *xyz\_base\_volume.yml* or *xyz\_base\_volume.yaml*;
1576 *module1\_volume.yml* or *module1\_volume.yaml* (referencing the
1577 above base module Heat template name)
1579 - The file name of the environment files must fully match the
1580 corresponding Heat template filename and have *.env* or *.ENV*
1583 - Examples: *base\_xyz.env* or *base\_xyz.ENV*; *xyz\_base.env* or
1584 *xyz\_base.ENV*; *base\_xyz\_volume.env* or
1585 *base\_xyz\_volume.ENV*; *module1.env* or *module1.ENV;
1586 module1\_volume.env* or *module1\_volume.ENV* (referencing the
1587 above base module Heat template name)
1589 - A YAML file must have a corresponding ENV file, even if the ENV file
1590 enumerates no parameters. It is an ONAP requirement.
1595 A Heat template (a YAML file and its corresponding environment file)
1596 must be formatted in valid YAML. For a description of YAML, refer to the
1597 following OpenStack wiki.
1599 https://wiki.openstack.org/wiki/Heat/YAMLTemplates
1601 A Heat template must follow a specific format. The OpenStack Heat
1602 Orchestration Template (HOT) specification explains in detail all
1603 elements of the HOT template format.
1605 http://docs.openstack.org/developer/heat/template_guide/hot_spec.html
1607 Parameter Categories & Specification
1608 ------------------------------------
1610 Parameter Categories
1611 ~~~~~~~~~~~~~~~~~~~~
1613 ONAP requires the Heat template parameters to follow certain
1614 requirements in order for it to be orchestrated or deployed. ONAP
1615 classifies parameters into eight broad categories.
1617 - **ONAP Metadata**: ONAP mandatory and optional metadata
1618 parameters in the resource *OS::Nova::Server*.
1620 - ONAP dictates the naming convention of these Metadata
1621 parameters and must be adhered to (See Section 5.b, Independent Volume Templates).
1623 - Metadata parameters must not be enumerated in the environment
1626 - The ONAP Metadata are generated and/or assigned by ONAP
1627 and supplied to the Heat by ONAP at orchestration time.
1629 - **ONAP Orchestration Parameters**: The data associated with
1630 these parameters are VNF instance specific.
1632 - ONAP enforces the naming convention of these parameters and
1633 must be adhered to (See Parameter Naming Convention).
1635 - These parameters must not be enumerated in the environment file.
1637 - The ONAP Orchestration Parameters are generated and/or
1638 assigned by ONAP and supplied to the Heat by ONAP at
1641 - **VNF Orchestration Parameters**: The data associated with these
1642 parameters are VNF instance specific.
1644 - While ONAP does not enforce a naming convention, the
1645 parameter names should include {vm-type} and {network-role} when
1646 appropriate. (See Parameter Naming Convention)
1648 - These parameters must not be enumerated in the environment file.
1650 - The VNF Orchestration Parameters Heat are generated and/or
1651 assigned by ONAP and supplied to the Heat by ONAP at
1654 - **ONAP Orchestration Constants**: The data associated with these
1655 parameters must be constant across all VNF instances.
1657 - ONAP enforces the naming convention of these parameters and
1658 must be adhered to (See Parameter Naming Convention).
1660 - These parameters must be enumerated in the environment file.
1662 - **VNF Orchestration Constants**: The data associated with these
1663 parameters must be constant across all VNF instances.
1665 - While ONAP does not enforce a naming convention, the
1666 parameter names should include {vm-type} and {network-role} when
1667 appropriate. (See Parameter Naming Convention)
1669 - These parameters must be enumerated in the environment file.
1671 - **ONAP Base Template Output Parameters** (also referred to as
1672 Base Template Output Parameters): The output section of the base
1673 template allows for specifying output parameters available to add-on
1674 modules once the base template has been instantiated. The parameter
1675 defined in the output section of the base must be identical to the
1676 parameter defined in the add-on module(s) where the parameter is
1679 - **ONAP Volume Template Output Parameters** (also referred to as
1680 Volume Template Output Parameters): The output section of the volume
1681 template allows for specifying output parameters available to the
1682 corresponding Heat template (base or add-on) once the volume template
1683 has been instantiated. The parameter defined in the output section of
1684 the volume must be identical to the parameter defined in the base or
1687 - **ONAP Predefined Output Parameters** (also referred to as
1688 Predefined Output Parameters): ONAP will look for a small set of
1689 pre-defined Heat output parameters to capture resource attributes for
1690 inventory in ONAP. These parameters are specified in Section
1691 5.b Resource Property: name.
1693 The table below summarizes the Parameter Types. If the user is
1694 orchestrating a manual spin up of Heat (e.g. OpenStack command line),
1695 the parameter values that ONAP supplies must be enumerated in the
1696 environment file. However, when the Heat is to be loaded into ONAP
1697 for orchestration, the parameters that ONAP supplies must be
1698 deleted or marked with a comment (i.e., a “#” placed at the beginning of
1701 +-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
1702 | Parameter Type | Naming Convention | Parameter Value Source |
1703 +===============================================+=====================+=================================================================================+
1704 | ONAP Metadata | Explicit | ONAP |
1705 +-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
1706 | ONAP Orchestration Parameters | Explicit | ONAP |
1707 +-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
1708 | VNF Orchestration Parameters | Recommended | ONAP |
1709 +-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
1710 | ONAP Orchestration Constants | Explicit | Environment File |
1711 +-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
1712 | VNF Orchestration Constants | Recommended | Environment File |
1713 +-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
1714 | ONAP Base Template Output Parameters | Recommended | Heat Output Statement for base, ONAP supplied to add-on modules |
1715 +-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
1716 | ONAP Volume Template Output Parameters | Recommended | Heat Output Statement for volume, OpeneECOMP supplies to corresponding module |
1717 +-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
1718 | ONAP Predefined Output Parameters | Explicit | Heat Output Statement |
1719 +-----------------------------------------------+---------------------+---------------------------------------------------------------------------------+
1721 Table 1 Parameter Types
1723 Parameter Specifications
1724 ~~~~~~~~~~~~~~~~~~~~~~~~
1726 ONAP METADATA Parameters
1727 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1729 ONAP defines four “metadata” parameters: vnf\_id, vf\_module\_id,
1730 vnf\_name, vf\_module\_name. These parameters must not define any
1731 constraints in the Heat template, including length restrictions, ranges,
1732 default value and/or allowed patterns.
1734 ONAP Base Template & Volume Template Output Parameters
1735 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1737 The base template and volume template output parameters are defined as
1738 input parameters in subsequent modules. When defined as input
1739 parameters, these parameters must not define any constraints in the Heat
1740 template, including length restrictions, ranges, default value and/or
1741 allowed patterns. The parameter name defined in the output statement of
1742 the Heat must be identical to the parameter name defined in the Heat
1743 that is to receive the value.
1745 ONAP Predefined Output Parameters
1746 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1748 These parameters must not define any constraints in the Heat template,
1749 including length restrictions, ranges, default value and/or allowed
1752 ONAP Orchestration Parameters, VNF Orchestration Parameters, ONAP Orchestration Constants, VNF Orchestration Constants
1753 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1755 ONAP Orchestration Parameters, VNF Orchestration Parameters,
1756 ONAP Orchestration Constants, VNF Orchestration Constants must
1757 adhere to the following:
1759 - All parameters should be clearly documented in the template,
1760 including expected values.
1762 - All parameters should be clearly specified, including constraints and
1765 - Numeric parameter constraints should include range and/or allowed
1768 - When the parameter type is a string and the parameter name contains
1769 an index, the index must be zero based. That is, the index starts at
1772 - When the parameter type is a Comma Delimited List (CDL), the
1773 reference index must start at zero.
1775 - Default values must only be supplied in a Heat environment file to
1776 keep the template itself as clean as possible.
1778 - Special characters must not be used in parameter names, as currently
1779 only alphanumeric characters and “\_” underscores are allowed.
1781 Use of Heat Environments
1782 ------------------------
1784 A YAML file must have a corresponding environment file (also referred to
1785 as ENV file), even if the environment file defines no parameters. It is
1786 an ONAP requirement.
1788 The environment file must contain parameter values for the ONAP
1789 Orchestration Constants and VNF Orchestration Constants. These
1790 parameters are identical across all instances of a VNF type, and
1791 expected to change infrequently. The ONAP Orchestration Constants
1792 are associated with OS::Nova::Server image and flavor properties (See
1793 Section 5.b Resource: OS::Nova::Server – Parameters). Examples of VNF Orchestration Constants are the networking
1794 parameters associated with an internal network (e.g. private IP ranges)
1795 and Cinder volume sizes.
1797 The environment file must not contain parameter values for parameters
1798 that are instance specific (ONAP Orchestration Parameters, VNF
1799 Orchestration Parameters). These parameters are supplied to the Heat by
1800 ONAP at orchestration time. The parameters are generated and/or
1801 assigned by ONAP at orchestration time
1803 Independent Volume Templates
1804 ----------------------------
1806 ONAP supports independent deployment of a Cinder volume via
1807 separate Heat templates. This allows the volume to persist after VNF
1808 deletion so that they can be reused on another instance (e.g. during a
1811 A VNF Incremental Module or Base Module may have an independent volume
1812 module. Use of separate volume modules is optional. A Cinder volume may
1813 be embedded within the Incremental or Base Module if persistence is not
1816 If a VNF Incremental Module or Base Module has an independent volume
1817 module, the scope of volume templates must be 1:1 with Incremental
1818 module or Base module. A single volume module must create only the
1819 volumes required by a single Incremental module or Base module.
1821 The following rules apply to independent volume Heat templates:
1823 - Cinder volumes must be created in a separate Heat template from the
1824 Incremental and Base Modules.
1826 - A single volume module must include all Cinder volumes needed by
1827 the Incremental/Base module.
1829 - The volume template must define “outputs” for each Cinder volume
1830 resource universally unique identifier (UUID) (i.e. ONAP
1831 Volume Template Output Parameters).
1833 - The VNF Incremental Module or Base Module must define input
1834 parameters that match each Volume output parameter (i.e., ONAP
1835 Volume Template Output Parameters).
1837 - ONAP will supply the volume template outputs automatically to
1838 the bases/incremental template input parameters.
1840 - Volume modules may utilize nested Heat templates.
1842 **Example (volume template):**
1844 In this example, the {vm-type} has been left as a variable.
1845 {vm-type} is described in section 5.b {vm-type}. If the VM was a load
1846 balancer, the {vm-type} could be defined as “lb”
1848 .. code-block:: python
1853 {vm-type}\_volume\_size\_0:
1858 {vm-type}\_volume\_0:
1859 type: OS::Cinder::Volume
1863 template: VNF\_NAME\_volume\_0
1865 VNF\_NAME: { get\_param: vnf\_name }
1866 size: {get\_param: {vm-type}\_volume\_size\_0}
1869 *(+ additional volume definitions)*
1871 .. code-block:: python
1874 {vm-type}\_volume\_id\_0:
1875 value: {get\_resource: {vm-type}\_volume\_0}
1878 *(+ additional volume outputs)*
1880 *Example (VNF module template):*
1882 .. code-block:: python
1887 {vm-type}\_volume\_id\_0:
1893 type: OS::Nova::Server
1895 name: {get\_param: {vm-type}\_name\_0}
1899 {vm-type}\_0\_volume\_attach:
1900 type: OS::Cinder::VolumeAttachment
1902 instance\_uuid: { get\_resource: {vm-type}\_0 }
1903 volume\_id: { get\_param: {vm-type}\_volume\_id\_0 }
1905 Nested Heat Templates
1906 ---------------------
1908 ONAP supports nested Heat templates per the OpenStack
1909 specifications. Nested templates may be suitable for larger VNFs that
1910 contain many repeated instances of the same VM type(s). A common usage
1911 pattern is to create a nested template for each VM type along with its
1912 supporting resources. The master VNF template (or VNF Module template)
1913 may then reference these component templates either statically (by
1914 repeated definition) or dynamically (via *OS::Heat::ResourceGroup*).
1916 Nested template support in ONAP is subject to the following
1919 - Heat templates for ONAP must only have one level of nesting.
1920 ONAP only supports one level of nesting.
1922 - Nested templates must be referenced by file name in the master
1925 - i.e. use of *resource\_registry* in the .env file is *not*
1928 - Nested templates must have unique file names within the scope of the
1931 - ONAP does not support a directory hierarchy for nested
1932 templates. All templates must be in a single, flat directory (per
1935 - A nested template may be shared by all Modules (i.e., Heat templates)
1944 VNF templates must not include any resources for external networks
1945 connected to the VNF. In this context, “external” is in relation to the
1946 VNF itself (not with regard to the Network Cloud site). External
1947 networks may also be referred to as “inter-VNF” networks.
1949 - External networks must be orchestrated separately, so they can be
1950 shared by multiple VNFs and managed independently. When the external
1951 network is created, it must be assigned a unique {network-role} (See
1952 section 5.b {network-role}).
1954 - External networks must be passed into the VNF template as parameters,
1955 including the network-id (i.e. the neutron network UUID) and optional
1958 - VNF templates must pass the appropriate external network IDs into
1959 nested VM templates when nested Heat is used.
1961 - VNFs may use DHCP assigned IP addresses or assign fixed IPs when
1962 attaching VMs to an external network.
1964 - ONAP enforces a naming convention for parameters associated with
1967 - Parameter values associated with an external network will be
1968 generated and/or assigned by ONAP at orchestration time.
1970 - Parameter values associated with an external network must not be
1971 enumerated in the environment file.
1976 Orchestration activities related to internal networks must be included
1977 in VNF templates. In this context, “internal” is in relation to the VNF
1978 itself (not in relation to the Network Cloud site). Internal networks
1979 may also be referred to as “intra-VNF” networks or “private” networks.
1981 - Internal networks must not attach to any external gateways and/or
1982 routers. Internal networks are for intra-VM communication only.
1984 - In the modular approach, internal networks must be created in the
1985 Base Module template, with their resource IDs exposed as outputs
1986 (i.e., ONAP Base Template Output Parameters) for use by all
1987 add-on module templates. When the external network is created, it
1988 must be assigned a unique {network-role} (See section 5.b {network-role}).
1990 - VNFs may use DHCP assigned IP addresses or assign fixed IPs when
1991 attaching VMs to an internal network.
1993 - ONAP does not enforce a naming convention for parameters for
1994 internal network, however, a naming convention is provided that
1997 - Parameter values associated with an internal network must either be
1998 passed as output parameter from the base template (i.e., ONAP
1999 Base Template Output Parameters) into the add-on modules or be
2000 enumerated in the environment file.
2002 IP Address Assignment
2003 ---------------------
2005 - VMs connect to external networks using either fixed (e.g. statically
2006 assigned) IP addresses or DHCP assigned IP addresses.
2008 - VMs connect to internal networks using either fixed (e.g. statically
2009 assigned) IP addresses or DHCP assigned IP addresses.
2011 - Neutron Floating IPs must not be used. ONAP does not support
2012 Neutron Floating IPs.
2014 - ONAP supports the OS::Neutron::Port property
2015 “allowed\_address\_pairs.” See Section 5.b Property: allowed_address_pairs.
2017 Parameter Naming Convention
2018 ---------------------------
2023 A common *{vm-type}* identifier must be used throughout the Heat
2024 template in naming parameters, for each VM type in the VNF with the
2025 following exceptions:
2027 - The four ONAP Metadata parameters must not be prefixed with a
2028 common {vm-type} identifier. They are *vnf\_name*, *vnf\_id*,
2029 *vf\_module\_id*, *vf\_module\_name*.
2031 - Parameters only referring to a network or subnetwork must not be
2032 prefixed with a common {vm-type} identifier.
2034 - The parameter referring to the OS::Nova::Server property
2035 availability\_zone must not be prefixed with a common {vm-type}
2038 - {vm-type} must be unique to the VNF. It does not have to be globally
2039 unique across all VNFs that ONAP supports.
2044 VNF templates must not include any resources for external networks
2045 connected to the VNF. In this context, “external” is in relation to the
2046 VNF itself (not with regard to the Network Cloud site). External
2047 networks may also be referred to as “inter-VNF” networks.
2049 External networks must be orchestrated separately, so they can be shared
2050 by multiple VNFs and managed independently. When the external network is
2051 created, it must be assigned a unique {network-role}.
2053 “External” networks must be passed into the VNF template as parameters.
2054 Examples include the network-id (i.e. the neutron network UUID) and
2055 optional subnet ID. See section 5.b Property: network & subnet.
2057 Any parameter that is associated with an external network must include
2058 the {network-role} as part of the parameter name.
2060 Internal network parameters must also define a {network-role}. Any
2061 parameter that is associated with an internal network must include
2062 int\_{network-role} as part of the parameter name.
2064 Resource: OS::Nova::Server - Parameters
2065 ---------------------------------------
2067 The following OS::Nova::Server Resource Property Parameter Names must
2068 follow the ONAP parameter Naming Convention. All the parameters
2069 associated with OS::Nova::Server are classified as ONAP
2070 Orchestration Parameters.
2072 +----------------------+-----------------------------------------+------------------+
2073 | OS::Nova::Server |
2074 +======================+=========================================+==================+
2075 | Property | ONAP Parameter Naming Convention | Parameter Type |
2076 +----------------------+-----------------------------------------+------------------+
2077 | image | {*vm-type*}\_image\_name | string |
2078 +----------------------+-----------------------------------------+------------------+
2079 | flavor | {*vm-type*}\_flavor\_name | string |
2080 +----------------------+-----------------------------------------+------------------+
2081 | name | {*vm-type*}\_name\_{*index*} | string |
2082 +----------------------+-----------------------------------------+------------------+
2083 | | {vm-type}\_names | CDL |
2084 +----------------------+-----------------------------------------+------------------+
2085 | availability\_zone | availability\_zone\_{index} | string |
2086 +----------------------+-----------------------------------------+------------------+
2088 Table 2 Resource Property Parameter Names
2093 Image is an ONAP Orchestration Constant parameter. The image must
2094 be referenced by the Network Cloud Service Provider (NCSP) image name,
2095 with the parameter enumerated in the Heat environment file.
2097 The parameters must be named *“{vm-type}\_image\_name”* in the VNF.
2099 Each VM type (e.g., {vm-type}) should have a separate parameter for
2100 images, even if several share the same image. This provides maximum
2101 clarity and flexibility.
2106 Flavor is an ONAP Orchestration Constant parameter. The flavors
2107 must be referenced by the Network Cloud Service Provider (NCSP) flavor
2108 name, with the parameter enumerated in the Heat environment file.
2110 The parameters must be named *“{vm-type}\_flavor\_name”* for each
2111 *{vm-type}* in the VNF.
2113 Each VM type should have separate parameters for flavors, even if more
2114 than one VM shares the same flavor. This provides maximum clarity and
2120 Name is an OpenEOMP Orchestration parameter; the value is provided to
2121 the Heat template by ONAP.
2123 VM names (hostnames) for assignment to VM instances must be passed to
2124 Heat templates either as
2126 - an array (comma delimited list) for each VM type
2128 - a set of fixed-index parameters for each VM type instance.
2130 Each element in the VM Name list should be assigned to successive
2131 instances of that VM type.
2133 The parameter names must reflect the VM Type (i.e., include the
2134 {vm-type} in the parameter name.) The parameter name format must be one
2137 - If the parameter type is a comma delimited list: {**vm-type**}\_names
2139 - If the parameter type is a string with a fixed index:
2140 {**vm-type**}\_name\_{**index**}
2142 If a VNF contains more than three instances of a given {vm-type}, the
2143 CDL form of the parameter name (i.e., *{vm-type}*\ \_names} should be
2144 used to minimize the number of unique parameters defined in the Heat.
2148 .. code-block:: python
2152 type: comma\_delimited\_list
2153 description: VM Names for {vm-type} VMs
2154 {vm-type}\_name\_{index}:
2156 description: VM Name for {vm-type} VM {index}
2160 In this example, the {vm-type} has been defined as “lb” for load
2163 .. code-block:: python
2167 type: comma\_delimited\_list
2168 description: VM Names for lb VMs
2171 type: OS::Nova::Server
2173 name: { get\_param: [lb\_names, 0] }
2177 type: OS::Nova::Server
2179 name: { get\_param: [lb\_names, 1] }
2182 **Example (fixed-index):**
2184 In this example, the {vm-type} has been defined as “lb” for load
2187 .. code-block:: python
2192 description: VM Name for lb VM 0
2195 description: VM Name for lb VM 1
2199 type: OS::Nova::Server
2201 name: { get\_param: lb\_name\_0 }
2205 type: OS::Nova::Server
2207 name: { get\_param: lb\_name\_1 }
2210 Property: availability\_zone
2211 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2213 Availability\_zone is an ONAP Orchestration parameter; the value is
2214 provided to the Heat template by ONAP.
2216 Availability zones must be passed as individual numbered parameters (not
2217 as arrays) so that VNFs with multi-availability zone requirements can
2218 clearly specify that in its parameter definitions.
2220 The availability zone parameter must be defined as
2221 “availability\_zone\_{index}”, with the {index} starting at zero.
2225 In this example, the {vm-type} has been defined as “lb” for load
2228 .. code-block:: python
2232 type: comma\_delimited\_list
2233 description: VM Names for lb VMs
2234 availability\_zone\_0:
2236 description: First availability zone ID or Name
2240 type: OS::Nova::Server
2242 name: { get\_param: [lb\_names, 0] }
2243 availability\_zone: { get\_param: availability\_zone\_0 }
2246 Resource: OS::Nova::Server - Metadata
2247 -------------------------------------
2249 This section describes the ONAP Metadata parameters.
2251 ONAP Heat templates must include the following three parameters
2252 that are used as metadata under the resource OS::Nova:Server: vnf\_id,
2253 vf\_module\_id, vnf\_name
2255 ONAP Heat templates may include the following parameter that is
2256 used as metadata under the resource OS::Nova:Server: vf\_module\_name.
2258 These parameters are all classified as ONAP Metadata.
2260 +---------------------------+------------------+----------------------+
2261 | Metadata Parameter Name | Parameter Type | Mandatory/Optional |
2262 +===========================+==================+======================+
2263 | vnf\_id | string | mandatory |
2264 +---------------------------+------------------+----------------------+
2265 | vf\_module\_id | string | mandatory |
2266 +---------------------------+------------------+----------------------+
2267 | vnf\_name | string | mandatory |
2268 +---------------------------+------------------+----------------------+
2269 | vf\_module\_name | string | optional |
2270 +---------------------------+------------------+----------------------+
2272 Table 3 ONAP Metadata
2274 Required Metadata Elements
2275 ~~~~~~~~~~~~~~~~~~~~~~~~~~
2277 The vnf\_id, vf\_module\_id, and vnf\_name metadata elements are
2278 required (must) for *OS::Nova::Server* resources. The metadata
2279 parameters will be used by ONAP to associate the servers with the
2284 - *“vnf\_id”* parameter value will be supplied by ONAP.
2285 ONAP generates the UUID that is the vnf\_id and supplies it
2286 to the Heat at orchestration time.
2290 - “\ *vf\_module\_id”* parameter value will be supplied by
2291 ONAP. ONAP generates the UUID that is the vf\_module\_id
2292 and supplies it to the Heat at orchestration time.
2296 - “\ *vnf\_name”* parameter value will be generated and/or assigned
2297 by ONAP and supplied to the Heat by ONAP at
2300 Optional Metadata Elements
2301 ~~~~~~~~~~~~~~~~~~~~~~~~~~
2303 The following metadata element is optional for *OS::Nova::Server*
2306 - *vf\_module\_name*
2308 - The vf\_module\_name is the name of the name of the Heat stack
2309 (e.g., <STACK\_NAME>) in the command “Heat stack-create” (e.g.
2310 Heat stack-create [-f <FILE>] [-e <FILE>] <STACK\_NAME>). The
2311 <STACK\_NAME> needs to be specified as part of the orchestration
2314 - *“vf\_module\_name”* parameter value, when used, will be supplied
2315 by ONAP to the Heat at orchestration time. The parameter will
2316 be generated and/or assigned by ONAP and supplied to the Heat
2317 by ONAP at orchestration time.
2321 In this example, the {vm-type} has been defined as “lb” for load
2324 .. code-block:: python
2329 description: Unique name for this VNF instance
2332 description: Unique ID for this VNF instance
2335 description: Unique name for this VNF Module instance
2338 description: Unique ID for this VNF Module instance
2342 type: OS::Nova::ServerGroup
2346 template: VNF\_NAME\_lb\_ServerGroup
2348 VNF\_NAME: { get\_param: VNF\_name }
2349 policies: [ ‘anti-affinity’ ]
2352 type: OS::Nova::Server
2354 name: { get\_param: lb\_name\_0 }
2356 group: { get\_resource: lb\_server\_group }
2358 vnf\_name: { get\_param: vnf\_name }
2359 vnf\_id: { get\_param: vnf\_id }
2360 vf\_module\_name: { get\_param: vf\_module\_name }
2361 vf\_module\_id: { get\_param: vf\_module\_id }
2364 Resource: OS::Neutron::Port - Parameters
2365 ----------------------------------------
2367 The following four OS::Neutron::Port Resource Property Parameters must
2368 adhere to the ONAP parameter naming convention.
2376 - allowed\_address\_pairs
2378 These four parameters reference a network, which maybe an external
2379 network or an internal network. Thus the parameter will include
2380 {network-role} in its name.
2382 When the parameter references an external network, the parameter is an
2383 ONAP Orchestration Parameter. The parameter value must be supplied
2384 by ONAP. The parameters must adhere to the ONAP parameter
2387 +---------------------------+-----------------------------------------------+------------------+
2388 | OS::Neutron::Port |
2389 +===========================+===============================================+==================+
2390 | Property | Parameter Name for External Networks | Parameter Type |
2391 +---------------------------+-----------------------------------------------+------------------+
2392 | Network | {network-role}\_net\_id | string |
2393 +---------------------------+-----------------------------------------------+------------------+
2394 | | {network-role}\_net\_name | string |
2395 +---------------------------+-----------------------------------------------+------------------+
2396 | Subnet | {network-role}\_subnet\_id | string |
2397 +---------------------------+-----------------------------------------------+------------------+
2398 | | {network-role}\_v6\_subnet\_id | string |
2399 +---------------------------+-----------------------------------------------+------------------+
2400 | fixed\_ips | {vm-type}\_{network-role}\_ip\_{index} | string |
2401 +---------------------------+-----------------------------------------------+------------------+
2402 | | {vm-type}\_{network-role}\_ips | CDL |
2403 +---------------------------+-----------------------------------------------+------------------+
2404 | | {vm-type}\_{network-role}\_v6\_ip\_{index} | string |
2405 +---------------------------+-----------------------------------------------+------------------+
2406 | | {vm-type}\_{network-role}\_v6\_ips | CDL |
2407 +---------------------------+-----------------------------------------------+------------------+
2408 | allowed\_address\_pairs | {vm-type}\_{network-role}\_floating\_ip | string |
2409 +---------------------------+-----------------------------------------------+------------------+
2410 | | {vm-type}\_{network-role}\_floating\_v6\_ip | string |
2411 +---------------------------+-----------------------------------------------+------------------+
2412 | | {vm-type}\_{network-role}\_ip\_{index} | string |
2413 +---------------------------+-----------------------------------------------+------------------+
2414 | | {vm-type}\_{network-role}\_ips | CDL |
2415 +---------------------------+-----------------------------------------------+------------------+
2416 | | {vm-type}\_{network-role}\_v6\_ip\_{index} | string |
2417 +---------------------------+-----------------------------------------------+------------------+
2418 | | {vm-type}\_{network-role}\_v6\_ips | CDL |
2419 +---------------------------+-----------------------------------------------+------------------+
2421 Table 4 Port Resource Property Parameters (External Networks)
2423 When the parameter references an internal network, the parameter is a
2424 VNF Orchestration Parameters. The parameter value(s) must be supplied
2425 either via an output statement(s) in the base module (i.e., ONAP
2426 Base Template Output Parameters) or be enumerated in the environment
2427 file. The parameters must adhere to the following parameter naming
2430 +---------------------------+----------------------------------------------------+------------------+
2431 | OS::Neutron::Port |
2432 +===========================+====================================================+==================+
2433 | Property | Parameter Name for Internal Networks | Parameter Type |
2434 +---------------------------+----------------------------------------------------+------------------+
2435 | Network | int\_{network-role}\_net\_id | string |
2436 +---------------------------+----------------------------------------------------+------------------+
2437 | | int\_{network-role}\_net\_name | string |
2438 +---------------------------+----------------------------------------------------+------------------+
2439 | Subnet | int\_{network-role}\_subnet\_id | string |
2440 +---------------------------+----------------------------------------------------+------------------+
2441 | | Int\_{network-role}\_v6\_subnet\_id | string |
2442 +---------------------------+----------------------------------------------------+------------------+
2443 | fixed\_ips | {vm-type}\_int\_{network-role}\_ip\_{index} | string |
2444 +---------------------------+----------------------------------------------------+------------------+
2445 | | {vm-type}\_int\_{network-role}\_ips | CDL |
2446 +---------------------------+----------------------------------------------------+------------------+
2447 | | {vm-type}\_int\_{network-role}\_v6\_ip\_{index} | string |
2448 +---------------------------+----------------------------------------------------+------------------+
2449 | | {vm-type}\_int\_{network-role}\_v6\_ips | CDL |
2450 +---------------------------+----------------------------------------------------+------------------+
2451 | allowed\_address\_pairs | {vm-type}\_int\_{network-role}\_floating\_ip | string |
2452 +---------------------------+----------------------------------------------------+------------------+
2453 | | {vm-type}\_int\_{network-role}\_floating\_v6\_ip | string |
2454 +---------------------------+----------------------------------------------------+------------------+
2455 | | {vm-type}\_int\_{network-role}\_ip\_{index} | string |
2456 +---------------------------+----------------------------------------------------+------------------+
2457 | | {vm-type}\_int\_{network-role}\_ips | CDL |
2458 +---------------------------+----------------------------------------------------+------------------+
2459 | | {vm-type}\_int\_{network-role}\_v6\_ip\_{index} | string |
2460 +---------------------------+----------------------------------------------------+------------------+
2461 | | {vm-type}\_int\_{network-role}\_v6\_ips | CDL |
2462 +---------------------------+----------------------------------------------------+------------------+
2464 Table 5 Port Resource Property Parameters (Internal Networks)
2466 Property: network & subnet
2467 ~~~~~~~~~~~~~~~~~~~~~~~~~~
2469 The property “networks” in the resource OS::Neutron::Port must be
2470 referenced by Neutron Network ID, a UUID value, or by the network name
2471 defined in OpenStack.
2473 When the parameter is referencing an “external” network, the parameter
2474 must adhere to the following naming convention
2476 - *“{*\ network-role}\_net\_id”, for the Neutron network ID
2478 - “{network-role}\_net\_name”, for the network name in OpenStack
2480 When the parameter is referencing an “internal” network, the parameter
2481 must adhere to the following naming convention.
2483 - “\ *int\_{network-role}\_net\_id*\ ”, for the Neutron network ID
2485 - “\ *int\_{network-role}\_net\_name*\ ”, for the network name in
2488 The property “subnet\_id” must be used if a DHCP IP address assignment
2489 is being requested and the DHCP IP address assignment is targeted at a
2492 The property “subnet\_id” should not be used if all IP assignments are
2493 fixed, or if the DHCP assignment does not target a specific subnet
2495 When the parameter is referencing an “external” network subnet, the
2496 “subnet\_id” parameter must adhere to the following naming convention.
2498 - “\ *{network-role}\_subnet\_id*\ ” if the subnet is an IPv4 subnet
2500 - “\ *{network-role}\_v6\_subnet\_id”* if the subnet is an IPv6 subnet
2502 When the parameter is referencing an “internal” network subnet, the
2503 “subnet\_id” parameter must adhere to the following naming convention.
2505 - “\ *int\_{network-role}\_subnet\_id*\ ” if the subnet is an IPv4
2508 - “\ *int\_{network-role}\_v6\_subnet\_id*\ ” if the subnet is an IPv6
2513 .. code-block:: python
2516 {network-role}\_net\_id:
2518 description: Neutron UUID for the {network-role} network
2519 {network-role}\_net\_name:
2521 description: Neutron name for the {network-role} network
2522 {network-role}\_subnet\_id:
2524 description: Neutron subnet UUID for the {network-role} network
2525 {network-role}\_v6\_subnet\_id:
2527 description: Neutron subnet UUID for the {network-role} network
2531 In this example, the {network-role} has been defined as “oam” to
2532 represent an oam network and the {vm-type} has been defined as “lb” for
2535 .. code-block:: python
2540 description: Neutron UUID for the oam network
2544 type: OS::Neutron::Port
2545 network: { get\_param: oam\_net\_id }
2547 Property: fixed\_ips
2548 ~~~~~~~~~~~~~~~~~~~~
2550 The property “fixed\_ips” in the resource OS::Neutron::Port must be used
2551 when statically assigning IP addresses.
2553 An IP address is assigned to a port on a type of VM (i.e., {vm-type})
2554 that is connected to a type of network (i.e., {network-role}). These two
2555 tags are components of the parameter name.
2557 When the “fixed\_ips” parameter is referencing an “external” network,
2558 the parameter must adhere to the naming convention below. The parameter
2559 may be a comma delimited list or a string.
2561 There must be a different parameter name for IPv4 IP addresses and IPv6
2564 - **Comma-delimited list:** Each element in the IP list should be
2565 assigned to successive instances of that VM type on that network.
2567 - *Format for IPv4 addresses:* {vm-type}\_{network-role}\_ips
2569 - *Format for IPv6 addresses:* {vm-type}\_{network-role}\_v6\_ips
2571 - **A set of fixed-index parameters:** In this case, the parameter
2572 should have “\ *type: string*\ ” and must be repeated for every IP
2573 expected for each {vm-type} + {network-role} pair.
2575 - *Format for IPv4 addresses:*
2576 {vm-type}\_{network-role}\_ip\_{index}
2578 - *Format for IPv6 addresses:*
2579 {vm-type}\_{network-role}\_v6\_ip\_{index}
2581 When the “fixed\_ips” parameter is referencing an “internal” network,
2582 the parameter must adhere to the naming convention below. The parameter
2583 may be a comma delimited list or a string.
2585 There must be a different parameter name for IPv4 IP addresses and IPv6
2588 - **Comma-delimited list:** Each element in the IP list should be
2589 assigned to successive instances of that VM type on that network.
2591 - *Format for IPv4 addresses:* {vm-type}\_int\_{network-role}\_ips
2593 - *Format for IPv6 addresses:*
2594 {vm-type}\_int\_{network-role}\_v6\_ips
2596 - **A set of fixed-index parameters:** In this case, the parameter
2597 should have “\ *type: string*\ ” and must be repeated for every IP
2598 expected for each {vm-type} and {network-role}pair.
2600 - *Format for IPv4 addresses:*
2601 {vm-type}\_int\_{network-role}\_ip\_{index}
2603 - *Format for IPv6 addresses:*
2604 {vm-type}\_int\_{network-role}\_v6\_ip\_{index}
2606 If a VNF contains more than three IP addresses for a given {vm-type} and
2607 {network-role} combination, the CDL form of the parameter name should be
2608 used to minimize the number of unique parameters defined in the Heat.
2610 *Example (external network)*
2612 .. code-block:: python
2615 {vm-type}\_{network-role}\_ips:
2616 type: comma\_delimited\_list
2617 description: Fixed IPv4 assignments for {vm-type} VMs on the
2618 {network-role} network
2619 {vm-type}\_{network-role}\_v6\_ips:
2620 type: comma\_delimited\_list
2621 description: Fixed IPv6 assignments for {vm-type} VMs on the
2622 {network-role} network
2623 {vm-type}\_{network-role}\_ip\_{index}:
2625 description: Fixed IPv4 assignment for {vm-type} VM {index} on the
2626 {network-role} network
2627 {vm-type}\_{network-role}\_v6\_ip\_{index}:
2629 description: Fixed IPv6 assignment for {vm-type} VM {index} on the
2630 {network-role} network
2632 *Example (CDL parameter for IPv4 Address Assignments to an external
2635 In this example, the {network-role} has been defined as “oam” to
2636 represent an oam network and the {vm-type} has been defined as “db” for
2639 .. code-block:: python
2644 description: Neutron UUID for a oam network
2646 type: comma\_delimited\_list
2647 description: Fixed IP assignments for db VMs on the oam network
2651 type: OS::Neutron::Port
2652 network: { get\_param: oam\_net\_id }
2653 fixed\_ips: [ { “ip\_address”: {get\_param: [ db\_oam\_ips, 0]
2656 type: OS::Neutron::Port
2657 network: { get\_param: oam\_net\_id }
2658 fixed\_ips: [ { “ip\_address”: {get\_param: [ db\_oam\_ips, 1]
2661 *Example (string parameters for IPv4 Address Assignments to an external
2664 In this example, the {network-role} has been defined as “oam” to
2665 represent an oam network and the {vm-type} has been defined as “db” for
2668 .. code-block:: python
2673 description: Neutron UUID for an OAM network
2676 description: First fixed IP assignment for db VMs on the OAM network
2679 description: Second fixed IP assignment for db VMs on the OAM network
2683 type: OS::Neutron::Port
2684 network: { get\_param: oam\_net\_id }
2685 fixed\_ips: [ { “ip\_address”: {get\_param: db\_oam\_ip\_0}}]
2687 type: OS::Neutron::Port
2688 network: { get\_param: oam\_net\_id }
2689 fixed\_ips: [ { “ip\_address”: {get\_param: db\_oam\_ip\_1}}]
2691 Property: allowed\_address\_pairs
2692 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2694 The property “allowed\_address\_pairs” in the resource OS::Neutron::Port
2695 allows the user to specify mac\_address/ip\_address (CIDR) pairs that
2696 pass through a port regardless of subnet. This enables the use of
2697 protocols such as VRRP, which floats an IP address between two instances
2698 to enable fast data plane failover. An “allowed\_address\_pairs” is
2699 unique to a {vm-type} and {network-role} combination. The management of
2700 these IP addresses (i.e. transferring ownership between active and
2701 standby VMs) is the responsibility of the application itself.
2703 Note that these parameters are *not* intended to represent Neutron
2704 “Floating IP” resources, for which OpenStack manages a pool of public IP
2705 addresses that are mapped to specific VM ports. In that case, the
2706 individual VMs are not even aware of the public IPs, and all assignment
2707 of public IPs to VMs is via OpenStack commands. ONAP does not
2708 support Neutron-style Floating IPs.
2710 Both IPv4 and IPv6 “allowed\_address\_pairs” addresses are supported.
2712 If property “allowed\_address\_pairs” is used with an external network,
2713 the parameter name must adhere to the following convention:
2715 - *Format for IPv4 addresses: {vm-type}\_{network-role}\_floating\_ip*
2717 - *Format for IPv6 addresses:
2718 {vm-type}\_{network-role}\_floating\_v6\_ip*
2722 .. code-block:: python
2725 {vm-type}\_{network-role}\_floating\_ip:
2727 description: VIP for {vm-type} VMs on the {network-role} network
2728 {vm-type}\_{network-role}\_floating\_v6\_ip:
2730 description: VIP for {vm-type} VMs on the {network-role} network
2734 In this example, the {network-role} has been defined as “oam” to
2735 represent an oam network and the {vm-type} has been defined as “db” for
2738 .. code-block:: python
2742 type: comma\_delimited\_list
2743 description: Fixed IPs for db VMs on the oam network
2744 db\_oam\_floating\_ip:
2746 description: Floating IP for db VMs on the oam network
2749 type: OS::Neutron::Port
2750 network: { get\_param: oam\_net\_id }
2751 fixed\_ips: [ { “ip\_address”: {get\_param: [db\_oam\_ips,0] }}]
2752 allowed\_address\_pairs: [
2753 { “ip\_address”: {get\_param: db\_oam\_floating\_ip}}]
2755 type: OS::Neutron::Port
2756 network: { get\_param: oam\_net\_id }
2757 fixed\_ips: [ { “ip\_address”: {get\_param: [db\_oam\_ips,1] }}]
2758 allowed\_address\_pairs: [
2759 { “ip\_address”: {get\_param: db\_oam\_floating\_ip}}]
2761 If property “allowed\_address\_pairs” is used with an internal network,
2762 the parameter name should adhere to the following convention:
2764 - *Format for IPv4 addresses:
2765 {vm-type}\_int\_{network-role}\_floating\_ip*
2767 - *Format for IPv6 addresses:
2768 {vm-type}\_int\_{network-role}\_floating\_v6\_ip*
2770 Using the parameter *{vm-type}\_{network-role}\_floating\_ip* or
2771 *{vm-type}\_{network-role}\_floating\_v6\_ip* provides only one floating
2772 IP per Vm-type{vm-type} and {network-role} pair. If there is a need for
2773 multiple floating IPs (e.g., Virtual IPs (VIPs)) for a given {vm-type}
2774 and {network-role} combination within a VNF, then the parameter names
2775 defined for the “fixed\_ips” should be used with the
2776 “allowed\_address\_pairs” property. The examples below illustrate this.
2778 Below example reflects two load balancer pairs in a single VNF. Each
2781 *Example: A VNF has four load balancers. Each pair has a unique VIP.*
2783 *Pair 1:* lb\_0 and lb\_1 share a unique VIP
2785 *Pair 2:* lb\_2 and lb\_3 share a unique VIP
2787 In this example, the {network-role} has been defined as “oam” to
2788 represent an oam network and the {vm-type} has been defined as “lb” for
2791 .. code-block:: python
2795 type: OS::Neutron::Port
2796 network: { get\_param: oam\_net\_id }
2797 fixed\_ips: [ { “ip\_address”: {get\_param: [lb\_oam\_ips,0] }}]
2798 allowed\_address\_pairs: [{ “ip\_address”: {get\_param: [lb\_oam\_ips,2] }}]
2801 type: OS::Neutron::Port
2802 network: { get\_param: oam\_net\_id }
2803 fixed\_ips: [ { “ip\_address”: {get\_param: [lb\_oam\_ips,1] }}]
2804 allowed\_address\_pairs: [{ “ip\_address”: {get\_param: [lb\_oam\_ips,2] }}]
2807 type: OS::Neutron::Port
2808 network: { get\_param: oam\_net\_id }
2809 fixed\_ips: [ { “ip\_address”: {get\_param: [lb\_oam\_ips,3] }}]
2810 allowed\_address\_pairs: [{ “ip\_address”: {get\_param: [lb\_oam\_ips,5] }}]
2813 type: OS::Neutron::Port
2814 network: { get\_param: oam\_net\_id }
2815 fixed\_ips: [ { “ip\_address”: {get\_param: [lb\_oam\_ips,4] }}]
2816 allowed\_address\_pairs: [{ “ip\_address”: {get\_param: [lb\_oam\_ips,5] }}]
2818 Below example reflects a single app VM pair within a VNF with two VIPs:
2820 *Example: A VNF has two load balancers. The pair of load balancers share
2823 In this example, the {network-role} has been defined as “oam” to
2824 represent an oam network and the {vm-type} has been defined as “lb” for
2827 .. code-block:: python
2831 type: OS::Neutron::Port
2832 network: { get\_param: oam\_net\_id }
2833 fixed\_ips: [ { “ip\_address”: {get\_param: [lb\_oam\_ips,0] }}]
2834 allowed\_address\_pairs: [{ "ip\_address": {get\_param: [lb\_oam\_ips,2] }, {get\_param: [lb\_oam\_ips,3] }}]
2837 type: OS::Neutron::Port
2838 network: { get\_param: oam\_net\_id }
2839 fixed\_ips: [ { “ip\_address”: {get\_param: [lb\_oam\_ips,1] }}]
2840 allowed\_address\_pairs: [{ "ip\_address": {get\_param: [lb\_oam\_ips,2] }, {get\_param: [lb\_oam\_ips,3] }}]
2842 As a general rule, provide the fixed IPs for the VMs indexed first in
2843 the CDL and then the VIPs as shown in the examples above.
2845 Resource Property: name
2846 -----------------------
2848 The parameter naming standard for the resource OS::Nova::Server has been
2849 defined in Section 5.b Resource: OS::Nova::Server – Parameters. This section describes how the name property
2850 of all other resources must be defined.
2852 Heat templates must use the Heat “str\_replace” function in conjunction
2853 with the ONAP supplied metadata parameter *vnf\_name* or
2854 *vnf\_module\_id* to generate a unique name for each VNF instance. This
2855 prevents the use of unique parameters values for resource “name”
2856 properties to be enumerated in a per instance environment file.
2860 - In most cases, only the use of the vnf\_name is necessary to create a
2863 - the Heat pseudo parameter 'OS::stack\_name’ can also be used in the
2864 ‘str\_replace’ construct to generate a unique name when the vnf\_name
2865 does not provide uniqueness
2867 .. code-block:: python
2869 type: OS::Cinder::Volume
2873 template: VF\_NAME\_STACK\_NAME\_oam\_volume
2875 VF\_NAME: { get\_param: vnf\_name }
2876 STACK\_NAME: { get\_param: 'OS::stack\_name' }
2878 type: OS::Neutron::SecurityGroup
2880 description: Security Group of Firewall
2883 template: VNF\_NAME\_Firewall\_SecurityGroup
2885 VNF\_NAME: { get\_param: vnf\_name }
2890 ONAP defines three type of Output Parameters.
2892 Base Template Output Parameters:
2893 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2895 The base template output parameters are available for use as input
2896 parameters in all add-on modules. The add-on modules may (or may not)
2897 use these parameters.
2899 Volume Template Output Parameters:
2900 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2902 The volume template output parameters are only available only for the
2903 module (base or add on) that the volume is associated with.
2905 Predefined Output Parameters
2906 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2908 ONAP currently defines one predefined output parameter.
2910 OAM Management IP Addresses
2911 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
2913 Many VNFs will have a management interface for application controllers
2914 to interact with and configure the VNF. Typically, this will be via a
2915 specific VM that performs a VNF administration function. The IP address
2916 of this interface must be captured and inventoried by ONAP. This
2917 might be a VIP if the VNF contains an HA pair of management VMs, or may
2918 be a single IP address assigned to one VM.
2920 The Heat template may define either (or both) of the following Output
2921 parameters to identify the management IP address.
2923 - *oam\_management\_v4\_address*
2925 - *oam\_management\_v6\_address*
2929 - The Management IP Address should be defined only once per VNF, so it
2930 would only appear in one Module template
2932 - If a fixed IP for the admin VM is passed as an input parameter, it
2933 may be echoed in the output parameters
2935 - If the IP for the admin VM is obtained via DHCP, it may be obtained
2936 from the resource attributes
2940 .. code-block:: python
2944 type: OS::Nova::Server
2947 - network: {get\_param: oam\_net\_id }
2951 oam\_management\_v4\_address:
2952 value: {get\_attr: [admin\_server, networks, {get\_param: oam\_net\_id}, 0] }
2954 Heat Template Constructs
2955 ------------------------
2960 Heat templates *should not* reference any HTTP-based resource
2961 definitions, any HTTP-based nested configurations, or any HTTP-based
2964 - During orchestration, ONAP *should not* retrieve any such
2965 resources from external/untrusted/unknown sources.
2967 - VNF images should not contain such references in user-data or other
2968 configuration/operational scripts that are specified via Heat or
2969 encoded into the VNF image itself.
2971 *Note:* HTTP-based references are acceptable if the HTTP-based reference
2972 is accessing information with the VM private/internal network.
2974 Heat Files Support (get\_file)
2975 ------------------------------
2977 Heat Templates may contain the inclusion of text files into Heat
2978 templates via the Heat “get\_file” directive. This may be used, for
2979 example, to define a common “user-data” script, or to inject files into
2980 a VM on startup via the “personality” property.
2982 Support for Heat Files is subject to the following limitations:
2984 - The ‘get\_files’ targets must be referenced in Heat templates by file
2985 name, and the corresponding files should be delivered to ONAP
2986 along with the Heat templates.
2988 - URL-based file retrieval must not be used; it is not supported.
2990 - The included files must have unique file names within the scope of
2993 - ONAP does not support a directory hierarchy for included files.
2995 - All files must be in a single, flat directory per VNF.
2997 - Included files may be used by all Modules within a given VNF.
2999 - get\_file directives may be used in both non-nested and nested
3002 Use of Heat ResourceGroup
3003 -------------------------
3005 The *OS::Heat::ResourceGroup* is a useful Heat element for creating
3006 multiple instances of a given resource or collection of resources.
3007 Typically it is used with a nested Heat template, to create, for
3008 example, a set of identical *OS::Nova::Server* resources plus their
3009 related *OS::Neutron::Port* resources via a single resource in a master
3012 *ResourceGroup* may be used in ONAP to simplify the structure of a
3013 Heat template that creates multiple instances of the same VM type.
3014 However, there are important caveats to be aware of.
3016 *ResourceGroup* does not deal with structured parameters
3017 (comma-delimited-list and json) as one might typically expect. In
3018 particular, when using a list-based parameter, where each list element
3019 corresponds to one instance of the *ResourceGroup*, it is not possible
3020 to use the intrinsic “loop variable” %index% in the *ResourceGroup*
3023 For instance, the following is **not** valid Heat for a *ResourceGroup*:
3025 .. code-block:: python
3027 type: OS::Heat::ResourceGroup
3029 type: my\_nested\_vm\_template.yaml
3031 name: {get\_param: [vm\_name\_list, %index%]}
3033 Although this appears to use the nth entry of the *vm\_name\_list* list
3034 for the nth element of the *ResourceGroup*, it will in fact result in a
3035 Heat exception. When parameters are provided as a list (one for each
3036 element of a *ResourceGroup*), you must pass the complete parameter to
3037 the nested template along with the current index as separate parameters.
3039 Below is an example of an **acceptable** Heat Syntax for a
3042 .. code-block:: python
3044 type: OS::Heat::ResourceGroup
3046 type: my\_nested\_vm\_template.yaml
3048 names: {get\_param: vm\_name\_list}
3051 You can then reference within the nested template as:
3053 { get\_param: [names, {get\_param: index} ] }
3055 Note that this is workaround has very important limitations. Since the
3056 entire list parameter is passed to the nested template, any change to
3057 that list (e.g., adding an additional element) will cause Heat to treat
3058 the entire parameter as updated within the context of the nested
3059 template (i.e., for each *ResourceGroup* element). As a result, if
3060 *ResourceGroup* is ever used for scaling (e.g., increment the count and
3061 include an additional element to each list parameter), Heat will often
3062 rebuild every existing element in addition to adding the “deltas”. For
3063 this reason, use of *ResourceGroup* for scaling in this manner is not
3069 When Nova Servers are created via Heat templates, they may be passed a
3070 “keypair” which provides an ssh key to the ‘root’ login on the newly
3071 created VM. This is often done so that an initial root key/password does
3072 not need to be hard-coded into the image.
3074 Key pairs are unusual in OpenStack, because they are the one resource
3075 that is owned by an OpenStack User as opposed to being owned by an
3076 OpenStack Tenant. As a result, they are usable only by the User that
3077 created the keypair. This causes a problem when a Heat template attempts
3078 to reference a keypair by name, because it assumes that the keypair was
3079 previously created by a specific ONAP user ID.
3081 When a keypair is assigned to a server, the SSH public-key is
3082 provisioned on the VMs at instantiation time. They keypair itself is not
3083 referenced further by the VM (i.e. if the keypair is updated with a new
3084 public key, it would only apply to subsequent VMs created with that
3087 Due to this behavior, the recommended usage of keypairs is in a more
3088 generic manner which does not require the pre-requisite creation of a
3089 keypair. The Heat should be structured in such a way as to:
3091 - Pass a public key as a parameter value instead of a keypair name
3093 - Create a new keypair within the VNF Heat templates (in the base
3094 module) for use within that VNF
3096 By following this approach, the end result is the same as pre-creating
3097 the keypair using the public key – i.e., that public key will be
3098 provisioned in the new VM. However, this recommended approach also makes
3099 sure that a known public key is supplied (instead of having OpenStack
3100 generate a public/private pair to be saved and tracked outside of
3101 ONAP). It also removes any access/ownership issues over the created
3104 The public keys may be enumerated as a VNF Orchestration Constant in the
3105 environment file (since it is public, it is not a secret key), or passed
3106 at run-time as an instance-specific parameters. ONAP will never
3107 automatically assign a public/private key pair.
3109 *Example (create keypair with an existing ssh public-key for {vm-type}
3110 of lb (for load balancer)):*
3112 .. code-block:: python
3121 type: OS::Nova::Keypair
3125 template: VNF\_NAME\_key\_pair
3127 VNF\_NAME: { get\_param: vnf\_name }
3128 public\_key: {get\_param: lb\_ssh\_public\_key}
3129 save\_private\_key: false
3134 OpenStack allows a tenant to create Security groups and define rules
3135 within the security groups.
3137 Security groups, with their rules, may either be created in the Heat
3138 template or they can be pre-created in OpenStack and referenced within
3139 the Heat template via parameter(s). There can be a different approach
3140 for security groups assigned to ports on internal (intra-VNF) networks
3141 or external networks (inter-VNF). Furthermore, there can be a common
3142 security group across all VMs for a specific network or it can vary by
3143 VM (i.e., {vm-type}) and network type (i.e., {network-role}).
3145 Anti-Affinity and Affinity Rules
3146 --------------------------------
3148 Anti-affinity or affinity rules are supported using normal OpenStack
3149 *“OS::Nova::ServerGroup”* resources. Separate ServerGroups are typically
3150 created for each VM type to prevent them from residing on the same host,
3151 but they can be applied to multiple VM types to extend the
3152 affinity/anti-affinity across related VM types as well.
3156 In this example, the {network-role} has been defined as “oam” to
3157 represent an oam network and the {vm-type} have been defined as “lb” for
3158 load balancer and “db” for database.
3160 .. code-block:: python
3164 type: OS::Nova::ServerGroup
3169 $vnf\_name: {get\_param: vnf\_name}
3170 template: $vnf\_name-server\_group1
3175 type: OS::Nova::ServerGroup
3180 $vnf\_name: {get\_param: vnf\_name}
3181 template: $vnf\_name-server\_group2
3186 *type: OS::Nova::Server*
3190 group: {get\_param: db\_server\_group}
3193 type: OS::Nova::Server
3197 group: {get\_param: db\_server\_group}
3200 type: OS::Nova::Server
3204 group: {get\_param: lb\_server\_group}
Code Review / vnfrqts / requirements.git / blob