diff options
| author |   Bozawglanian, Hagop (hb755d) <hb755d@att.com> | 2018-07-26 19:41:23 +0000 |
|---|---|---|
| committer | Bozawglanian, Hagop (hb755d) <hb755d@att.com> | 2018-07-26 22:03:18 +0000 |
| commit | ddd21ab3b6b5b8762d6b0504ec666c1d148ce70a (patch) | |
| tree | fdd3b9c716675fd15727e8381d219be5858d1a3a | |
| parent | 59330ac9f35ad76ab76904df305562ce56535c4e (diff) | |
VNFRQTS - Updating links in Beijing
Updating the links and formatting of beijing.
Change-Id: I48d79636cb9d3d8eb708fff635c2efee8023f2b9
Issue-ID: VNFRQTS-266
Signed-off-by: Bozawglanian, Hagop (hb755d) <hb755d@att.com>
| -rw-r--r-- | docs/Chapter1.rst | 11 | ||||
| -rw-r--r-- | docs/Chapter2.rst | 2 | ||||
| -rw-r--r-- | docs/Chapter3.rst | 2 | ||||
| -rw-r--r-- | docs/Chapter4.rst | 64 | ||||
| -rw-r--r-- | docs/Chapter5.rst | 1006 | ||||
| -rw-r--r-- | docs/Chapter6.rst | 2 | ||||
| -rw-r--r-- | docs/Chapter7.rst | 196 | ||||
| -rw-r--r-- | docs/Chapter8.rst | 1334 | ||||
| -rw-r--r-- | docs/release-notes.rst | 7 |
9 files changed, 1339 insertions, 1285 deletions
diff --git a/docs/Chapter1.rst b/docs/Chapter1.rst index 4451c1d..f867024 100644 --- a/docs/Chapter1.rst +++ b/docs/Chapter1.rst @@ -9,16 +9,15 @@ Purpose practices which will increase innovation, minimize customization needed to onboard xNFs as well as reduce implementation complexity, time and cost for all impacted stakeholders. -- This initial release consolidates the requirements from Open-O and OpenECOMP - to provide common xNF requirements across the industry in order to drive - interoperability, simplify management, and reduce cost to build, deploy and - manage xNFs. +- The consolidated the requirements provide common xNF requirements across + the industry in order to drive interoperability, simplify management, and reduce + cost to build, deploy and manage xNFs. - These requirements serve multiple purposes: - Primarily it provides a detailed list of requirements for xNF providers to meet to be compatible with ONAP; xNF providers will use - the xNF requirements to build VNFs/PNFs that are compatible with ONAP + the xNF requirements to build VNFs/PNFs that are compatible with ONAP. - It can also serve as a list of requirements that service providers can - use in RFPs for selecting VNFs/PNFs + use in RFPs for selecting VNFs/PNFs. - It will also be used as a basis for testing and certification of xNFs for compliance with ONAP; ONAP projects such as the VNF Validation Project will uses these xNFs requirements to build test diff --git a/docs/Chapter2.rst b/docs/Chapter2.rst index c33c5c5..1da407d 100644 --- a/docs/Chapter2.rst +++ b/docs/Chapter2.rst @@ -13,7 +13,7 @@ Scope - Requirements that are not applicable to xNF providers such as those that applicable to service providers are not included in this document. - These requirements are applicable to the current release of ONAP. -- Scope of the ONAP versions/release and future functionality +- Scope of the ONAP versions/release and future functionality. - The VNF Requirements should include support for the functionality of the ONAP E-E use cases. - These requirements apply to xNFs at both ONAP Design-Time and ONAP Run-Time. diff --git a/docs/Chapter3.rst b/docs/Chapter3.rst index a018721..9a8f3e3 100644 --- a/docs/Chapter3.rst +++ b/docs/Chapter3.rst @@ -6,8 +6,6 @@ Introduction ============ - These requirements are specific to the current release of ONAP. - It is the initial release of requirements based on a merge of the Open-O - and OpenECOMP requirements. - Requirements are identified as either MUST, MUST NOT, SHOULD, SHOULD NOT, or MAY as defined in RFC 2119. - Requirements should be targeted to a restricted set of nouns related diff --git a/docs/Chapter4.rst b/docs/Chapter4.rst index 89df784..2100725 100644 --- a/docs/Chapter4.rst +++ b/docs/Chapter4.rst @@ -24,7 +24,7 @@ grouping functions in a common cloud data center to minimize inter-component latency. The VNFs should be designed with a goal of being modular and reusable to enable using best-in-breed vendors. -Section 5.a VNF Design in *VNF Guidelines* describes +Section 4.1 VNF Design in *VNF Guidelines* describes the overall guidelines for designing VNFs from VNF Components (VNFCs). Below are more detailed requirements for composing VNFs. @@ -63,7 +63,7 @@ VNF Design Requirements * R-88199 The VNF **MUST** utilize a persistent datastore service that can meet the data performance/latency requirements. (For example: Datastore service could be a VNFC in VNF or a DBaaS in the Cloud - execution environment) + execution environment). * R-99656 The VNF **MUST** NOT terminate stable sessions if a VNFC instance fails. * R-84473 The VNF **MUST** enable DPDK in the guest OS for VNF’s requiring @@ -95,7 +95,7 @@ Network Cloud, resiliency must be designed into the VNF software to provide high availability versus relying on the Network Cloud to achieve that end. -Section 5.a Resiliency in *VNF Guidelines* describes +Section 4.2 Resiliency in *VNF Guidelines* describes the overall guidelines for designing VNFs to meet resiliency goals. Below are more detailed resiliency requirements for VNFs. @@ -390,7 +390,7 @@ to all VNFs. Additional security requirements for specific types of VNFs will be applicable and are outside the scope of these general requirements. -Section 5.a Security in *VNF Guidelines* outlines +Section 4.3 Security in *VNF Guidelines* outlines the five broad security areas for VNFs that are detailed in the following sections: @@ -773,12 +773,12 @@ Security Analytics Requirements * R-22286 The VNF **MUST** support Integration functionality via API/Syslog/SNMP to other functional modules in the network (e.g., PCRF, PCEF) that enable dynamic security control by blocking the - malicious traffic or malicious end users + malicious traffic or malicious end users. * R-32636 The VNF **MUST** support API-based monitoring to take care of the scenarios where the control interfaces are not exposed, or are optimized and proprietary in nature. * R-61648 The VNF **MUST** support event logging, formats, and delivery - tools to provide the required degree of event data to ONAP + tools to provide the required degree of event data to ONAP. * R-22367 The VNF **MUST** support detection of malformed packets due to software misconfiguration or software vulnerability. * R-31961 The VNF **MUST** support integrated DPI/monitoring functionality @@ -829,13 +829,13 @@ Security Analytics Requirements security audit logs. * R-41825 The VNF **MUST** activate security alarms automatically when the following event is detected: configurable number of consecutive - unsuccessful login attempts + unsuccessful login attempts. * R-43332 The VNF **MUST** activate security alarms automatically when the following event is detected: successful modification of critical - system or application files + system or application files. * R-74958 The VNF **MUST** activate security alarms automatically when the following event is detected: unsuccessful attempts to gain permissions - or assume the identity of another user + or assume the identity of another user. * R-15884 The VNF **MUST** include the field “date” in the Security alarms (where applicable and technically feasible). * R-23957 The VNF **MUST** include the field “time” in the Security alarms @@ -1071,7 +1071,7 @@ b. Group all VMs (e.g., VNFCs) of a given type (i.e. {vm-type}) into its own incremental module. That is, the VNF has an incremental module for each {vm-type}. -c. For a given {vm-type} incremental module, the VNF may have +c. For a given {vm-type} incremental module, the VNF may have: i. One incremental module used for both initial turn up and re-used for scaling. This approach is used when the number of VMs @@ -1084,13 +1084,13 @@ c. For a given {vm-type} incremental module, the VNF may have **Option 2: Base VNF with Incremental Growth Modules** -a. Base module contains a complete initial VNF instance +a. Base module contains a complete initial VNF instance. -b. Incremental modules for incremental scaling units +b. Incremental modules for incremental scaling units: - i. May contain VMs of multiple types in logical scaling combinations + i. May contain VMs of multiple types in logical scaling combinations. - ii. May be separated by VM type for multi-dimensional scaling + ii. May be separated by VM type for multi-dimensional scaling. With no growth units, Option 2 is equivalent to the “One Heat Template per VNF” model. @@ -1109,54 +1109,54 @@ There are some rules to follow when building modular VNF templates: first one deployed. The base template: a. Must include all shared resources (e.g., private networks, server - groups, security groups) + groups, security groups). b. Must expose all shared resources (by UUID) as “outputs” in its associated Heat template (i.e., ONAP Base Module Output - Parameters) + Parameters). - c. May include initial set of VMs + c. May include initial set of VMs. d. May be operational as a stand-alone “minimum” configuration of the - VNF + VNF. 2. VNFs may have one or more incremental modules which: - a. Defines additional resources that can be added to an existing VNF + a. Defines additional resources that can be added to an existing VNF. - b. Must be complete Heat templates + b. Must be complete Heat templates. - i. i.e. not snippets to be incorporated into some larger template + i. i.e. not snippets to be incorporated into some larger template. c. Should define logical growth-units or sub-components of an overall - VNF + VNF. d. On creation, receives appropriate Base Module outputs as - parameters + parameters. - i. Provides access to all shared resources (by UUID) + i. Provides access to all shared resources (by UUID). - ii. must not be dependent on other Add-On VNF Modules + ii. must not be dependent on other Add-On VNF Modules. e. Multiple instances of an incremental Module may be added to the same VNF (e.g., incrementally grow a VNF by a fixed “add-on” - growth units) + growth units). 3. Each VNF Module (base or incremental) may have (optional) an - associated Cinder Volume Module (see Cinder Volume Templates) + associated Cinder Volume Module (see Cinder Volume Templates): a. Volume modules must correspond 1:1 with a base module or - incremental module + incremental module. b. A Cinder volume may be embedded within the base module or - incremental module if persistence is not required + incremental module if persistence is not required. 4. Shared resource UUIDs are passed between the base module and incremental modules via Heat Outputs Parameters (i.e., Base Module - Output Parameters) + Output Parameters): a. The output parameter name in the base must match the parameter - name in the add-on module + name in the add-on module. VNF Modularity Examples ^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -1300,7 +1300,7 @@ software bundle, VNF suppliers using standard images would typically provide the NCSP with an install package consistent with the default OS package manager (e.g. aptitude for Ubuntu, yum for Redhat/CentOS). -Section 5.a DevOps in *VNF Guidelines* describes +Section 4.5 DevOps in *VNF Guidelines* describes the DevOps guidelines for VNFs. DevOps Requirements diff --git a/docs/Chapter5.rst b/docs/Chapter5.rst index 8496360..1e82930 100644 --- a/docs/Chapter5.rst +++ b/docs/Chapter5.rst @@ -188,6 +188,7 @@ changes from ETSI SOL001 draft. +====================================================================+ +--------------------------------------------------------------------+ + HPA Requirements ^^^^^^^^^^^^^^^^^^ @@ -196,67 +197,67 @@ HPA Requirements Definitions of SRIOV\_Port are necessary if VDU supports SR-IOV. Here is an example. -+------------------------------------------------+ -| node\_templates: | -| | -| vdu\_vNat: | -| | -| SRIOV\_Port: | -| | -| attributes: | -| | -| tosca\_name: SRIOV\_Port | -| | -| properties: | -| | -| virtual\_network\_interface\_requirements: | -| | -| - name: sriov | -| | -| support\_mandatory: false | -| | -| description: sriov | -| | -| requirement: | -| | -| SRIOV: true | -| | -| role: root | -| | -| description: sriov port | -| | -| layer\_protocol: ipv4 | -| | -| requirements: | -| | -| - virtual\_binding: | -| | -| capability: virtual\_binding | -| | -| node: vdu\_vNat | -| | -| relationship: | -| | -| type: tosca.relationships.nfv.VirtualBindsTo | -| | -| - virtual\_link: | -| | -| node: tosca.nodes.Root | -| | -| type: tosca.nodes.nfv.VduCpd | -| | -| substitution\_mappings: | -| | -| requirements: | -| | -| sriov\_plane: | -| | -| - SRIOV\_Port | -| | -| - virtual\_link | -| | -| node\_type: tosca.nodes.nfv.VNF.vOpenNAT | -+------------------------------------------------+ +.. code-block:: yaml + + node\_templates: + + vdu\_vNat: + + SRIOV\_Port: + + attributes: + + tosca\_name: SRIOV\_Port + + properties: + + virtual\_network\_interface\_requirements: + + - name: sriov + + support\_mandatory: false + + description: sriov + + requirement: + + SRIOV: true + + role: root + + description: sriov port + + layer\_protocol: ipv4 + + requirements: + + - virtual\_binding: + + capability: virtual\_binding + + node: vdu\_vNat + + relationship: + + type: tosca.relationships.nfv.VirtualBindsTo + + - virtual\_link: + + node: tosca.nodes.Root + + type: tosca.nodes.nfv.VduCpd + + substitution\_mappings: + + requirements: + + sriov\_plane: + + - SRIOV\_Port + + - virtual\_link + + node\_type: tosca.nodes.nfv.VNF.vOpenNAT 2. Hugepages @@ -264,22 +265,22 @@ Definitions of mem\_page\_size as one property shall be added to Properties and set the value to large if one VDU node supports huagepages. Here is an example. -+----------------------------------+ -| node\_templates: | -| | -| vdu\_vNat: | -| | -| Hugepages: | -| | -| attributes: | -| | -| tosca\_name: Huge\_pages\_demo | -| | -| properties: | -| | -| mem\_page\_size:large | -+==================================+ -+----------------------------------+ +.. code-block:: yaml + + node\_templates: + + vdu\_vNat: + + Hugepages: + + attributes: + + tosca\_name: Huge\_pages\_demo + + properties: + + mem\_page\_size:large + 3. NUMA (CPU/Mem) @@ -287,45 +288,47 @@ Likewise, we shall add definitions of numa to requested\_additional\_capabilities if we wand VUD nodes to support NUMA. Here is an example. -+-------------------------------------------------+ -| topology\_template: | -| | -| node\_templates: | -| | -| vdu\_vNat: | -| | -| capabilities: | -| | -| virtual\_compute: | -| | -| properties: | -| | -| virtual\_memory: | -| | -| numa\_enabled: true | -| | -| virtual\_mem\_size: 2 GB | -| | -| requested\_additional\_capabilities: | -| | -| numa: | -| | -| support\_mandatory: true | -| | -| requested\_additional\_capability\_name: numa | -| | -| target\_performance\_parameters: | -| | -| hw:numa\_nodes: "2" | -| | -| hw:numa\_cpus.0: "0,1" | -| | -| hw:numa\_mem.0: "1024" | -| | -| hw:numa\_cpus.1: "2,3,4,5" | -| | -| hw:numa\_mem.1: "1024" | -+-------------------------------------------------+ + +.. code-block:: yaml + + topology\_template: + + node\_templates: + + vdu\_vNat: + + capabilities: + + virtual\_compute: + + properties: + + virtual\_memory: + + numa\_enabled: true + + virtual\_mem\_size: 2 GB + + requested\_additional\_capabilities: + + numa: + + support\_mandatory: true + + requested\_additional\_capability\_name: numa + + target\_performance\_parameters: + + hw:numa\_nodes: "2" + + hw:numa\_cpus.0: "0,1" + + hw:numa\_mem.0: "1024" + + hw:numa\_cpus.1: "2,3,4,5" + + hw:numa\_mem.1: "1024" + 4. Hyper-Theading @@ -333,43 +336,44 @@ Definitions of Hyper-Theading are necessary as one of requested\_additional\_capabilities of one VUD node if that node supports Hyper-Theading. Here is an example. -+-------------------------------------------------------------+ -| topology\_template: | -| | -| node\_templates: | -| | -| vdu\_vNat: | -| | -| capabilities: | -| | -| virtual\_compute: | -| | -| properties: | -| | -| virtual\_memory: | -| | -| numa\_enabled: true | -| | -| virtual\_mem\_size: 2 GB | -| | -| requested\_additional\_capabilities: | -| | -| hyper\_threading: | -| | -| support\_mandatory: true | -| | -| requested\_additional\_capability\_name: hyper\_threading | -| | -| target\_performance\_parameters: | -| | -| hw:cpu\_sockets : "2" | -| | -| hw:cpu\_threads : "2" | -| | -| hw:cpu\_cores : "2" | -| | -| hw:cpu\_threads\_policy: "isolate" | -+-------------------------------------------------------------+ +.. code-block:: yaml + + topology\_template: + + node\_templates: + + vdu\_vNat: + + capabilities: + + virtual\_compute: + + properties: + + virtual\_memory: + + numa\_enabled: true + + virtual\_mem\_size: 2 GB + + requested\_additional\_capabilities: + + hyper\_threading: + + support\_mandatory: true + + requested\_additional\_capability\_name: hyper\_threading + + target\_performance\_parameters: + + hw:cpu\_sockets : "2" + + hw:cpu\_threads : "2" + + hw:cpu\_cores : "2" + + hw:cpu\_threads\_policy: "isolate" + 5. OVS+DPDK @@ -377,37 +381,38 @@ Definitions of ovs\_dpdk are necessary as one of requested\_additional\_capabilities of one VUD node if that node supports dpdk. Here is an example. -+------------------------------------------------------+ -| topology\_template: | -| | -| node\_templates: | -| | -| vdu\_vNat: | -| | -| capabilities: | -| | -| virtual\_compute: | -| | -| properties: | -| | -| virtual\_memory: | -| | -| numa\_enabled: true | -| | -| virtual\_mem\_size: 2 GB | -| | -| requested\_additional\_capabilities: | -| | -| ovs\_dpdk: | -| | -| support\_mandatory: true | -| | -| requested\_additional\_capability\_name: ovs\_dpdk | -| | -| target\_performance\_parameters: | -| | -| sw:ovs\_dpdk: "true" | -+------------------------------------------------------+ +.. code-block:: yaml + + topology\_template: + + node\_templates: + + vdu\_vNat: + + capabilities: + + virtual\_compute: + + properties: + + virtual\_memory: + + numa\_enabled: true + + virtual\_mem\_size: 2 GB + + requested\_additional\_capabilities: + + ovs\_dpdk: + + support\_mandatory: true + + requested\_additional\_capability\_name: ovs\_dpdk + + target\_performance\_parameters: + + sw:ovs\_dpdk: "true" + NFV TOSCA Type Definition ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -472,148 +477,149 @@ Capabilities | | capability type | | | +------------+--------------------+------------+------------------------------+ + Definition ++++++++++++ -+-----------------------------------------------------------------------------+ -| tosca.nodes.nfv.VDU.Compute: | -| | -| derived\_from: tosca.nodes.Compute | -| | -| properties: | -| | -| name: | -| | -| type: string | -| | -| required: true | -| | -| description: | -| | -| type: string | -| | -| required: true | -| | -| boot\_order: | -| | -| type: list # explicit index (boot index) not necessary, contrary to IFA011 | -| | -| entry\_schema: | -| | -| type: string | -| | -| required: false | -| | -| nfvi\_constraints: | -| | -| type: list | -| | -| entry\_schema: | -| | -| type: string | -| | -| required: false | -| | -| configurable\_properties: | -| | -| type: map | -| | -| entry\_schema: | -| | -| type: tosca.datatypes.nfv.VnfcConfigurableProperties | -| | -| required: true | -| | -| attributes: | -| | -| private\_address: | -| | -| status: deprecated | -| | -| public\_address: | -| | -| status: deprecated | -| | -| networks: | -| | -| status: deprecated | -| | -| ports: | -| | -| status: deprecated | -| | -| capabilities: | -| | -| virtual\_compute: | -| | -| type: tosca.capabilities.nfv.VirtualCompute | -| | -| virtual\_binding: | -| | -| type: tosca.capabilities.nfv.VirtualBindable | -| | -| #monitoring\_parameter: | -| | -| # modeled as ad hoc (named) capabilities in VDU node template | -| | -| # for example: | -| | -| #capabilities: | -| | -| # cpu\_load: tosca.capabilities.nfv.Metric | -| | -| # memory\_usage: tosca.capabilities.nfv.Metric | -| | -| host: #Editor note: FFS. How this capabilities should be used in NFV Profile| -| | -| type: `*tosca.capabilities.Container* <#DEFN_TYPE_CAPABILITIES_CONTAINER>`__| -| | -| valid\_source\_types: | -| [`*tosca.nodes.SoftwareComponent* <#DEFN_TYPE_NODES_SOFTWARE_COMPONENT>`__] | -| | -| occurrences: [0,UNBOUNDED] | -| | -| endpoint: | -| | -| occurrences: [0,0] | -| | -| os: | -| | -| occurrences: [0,0] | -| | -| scalable: | -| #Editor note: FFS. How this capabilities should be used in NFV Profile | -| | -| type: `*tosca.capabilities.Scalable* <#DEFN_TYPE_CAPABILITIES_SCALABLE>`__ | -| | -| binding: | -| | -| occurrences: [0,UNBOUND] | -| | -| requirements: | -| | -| - virtual\_storage: | -| | -| capability: tosca.capabilities.nfv.VirtualStorage | -| | -| relationship: tosca.relationships.nfv.VDU.AttachedTo | -| | -| node: tosca.nodes.nfv.VDU.VirtualStorage | -| | -| occurences: [ 0, UNBOUNDED ] | -| | -| - local\_storage: #For NFV Profile, this requirement is deprecated. | -| | -| occurrences: [0,0] | -| | -| artifacts: | -| | -| - sw\_image: | -| | -| file: | -| | -| type: tosca.artifacts.nfv.SwImage | -+-----------------------------------------------------------------------------+ +.. code-block:: yaml + + tosca.nodes.nfv.VDU.Compute: + + derived\_from: tosca.nodes.Compute + + properties: + + name: + + type: string + + required: true + + description: + + type: string + + required: true + + boot\_order: + + type: list # explicit index (boot index) not necessary, contrary to IFA011 + + entry\_schema: + + type: string + + required: false + + nfvi\_constraints: + + type: list + + entry\_schema: + + type: string + + required: false + + configurable\_properties: + + type: map + + entry\_schema: + + type: tosca.datatypes.nfv.VnfcConfigurableProperties + + required: true + + attributes: + + private\_address: + + status: deprecated + + public\_address: + + status: deprecated + + networks: + + status: deprecated + + ports: + + status: deprecated + + capabilities: + + virtual\_compute: + + type: tosca.capabilities.nfv.VirtualCompute + + virtual\_binding: + + type: tosca.capabilities.nfv.VirtualBindable + + #monitoring\_parameter: + + # modeled as ad hoc (named) capabilities in VDU node template + + # for example: + + #capabilities: + + # cpu\_load: tosca.capabilities.nfv.Metric + + # memory\_usage: tosca.capabilities.nfv.Metric + + host: #Editor note: FFS. How this capabilities should be used in NFV Profile| + + type: *tosca.capabilities.Container* + + valid\_source\_types: [*tosca.nodes.SoftwareComponent*] + + occurrences: [0,UNBOUNDED] + + endpoint: + + occurrences: [0,0] + + os: + + occurrences: [0,0] + + scalable: + #Editor note: FFS. How this capabilities should be used in NFV Profile + + type: *tosca.capabilities.Scalable* + + binding: + + occurrences: [0,UNBOUND] + + requirements: + + - virtual\_storage: + + capability: tosca.capabilities.nfv.VirtualStorage + + relationship: tosca.relationships.nfv.VDU.AttachedTo + + node: tosca.nodes.nfv.VDU.VirtualStorage + + occurences: [ 0, UNBOUNDED ] + + - local\_storage: #For NFV Profile, this requirement is deprecated. + + occurrences: [0,0] + + artifacts: + + - sw\_image: + + file: + + type: tosca.artifacts.nfv.SwImage + Artifact ++++++++++ @@ -633,7 +639,6 @@ Note: currently not supported. |image2| - tosca.nodes.nfv.VDU.VirtualStorage ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -724,99 +729,101 @@ Properties | | | | | with this software image| +-----------------+---------+----------+------------+-------------------------+ + Definition +++++++++++ -+-----------------------------------------------------+ -| tosca.artifacts.nfv.SwImage: | -| | -| derived\_from: tosca.artifacts.Deployment.Image | -| | -| properties or metadata: | -| | -| #id: | -| | -| # node name | -| | -| name: | -| | -| type: string | -| | -| required: true | -| | -| version: | -| | -| type: string | -| | -| required: true | -| | -| checksum: | -| | -| type: string | -| | -| required: true | -| | -| container\_format: | -| | -| type: string | -| | -| required: true | -| | -| disk\_format: | -| | -| type: string | -| | -| required: true | -| | -| min\_disk: | -| | -| type: scalar-unit.size # Number | -| | -| required: true | -| | -| min\_ram: | -| | -| type: scalar-unit.size # Number | -| | -| required: false | -| | -| size: | -| | -| type: scalar-unit.size # Number | -| | -| required: true | -| | -| sw\_image: | -| | -| type: string | -| | -| required: true | -| | -| operating\_system: | -| | -| type: string | -| | -| required: false | -| | -| supported\_virtualisation\_environments: | -| | -| type: list | -| | -| entry\_schema: | -| | -| type: string | -| | -| required: false | -+-----------------------------------------------------+ +.. code-block:: yaml + + tosca.artifacts.nfv.SwImage: + + derived\_from: tosca.artifacts.Deployment.Image + + properties or metadata: + + #id: + + # node name + + name: + + type: string + + required: true + + version: + + type: string + + required: true + + checksum: + + type: string + + required: true + + container\_format: + + type: string + + required: true + + disk\_format: + + type: string + + required: true + + min\_disk: + + type: scalar-unit.size # Number + + required: true + + min\_ram: + + type: scalar-unit.size # Number + + required: false + + size: + + type: scalar-unit.size # Number + + required: true + + sw\_image: + + type: string + + required: true + + operating\_system: + + type: string + + required: false + + supported\_virtualisation\_environments: + + type: list + + entry\_schema: + + type: string + + required: false + .. |image1| image:: Image1.png :width: 5.76806in :height: 4.67161in + .. |image2| image:: Image2.png :width: 5.40486in :height: 2.46042in - Heat ------------- @@ -991,7 +998,7 @@ hidden ______ R-32557 A VNF's Heat Orchestration Template parameter -declaration MAY contain the attribute "hidden:". +declaration **MAY** contain the attribute "hidden:". The parameter attribute "hidden:" is an OpenStack optional attribute that defines whether the parameters should be @@ -1271,7 +1278,7 @@ R-36982 A VNF’s Heat Orchestration template **MAY** contain the “outputs:” This section allows for specifying output parameters available to users once the template has been instantiated. If the section is specified, it will need to adhere to specific requirements. -See `ONAP Parameter Classifications Overview`_ and +See `Output Parameters`_ and `ONAP Output Parameter Names`_ for additional details. Environment File Format @@ -1341,7 +1348,7 @@ created. ONAP has requirements for what parameters must be enumerated in the environment file and what parameter must not be enumerated in the -environment file. See `ONAP Parameter Classifications Overview`_ and +environment file. See `Output Parameters`_ and `ONAP Resource ID and Parameter Naming Convention`_ for more details. ONAP Heat Orchestration Templates: Overview @@ -2266,7 +2273,7 @@ convention. The four properties are: Requirement R-01455 defines how the ‘{vm-type]’ is defined. -Requirement R-82481 defines how the ‘{vm-type} is used.’ +Requirement R-82481 defines how the ‘{vm-type}’ is used. The table below provides a summary. The sections that follow provides the detailed requirements. @@ -2450,9 +2457,10 @@ In this example, the {vm-type} has been defined as “lb” for load balancer. Contrail Issue with Values for OS::Nova::Server Property Name _____________________________________________________________ -R-44271 The VNF's Heat Orchestration Template's Resource 'OS::Nova::Server' property -'name' parameter value **SHOULD NOT** contain special characters -since the Contrail GUI has a limitation displaying special characters. +R-44271 The VNF's Heat Orchestration Template's Resource +'OS::Nova::Server' property 'name' parameter value **SHOULD NOT** +contain special characters since the Contrail GUI has a limitation +displaying special characters. However, if special characters must be used, the only special characters supported are: @@ -2617,10 +2625,9 @@ associated with these two properties: Resource: OS::Nova::Server – Metadata Parameters ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The OS::Nova::Server Resource property metadata is an optional -OpenStack property. -The table below summarizes the mandatory and optional metadata -supported by ONAP. +The OS::Nova::Server Resource property metadata is an +optional OpenStack property. The table below summarizes the +mandatory and optional metadata supported by ONAP. The sections that follow provides the requirements associated with each metadata parameter. @@ -2822,7 +2829,7 @@ parameter contraints defined. R-46823 A VNF’s Heat Orchestration Template’s OS::Nova::Server Resource metadata map value parameter ‘vnf_name’ **MUST** be -either +either: - enumerated in the VNF’s Heat Orchestration Template’s environment file. @@ -3153,7 +3160,9 @@ ONAP parameter naming convention. The four properties are: 1. network 2. fixed_ips, ip_address 3. fixed_ips, subnet_id or fixed_ips, subnet + * Note that in many examples in this document fixed_ips, subnet_id is used. + 4. allowed_address_pairs, ip_address Below is a generic example. Note that for some parameters @@ -3216,33 +3225,38 @@ different subnets and the IPv6 Addresses **MAY** be from different subnets. If a VNF's Port is attached to an external network the IP addresses **MAY** -either be assigned by +either be assigned by: + 1. ONAP's SDN-Controller (SDN-C) 2. Cloud Assigned by OpenStack’s DHCP Service If a VNF's Port is attached to an external network and the port's IP addresses -are assigned by ONAP's SDN-Controller, the 'OS::Neutron::Port' Resource's +are assigned by ONAP's SDN-Controller, the 'OS::Neutron::Port' Resource's: + * property 'fixed_ips' map property 'ip_address' **MUST** be used * property 'fixed_ips' map property 'subnet'/'subnet_id' **MUST NOT** be used If a VNF's Port is attached to an external network and the port's IP addresses are Cloud Assigned by OpenStack’s DHCP Service, -the 'OS::Neutron::Port' Resource's +the 'OS::Neutron::Port' Resource's: + * property 'fixed_ips' map property 'ip_address' **MUST NOT** be used * property fixed_ips' map property 'subnet'/'subnet_id' **MAY** be used If a VNF's Port is attached to an internal network and the port's IP addresses are assigned by the VNF's Heat Orchestration Template (i.e., enumerated in the Heat Orchestration Template's environment file), -the 'OS::Neutron::Port' Resource's +the 'OS::Neutron::Port' Resource's: + * property 'fixed_ips' map property 'ip_address' **MUST** be used * property 'fixed_ips' map property 'subnet'/'subnet_id' **MUST NOT** be used If a VNF's Port is attached to an internal network and the port's IP addresses are Cloud Assigned by OpenStack’s DHCP Service, -the 'OS::Neutron::Port' Resource's +the 'OS::Neutron::Port' Resource's: + * property 'fixed_ips' map property 'ip_address' **MUST NOT** be used * property 'fixed_ips' map property 'subnet'/'subnet_id' **MAY** be used @@ -3267,15 +3281,16 @@ be specified. Property: network +++++++++++++++++ -The Resource 'OS::Neutron::Port' property 'network' determines what network -the port is attached to. +The Resource 'OS::Neutron::Port' property 'network' determines what +network the port is attached to. R-18008 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ property ‘network’ parameter **MUST** be declared as type: ‘string’. -R-62983 When the VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ -is attaching to an external network, the ‘network’ parameter name **MUST** +R-62983 When the VNF’s Heat Orchestration Template’s +Resource ‘OS::Neutron::Port’ is attaching to an external +network, the ‘network’ parameter name **MUST**: - follow the naming convention ‘{network-role}_net_id’ if the Neutron network UUID value is used to reference the network @@ -3285,17 +3300,19 @@ is attaching to an external network, the ‘network’ parameter name **MUST** where ‘{network-role}’ is the network-role of the external network and a ‘get_param’ **MUST** be used as the intrinsic function. -R-86182 When the VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ -is attaching to an internal network, and the internal network is created in a different +R-86182 When the VNF’s Heat Orchestration Template’s +Resource ‘OS::Neutron::Port’ is attaching to an internal network, +and the internal network is created in a different Heat Orchestration Template than the ‘OS::Neutron::Port’, the ‘network’ -parameter name **MUST** +parameter name **MUST**: - follow the naming convention ‘int\_{network-role}_net_id’ if the Neutron network UUID value is used to reference the network - follow the naming convention ‘int\_{network-role}_net_name’ if the OpenStack network name in is used to reference the network. -where ‘{network-role}’ is the network-role of the internal network and a ‘get_param’ **MUST** be used as the intrinsic function. +where ‘{network-role}’ is the network-role of the internal network +and a ‘get_param’ **MUST** be used as the intrinsic function. In Requirement R-86182, the internal network is created in the VNF's Base Module (Heat Orchestration Template) and the parameter name is @@ -3303,8 +3320,9 @@ declared in the Base Module's outputs' section. The output parameter name will be declared as a parameter in the 'parameters' section of the incremental module. -R-93177 When the VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ -is attaching to an internal network, and the internal network is created in the same Heat +R-93177 When the VNF’s Heat Orchestration Template’s +Resource ‘OS::Neutron::Port’ is attaching to an internal network, +and the internal network is created in the same Heat Orchestration Template than the ‘OS::Neutron::Port’, the ‘network’ parameter name **MUST** obtain the UUID of the internal network by using the intrinsic function ‘get_resource’ or ‘get_attr’ and referencing the @@ -3363,15 +3381,15 @@ One 'OS::Neutron::Port' resource may assign one or more IPv4 and/or IPv6 addresses. R-34037 The VNF’s Heat Orchestration Template’s resource ‘OS::Neutron::Port’ -property ‘fixed_ips’ map property ‘ip_address’ parameter **MUST** be declared as -either type ‘string’ or type ‘comma_delimited_list’. +property ‘fixed_ips’ map property ‘ip_address’ parameter **MUST** +be declared as either type ‘string’ or type ‘comma_delimited_list’. R-40971 When the VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ is attaching to an external network, and an IPv4 address is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and the parameter type is defined as a string, the parameter name **MUST** follow the naming -convention ‘{vm-type}_{network-role}\_ip\_{index}’, where +convention ‘{vm-type}_{network-role}\_ip\_{index}’, where: - ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server - ‘{network-role}’ is the {network-role} of the external network @@ -3395,11 +3413,12 @@ the value at orchestration to the Heat Orchestration Template. type: string description: Fixed IPv4 assignment for {vm-type} VM {index} on the{network-role} network -R-04697 When the VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ -is attaching to an external network, and an IPv4 address is assigned using -the property ‘fixed_ips’ map property ‘ip_address’ and the parameter type -is defined as a comma_delimited_list, the parameter name **MUST** follow the -naming convention ‘{vm-type}_{network-role}_ips’, where +R-04697 When the VNF’s Heat Orchestration Template’s +Resource ‘OS::Neutron::Port’ is attaching to an external network, +and an IPv4 address is assigned using the property ‘fixed_ips’ +map property ‘ip_address’ and the parameter type is defined as +a comma_delimited_list, the parameter name **MUST** follow the +naming convention ‘{vm-type}_{network-role}_ips’, where: - ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server - ‘{network-role}’ is the {network-role} of the external network @@ -3427,7 +3446,7 @@ R-71577 When the VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ is attaching to an external network, and an IPv6 address is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and the parameter type is defined as a string, the parameter name **MUST** follow -the naming convention ‘{vm-type}_{network-role}\_v6\_ip\_{index}’, where +the naming convention ‘{vm-type}_{network-role}\_v6\_ip\_{index}’, where: - ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server - ‘{network-role}’ is the {network-role} of the external network @@ -3436,8 +3455,9 @@ the naming convention ‘{vm-type}_{network-role}\_v6\_ip\_{index}’, where R-87123 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’ -parameter ‘{vm-type}_{network-role}\_v6\_ip\_{index}’ **MUST NOT** be enumerated -in the VNF’s Heat Orchestration Template’s Environment File. +parameter ‘{vm-type}_{network-role}\_v6\_ip\_{index}’ +**MUST NOT** be enumerated in the VNF’s Heat Orchestration +Template’s Environment File. ONAP's SDN-Controller assigns the IP Address and ONAP provides the value at orchestration to the Heat Orchestration Template. @@ -3456,7 +3476,8 @@ R-23503 When the VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ is attaching to an external network, and an IPv6 address is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and the parameter type is defined as a comma_delimited_list, the parameter -name **MUST** follow the naming convention ‘{vm-type}_{network-role}_v6_ips’, where +name **MUST** follow the naming convention +‘{vm-type}_{network-role}_v6_ips’, where: - ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server - ‘{network-role}’ is the {network-role} of the external network @@ -3484,7 +3505,7 @@ R-78380 When the VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ is attaching to an internal network, and an IPv4 address is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and the parameter type is defined as a string, the parameter name **MUST** follow -the naming convention ‘{vm-type}\_int\_{network-role}\_ip\_{index}’, where +the naming convention ‘{vm-type}\_int\_{network-role}\_ip\_{index}’, where: - ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server - ‘{network-role}’ is the {network-role} of the internal network @@ -3513,7 +3534,8 @@ R-85235 When the VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ is attaching to an internal network, and an IPv4 address is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and the parameter type is defined as a comma_delimited_list, the parameter -name **MUST** follow the naming convention ‘{vm-type}\_int\_{network-role}_ips’, where +name **MUST** follow the naming convention +‘{vm-type}\_int\_{network-role}_ips’, where: - ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server - ‘{network-role}’ is the {network-role} of the internal network @@ -3539,7 +3561,7 @@ R-27818 When the VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ is attaching to an internal network, and an IPv6 address is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and the parameter type is defined as a string, the parameter name **MUST** follow -the naming convention ‘{vm-type}\_int\_{network-role}\_v6\_ip\_{index}’, where +the naming convention ‘{vm-type}\_int\_{network-role}\_v6\_ip\_{index}’, where: - ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server - ‘{network-role}’ is the {network-role} of the internal network @@ -3547,7 +3569,8 @@ the naming convention ‘{vm-type}\_int\_{network-role}\_v6\_ip\_{index}’, whe R-97201 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’ -parameter ‘{vm-type}\_int\_{network-role}\_v6\_ip\_{index}’ **MUST** be enumerated +parameter ‘{vm-type}\_int\_{network-role}\_v6\_ip\_{index}’ +**MUST** be enumerated in the VNF’s Heat Orchestration Template’s Environment File. The IP address is local to the VNF's internal network and is (re)used @@ -3568,7 +3591,8 @@ R-29765 When the VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ is attaching to an internal network, and an IPv6 address is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and the parameter type is defined as a comma_delimited_list, the parameter -name **MUST** follow the naming convention ‘{vm-type}\_int\_{network-role}_v6_ips’, where +name **MUST** follow the naming convention +‘{vm-type}\_int\_{network-role}_v6_ips’, where: - ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server - ‘{network-role}’ is the {network-role} of the internal network @@ -3602,8 +3626,9 @@ parameter associated with an external network, i.e., - {vm-type}_{network-role}_ips - {vm-type}_{network-role}_v6_ips -**MUST NOT** be enumerated in the Heat Orchestration Template’s Environment File. -ONAP provides the IP address assignments at orchestration time. +**MUST NOT** be enumerated in the Heat Orchestration Template’s +Environment File. ONAP provides the IP address assignments at +orchestration time. R-93496 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’ @@ -3933,7 +3958,7 @@ balancer. - subnet_id: { get_param: oam_subnet_id } - subnet_id: { get_param: oam_v6_subnet_id } -R-84123 When +R-84123 When: - the VNF’s Heat Orchestration Template’s resource ‘OS::Neutron::Port’ in an Incremental Module is attaching to an internal network @@ -3971,7 +3996,7 @@ input parameter. type: string description: Neutron IPv4 subnet UUID for the int_{network-role} network -R-76160 When +R-76160 When: - the VNF’s Heat Orchestration Template’s resource ‘OS::Neutron::Port’ in an Incremental Module is attaching to an @@ -4103,9 +4128,10 @@ an oam network and the {vm-type} has been defined as db for database. Internal Networks _________________ -R-16805 The VNF Heat Orchestration Template **MUST** adhere to the following naming convention -for the property allowed\_address\_pairs and Map Property ip\_address -parameter when the parameter is referencing an “internal” network. +R-16805 The VNF Heat Orchestration Template **MUST** adhere to +the following naming convention for the property allowed\_address\_pairs +and Map Property ip\_address parameter when the parameter is +referencing an “internal” network. - {vm-type}\_int\_{network-role}\_floating\_ip for an IPv4 address @@ -4130,7 +4156,7 @@ The parameter must be enumerated in the Heat environment file. description: VIP for {vm-type} VMs on the int_{network-role} network Multiple allowed\_address\_pairs for a {vm-type} / {network-role} combination -__________________________________________________________________ +______________________________________________________________________________ The parameter {vm-type}\_{network-role}\_floating\_ip provides only one allowed address pair IPv4 address per {vm-type} and {network-role} pair. @@ -4248,23 +4274,23 @@ OS::Nova::Server resources must be defined when the property is used. Not all resources require the property name (e.g., it is optional) and some resources do not support the property. -R-85734 The VNF Heat Orchestration Template **MUST** use the intrinsic function str\_replace -in conjunction with the ONAP supplied metadata parameter -vnf\_name to generate a unique value, +R-85734 The VNF Heat Orchestration Template **MUST** use the +intrinsic function str\_replace in conjunction with the ONAP +supplied metadata parameter vnf\_name to generate a unique value, when the property name for a non OS::Nova::Server resources is defined in a Heat Orchestration Template. This prevents the enumeration of a unique value for the property name in a per instance environment file. -Note that +Note that: - In most cases, only the use of the metadata value vnf\_name is - required to create a unique property name + required to create a unique property name. - the Heat Orchestration Template pseudo parameter 'OS::stack\_name’ may also be used in the str\_replace construct to generate a unique - name when the vnf\_name does not provide uniqueness + name when the vnf\_name does not provide uniqueness. *Example: Property* name *for resource* OS::Neutron::SecurityGroup @@ -4323,7 +4349,7 @@ characters must be used, note that for the following resources: the only special characters supported are: -- “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_ +-- “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_ ONAP Output Parameter Names ~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -4481,7 +4507,7 @@ _________________ When the parameter associated with the Contrail Network is referencing an “external” network, the parameter must adhere to the following naming -convention in the Heat Orchestration Template +convention in the Heat Orchestration Template: - {network-role}\_net\_fqdn @@ -4524,7 +4550,7 @@ virtual\_network\_refs references a contrail network FQDN. - get_param: fw_sec_grp_id Interface Route Table Prefixes for Contrail InterfaceRoute Table -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The parameter associated with the resource OS::ContrailV2::InterfaceRouteTable property @@ -4652,8 +4678,9 @@ module. Use of separate volume modules is optional. A Cinder volume may be embedded within the Base Module or Incremental Module if persistence is not required. -R-47788 The VNF Heat Orchestration Template **MUST** have a 1:1 scope of a cinder volume module, -when it exists, with the Base Module or Incremental Module +R-47788 The VNF Heat Orchestration Template **MUST** have a 1:1 +scope of a cinder volume module, when it exists, with the Base +Module or Incremental Module A single volume module must create only the volumes required by a single Incremental module or Base module. @@ -4666,9 +4693,10 @@ The following rules apply to independent volume Heat templates: - A single Cinder volume module must include all Cinder volumes needed by the Base/Incremental module. -- R-79531 The VNF Heat Orchestration Template **MUST** define “outputs” in the volume - template for each Cinder volume resource universally unique - identifier (UUID) (i.e. ONAP Volume Template Output Parameters). +- R-79531 The VNF Heat Orchestration Template **MUST** define + “outputs” in the volume template for each Cinder volume + resource universally unique identifier (UUID) (i.e. ONAP Volume + Template Output Parameters). - The VNF Incremental Module or Base Module must define input parameters that match each Volume output parameter (i.e., ONAP Volume @@ -4765,8 +4793,8 @@ environment file for a Base Module. R-35727 The VNF Heat Orchestration Template **MUST** have a corresponding environment file for an Incremental module. -R-22656 The VNF Heat Orchestration Template **MUST** have a corresponding environment file -for a Cinder Volume Module. +R-22656 The VNF Heat Orchestration Template **MUST** have a +corresponding environment file for a Cinder Volume Module. A nested heat template must not have an environment file; OpenStack does not support it. @@ -4845,12 +4873,12 @@ Nested heat templates must be referenced by file name. The use of resource\_registry in the environment file is not supported and must not be used. -R-89868 The VNF Heat Orchestration Template **MUST** have unique file names within the scope -of the VNF for a nested heat yaml file. +R-89868 The VNF Heat Orchestration Template **MUST** have unique +file names within the scope of the VNF for a nested heat yaml file. -R-52530 The VNF Heat Orchestration Template **MUST NOT** use a directory hierarchy for -nested templates. All templates must be in a single, flat directory -(per VNF). +R-52530 The VNF Heat Orchestration Template **MUST NOT** use a +directory hierarchy for nested templates. All templates must be +in a single, flat directory (per VNF). A nested heat template may be used by any module within a given VNF. @@ -4859,9 +4887,9 @@ Note that: - Constrains must not be defined for any parameter enumerated in a nested heat template. -- R-11041 The VNF Heat Orchestration Template **MUST** have the resource calling the - nested yaml file pass in as properties all parameters defined - in nested yaml file. +- R-11041 The VNF Heat Orchestration Template **MUST** have the + resource calling the nested yaml file pass in as properties + all parameters defined in nested yaml file. - R-61183 The VNF Heat Orchestration Template **MUST NOT** change the parameter names, when OS::Nova::Server metadata parameters are past into a nested heat template. @@ -5089,16 +5117,18 @@ a VM on startup via the “personality” property. Support for Heat Files is subject to the following limitations: -R-76718 The VNF Heat Orchestration Template **MUST** reference the get\_files targets in -Heat templates by file name, and the corresponding files should be -delivered to ONAP along with the Heat templates. +R-76718 The VNF Heat Orchestration Template **MUST** reference the +get\_files targets in Heat templates by file name, and the +corresponding files should be delivered to ONAP along with the Heat +templates. R-41888 The VNE Heat **MUST NOT** use URL-based file retrieval. -R-62177 The VNF Heat Orchestration Template **MUST** have unique file names for the included -files within the scope of the VNF. +R-62177 The VNF Heat Orchestration Template **MUST** have unique +file names for the included files within the scope of the VNF. -R-87848 The VNF Heat Orchestration Template **MUST** have all included files in a single, flat +R-87848 The VNF Heat Orchestration Template **MUST** have all +included files in a single, flat directory per VNF. ONAP does not support a directory hierarchy. - Included files may be used by all Modules within a given VNF. diff --git a/docs/Chapter6.rst b/docs/Chapter6.rst index 381306d..b9a7ec2 100644 --- a/docs/Chapter6.rst +++ b/docs/Chapter6.rst @@ -6,7 +6,7 @@ Infrastructure Requirements =========================== -This Amsterdam release of the requirements is targeted for those +This Beijing release of the requirements is targeted for those implementations that consist of Network Clouds: Vanilla OpenStack (based on Ocata_) and commercial Clouds for example: OpenStack (including `Titanium - Mitaka from Wind River`_ and diff --git a/docs/Chapter7.rst b/docs/Chapter7.rst index 3b53f23..bd9cddf 100644 --- a/docs/Chapter7.rst +++ b/docs/Chapter7.rst @@ -63,7 +63,7 @@ Service Design ------------------------------------ This section, Service Design, has been left intentionally blank. It -is out-of-scope for the VNF Requirements project for the Amsterdam +is out-of-scope for the VNF Requirements project for the Beijing release and no numbered requirements are expected. Content may be added in future updates of this document. @@ -152,7 +152,8 @@ Configuration Management via Chef * R-18525 The xNF provider **MUST** provide a JSON file for each supported action for the xNF. The JSON file must contain key value pairs with all relevant values populated with sample data that illustrates - its usage. The fields and their description are defined in Tables A1 and A2 in the Appendix. + its usage. The fields and their description are defined in Tables A1 + and A2 in the Appendix. Note: Chef support in ONAP is not currently available and planned for 4Q 2017. @@ -164,7 +165,8 @@ Configuration Management via Ansible * R-16777 The xNF provider **MUST** provide a JSON file for each supported action for the xNF. The JSON file must contain key value pairs with all relevant values populated with sample data that illustrates - its usage. The fields and their description are defined in Table B1 in the Appendix. + its usage. The fields and their description are defined in Table B1 + in the Appendix. * R-46567 The xNF Package **MUST** include configuration scripts for boot sequence and configuration. @@ -192,7 +194,7 @@ Resource Control Loop descriptions including causes/fixes if applicable for the event. * R-42018 The xNF Package **MUST** include documentation which must include all events (fault, measurement for xNF Scaling, Syslogs, State Change - and Mobile Flow), that need to be collected at each VM, VNFC (defined in `VNF Guidelines <http://onap.readthedocs.io/en/latest/submodules/vnfrqts/guidelines.git/docs/vnf_guidelines/vnf_guidelines.html#a-glossary>`__ ) and for the overall xNF. + and Mobile Flow), that need to be collected at each VM, VNFC (defined in `VNF Guidelines <http://onap.readthedocs.io/en/beijing/submodules/vnfrqts/guidelines.git/docs/vnf_guidelines/vnf_guidelines.html#a-glossary>`__ ) and for the overall xNF. * R-27711 The xNF provider **MUST** provide an XML file that contains a list of xNF error codes, descriptions of the error, and possible causes/corrective action. @@ -290,7 +292,7 @@ Licensing Requirements * R-40827 The xNF provider **MUST** enumerate all of the open source licenses their xNF(s) incorporate. * R-97293 The xNF provider **MUST NOT** require audits of - Service Provider’s business. + Service Provider's business. * R-44569 The xNF provider **MUST NOT** require additional infrastructure such as a xNF provider license server for xNF provider functions and metrics. @@ -298,7 +300,7 @@ Licensing Requirements purposes to allow automated scale up/down by the management system. * R-27511 The VNF provider **MUST** provide the ability to scale up a VNF provider supplied product during growth and scale down a - VNF provider supplied product during decline without “real-time” + VNF provider supplied product during decline without "real-time" restrictions based upon VNF provider permissions. * R-85991 The xNF provider **MUST** provide a universal license key per xNF to be used as needed by services (i.e., not tied to a VM @@ -313,7 +315,7 @@ Licensing Requirements onboarding the xNF into the ONAP environment and automating processes for putting the licenses into use and managing the full lifecycle of the licenses. The details of this license model are described in - Tables C1 to C8 in the Appendix. Note: License metadata support in + Tables C1 to C8 in the Appendix. Note: License metadata support in ONAP is not currently available and planned for 1Q 2018. Configuration Management @@ -334,7 +336,7 @@ This section describes the list of commands that should be supported by the VNF. The following sections describe the standard protocols that are supported (NETCONF, Chef, Ansible, and REST). -The commands below are expected to be supported on all VNF’s, unless +The commands below are expected to be supported on all VNF's, unless noted otherwise, either directly (via the NETCONF or REST interface) or indirectly (via a Chef Cookbook or Ansible server). Note that there are additional commands offered to northbound clients that are not shown @@ -382,20 +384,20 @@ the VNF is not in service (i.e., in a maintenance state). **ConfigScaleOut**: The Controller client is requesting that a configuration be applied after the VNF instance has been scaled out (i.e., one or more -additional VM’s instantiated to increase capacity). For some VNF’s, +additional VM's instantiated to increase capacity). For some VNF's, ConfigScaleOut is not needed because the VNF is auto-configured after scale-out. This command is being introduced in the Beijing release. **Audit**: The Controller client is requesting that the current (last known configuration update) is audited against the running configuration on the VNF. -* R-20741 The xNF **MUST** support ONAP Controller’s **Configure** command. -* R-19366 The xNF **MUST** support ONAP Controller’s **ConfigModify** command. -* R-32981 The xNF **MUST** support ONAP Controller’s **ConfigBackup** command. -* R-48247 The xNF **MUST** support ONAP Controller’s **ConfigRestore** command. -* R-94084 The xNF **MUST** support ONAP Controller’s **ConfigScaleOut** +* R-20741 The xNF **MUST** support ONAP Controller's **Configure** command. +* R-19366 The xNF **MUST** support ONAP Controller's **ConfigModify** command. +* R-32981 The xNF **MUST** support ONAP Controller's **ConfigBackup** command. +* R-48247 The xNF **MUST** support ONAP Controller's **ConfigRestore** command. +* R-94084 The xNF **MUST** support ONAP Controller's **ConfigScaleOut** command. -* R-56385 The xNF **MUST** support ONAP Controller’s **Audit** command. +* R-56385 The xNF **MUST** support ONAP Controller's **Audit** command. LifeCycle Management Related Commands ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -445,23 +447,23 @@ up prior to the UpgradeSoftware. is backed out (in the event that the SoftwareUpgrade or UpgradePostCheck failed). -* R-12706 The xNF **MUST** support ONAP Controller’s **QuiesceTraffic** +* R-12706 The xNF **MUST** support ONAP Controller's **QuiesceTraffic** command. -* R-07251 The xNF **MUST** support ONAP Controller’s **ResumeTraffic** +* R-07251 The xNF **MUST** support ONAP Controller's **ResumeTraffic** command. -* R-83146 The xNF **MUST** support ONAP Controller’s **StopApplication** +* R-83146 The xNF **MUST** support ONAP Controller's **StopApplication** command. -* R-82811 The xNF **MUST** support ONAP Controller’s **StartApplication** +* R-82811 The xNF **MUST** support ONAP Controller's **StartApplication** command. -* R-19922 The xNF **MUST** support ONAP Controller’s **UpgradePrecheck** +* R-19922 The xNF **MUST** support ONAP Controller's **UpgradePrecheck** command. -* R-49466 The xNF **MUST** support ONAP Controller’s **UpgradeSoftware** +* R-49466 The xNF **MUST** support ONAP Controller's **UpgradeSoftware** command. -* R-45856 The xNF **MUST** support ONAP Controller’s **UpgradePostCheck** +* R-45856 The xNF **MUST** support ONAP Controller's **UpgradePostCheck** command. -* R-97343 The xNF **MUST** support ONAP Controller’s **UpgradeBackup** +* R-97343 The xNF **MUST** support ONAP Controller's **UpgradeBackup** command. -* R-65641 The xNF **MUST** support ONAP Controller’s **UpgradeBackOut** +* R-65641 The xNF **MUST** support ONAP Controller's **UpgradeBackOut** command. Virtual Function - Container Recovery Requirements @@ -481,22 +483,23 @@ without having to rebuild entire VNFs or even entire sites these basic recovery capabilities of individual containers, Virtual Machines or other, must be supported. -* R-11790 The VNF **MUST** support ONAP Controller’s +* R-11790 The VNF **MUST** support ONAP Controller's **Restart (stop/start or reboot)** command. -* R-56218 The VNF **MUST** support ONAP Controller’s Migrate command that +* R-56218 The VNF **MUST** support ONAP Controller's Migrate command that moves container (VM) from a live Physical Server / Compute Node to another live Physical Server / Compute Node. - + NOTE: Container migrations MUST be transparent to the VNF and no more intrusive than a stop, followed by some down time for the migration to be performed from one Compute Node / Physical Server to another, followed -by a start of the same VM with same configuration on the new Compute +by a start of the same VM with same configuration on the new Compute Node / Physical Server. - -* R-38001 The VNF MUST support ONAP Controller’s **Rebuild** command. -* R-76901 VNF MUST support a container rebuild mechanism based on existing - image (e.g. Glance image in Openstack environment) or a snapshot. - + +* R-38001 The VNF **MUST** support ONAP Controller's **Rebuild** command. +* R-76901 The VNF **MUST** support a container rebuild mechanism + based on existing image (e.g. Glance image in Openstack environment) + or a snapshot. + HealthCheck and Failure Related Commands ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -511,7 +514,7 @@ Openstack failure recovery related commands that are executed on-demand or via Control Loop at the VM level. The VNF must support these commands in a fully automated fashion. -* R-41430 The xNF **MUST** support ONAP Controller’s **HealthCheck** +* R-41430 The xNF **MUST** support ONAP Controller's **HealthCheck** command. Notes On Command Support Using Controller Southbound Protocols @@ -525,7 +528,7 @@ NETCONF and REST require the VNF to implement a server which supports the RPC or REST calls. Ansible and Chef require the use of a Ansible or Chef server which communicates -with the Controller (northbound) and the VNF VM’s (southbound). +with the Controller (northbound) and the VNF VM's (southbound). The vendor must select which protocol to support for the commands listed above. Notes: @@ -538,7 +541,7 @@ Notes: * REST is specified as an option only for the HealthCheck. -Additional details can be found in the `ONAP Application Controller (APPC) API Guide <http://onap.readthedocs.io/en/latest/submodules/appc.git/docs/APPC%20API%20Guide/APPC%20API%20Guide.html>`_, `ONAP VF-C project <http://onap.readthedocs.io/en/latest/submodules/vfc/nfvo/lcm.git/docs/index.html>`_ and the `ONAP SDNC project <http://onap.readthedocs.io/en/latest/submodules/sdnc/northbound.git/docs/index.html>`_. +Additional details can be found in the `ONAP Application Controller (APPC) API Guide <http://onap.readthedocs.io/en/beijing/submodules/appc.git/docs/index.html>`_, `ONAP VF-C project <http://onap.readthedocs.io/en/beijing/submodules/vfc/nfvo/lcm.git/docs/index.html>`_ and the `ONAP SDNC project <http://onap.readthedocs.io/en/beijing/submodules/sdnc/oam.git/docs/index.html>`_. NETCONF Standards and Capabilities ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -637,7 +640,7 @@ NETCONF Server Requirements server. A server may support partial XPath retrieval filtering, but it cannot advertise the **:xpath** capability unless the entire XPath 1.0 specification is supported. -* R-83790 The xNF **MUST** implement the **:validate** capability +* R-83790 The xNF **MUST** implement the **:validate** capability. * R-49145 The xNF **MUST** implement **:confirmed-commit** If **:candidate** is supported. * R-58358 The xNF **MUST** implement the **:with-defaults** capability @@ -681,7 +684,7 @@ NETCONF Server Requirements * R-63935 The xNF **MUST** release locks to prevent permanent lock-outs when a user configured timer has expired forcing the NETCONF SSH Session termination (i.e., product must expose a configuration knob for a user - setting of a lock expiration timer) + setting of a lock expiration timer). * R-10173 The xNF **MUST** allow another NETCONF session to be able to initiate the release of the lock by killing the session owning the lock, using the <kill-session> operation to guard against hung NETCONF sessions. @@ -701,7 +704,7 @@ NETCONF Server Requirements $ echo $! * R-63953 The xNF **MUST** have the echo command return a zero value - otherwise the validation has failed + otherwise the validation has failed. * R-26508 The xNF **MUST** support a NETCONF server that can be mounted on OpenDaylight (client) and perform the operations of: modify, update, change, rollback configurations using each configuration data element, @@ -713,45 +716,45 @@ The following requirements provides the Yang models that suppliers must conform, and those where applicable, that suppliers need to use. * R-28545 The xNF **MUST** conform its YANG model to RFC 6060, - “YANG - A Data Modeling Language for the Network Configuration - Protocol (NETCONF)” + "YANG - A Data Modeling Language for the Network Configuration + Protocol (NETCONF)". * R-22700 The xNF **MUST** conform its YANG model to RFC 6470, - “NETCONF Base Notifications”. + "NETCONF Base Notifications". * R-10353 The xNF **MUST** conform its YANG model to RFC 6244, - “An Architecture for Network Management Using NETCONF and YANG”. + "An Architecture for Network Management Using NETCONF and YANG". * R-53317 The xNF **MUST** conform its YANG model to RFC 6087, - “Guidelines for Authors and Reviewers of YANG Data Model Documents”. + "Guidelines for Authors and Reviewers of YANG Data Model Documents". * R-33955 The xNF **SHOULD** conform its YANG model to RFC 6991, - “Common YANG Data Types”. + "Common YANG Data Types". * R-22946 The xNF **SHOULD** conform its YANG model to RFC 6536, - “NETCONF Access Control Model”. + "NETCONF Access Control Model". * R-10129 The xNF **SHOULD** conform its YANG model to RFC 7223, - “A YANG Data Model for Interface Management”. + "A YANG Data Model for Interface Management". * R-12271 The xNF **SHOULD** conform its YANG model to RFC 7223, - “IANA Interface Type YANG Module”. + "IANA Interface Type YANG Module". * R-49036 The xNF **SHOULD** conform its YANG model to RFC 7277, - “A YANG Data Model for IP Management”. + "A YANG Data Model for IP Management". * R-87564 The xNF **SHOULD** conform its YANG model to RFC 7317, - “A YANG Data Model for System Management”. + "A YANG Data Model for System Management". * R-24269 The xNF **SHOULD** conform its YANG model to RFC 7407, - “A YANG Data Model for SNMP Configuration”, if Netconf used to + "A YANG Data Model for SNMP Configuration", if Netconf used to configure SNMP engine. The NETCONF server interface shall fully conform to the following NETCONF RFCs. * R-33946 The xNF **MUST** conform to the NETCONF RFC 4741, - “NETCONF Configuration Protocol”. + "NETCONF Configuration Protocol". * R-04158 The xNF **MUST** conform to the NETCONF RFC 4742, - “Using the NETCONF Configuration Protocol over Secure Shell (SSH)”. + "Using the NETCONF Configuration Protocol over Secure Shell (SSH)". * R-13800 The xNF **MUST** conform to the NETCONF RFC 5277, - “NETCONF Event Notification”. + "NETCONF Event Notification". * R-01334 The xNF **MUST** conform to the NETCONF RFC 5717, - “Partial Lock Remote Procedure Call”. + "Partial Lock Remote Procedure Call". * R-08134 The xNF **MUST** conform to the NETCONF RFC 6241, - “NETCONF Configuration Protocol”. + "NETCONF Configuration Protocol". * R-78282 The xNF **MUST** conform to the NETCONF RFC 6242, - “Using the Network Configuration Protocol over Secure Shell”. + "Using the Network Configuration Protocol over Secure Shell". VNF REST APIs ^^^^^^^^^^^^^^^ @@ -824,7 +827,7 @@ requirements and guidelines defined in this section. The Chef configuration management mechanism follows a client-server model. It requires the presence of a Chef-Client on the VNF that will be directly managed by a Chef Server. The Chef-client will register with -the appropriate Chef Server and are managed via ‘cookbooks’ and +the appropriate Chef Server and are managed via 'cookbooks' and configuration attributes loaded on the Chef Server which contain all necessary information to execute the appropriate actions on the VNF via the Chef-client. @@ -877,11 +880,11 @@ Chef Roles/Requirements chef-client run encounters any critical errors/failures when executing a xNF action. * R-44013 The xNF **MUST** populate an attribute, defined as node - [‘PushJobOutput’] with the desired output on all nodes in the push job + ['PushJobOutput'] with the desired output on all nodes in the push job that execute chef-client run if the xNF action requires the output of a chef-client run be made available (e.g., get running configuration). * R-30654 The xNF Package **MUST** have appropriate cookbooks that are - designed to automatically ‘rollback’ to the original state in case of + designed to automatically 'rollback' to the original state in case of any errors for actions that change state of the xNF (e.g., configure). * R-65755 The xNF **SHOULD** support callback URLs to return information to ONAP upon completion of the chef-client run for any chef-client run @@ -890,8 +893,8 @@ Chef Roles/Requirements - As part of the push job, ONAP will provide two parameters in the environment of the push job JSON object: - - ‘RequestId’ a unique Id to be used to identify the request, - - ‘CallbackUrl’, the URL to post response back. + - 'RequestId' a unique Id to be used to identify the request, + - 'CallbackUrl', the URL to post response back. - If the CallbackUrl field is empty or missing in the push job, then the chef-client run need not post the results back via callback. @@ -913,15 +916,15 @@ action request against a Chef managed VNF. 1. When ONAP receives a request for an action for a Chef Managed VNF, it retrieves the corresponding template (based on **action** and **VNF)** from its database and sets necessary values in the - “Environment”, “Node” and “NodeList” keys (if present) from either + "Environment", "Node" and "NodeList" keys (if present) from either the payload of the received action or internal data. -2. If “Environment” key is present in the updated template, it posts the +2. If "Environment" key is present in the updated template, it posts the corresponding JSON dictionary to the appropriate Environment object REST endpoint on the Chef Server thus updating the Environment attributes on the Chef Server. -3. Next, it creates a Node Object from the “Node” JSON dictionary for +3. Next, it creates a Node Object from the "Node" JSON dictionary for all elements listed in the NodeList (using the FQDN to construct the endpoint) by replicating it [2]_. As part of this process, it will set the name field in each Node Object to the corresponding FQDN. @@ -929,7 +932,7 @@ action request against a Chef managed VNF. corresponding Node Object REST endpoints to update the corresponding node attributes. -4. If PushJobFlag is set to “True” in the template, ONAP requests a push +4. If PushJobFlag is set to "True" in the template, ONAP requests a push job against all the nodes in the NodeList to trigger chef-client\ **.** It will not invoke any other command via the push job. ONAP will include a callback URL in the push job request and a @@ -941,21 +944,21 @@ action request against a Chef managed VNF. { "command": "chef-client", "run\_timeout": 300, - "nodes”: [“node1.vnf\_a.onap.com”, “node2.vnf\_a.onap.com”], + "nodes": ["node1.vnf\_a.onap.com", "node2.vnf\_a.onap.com"], "env": { - “RequestId”:”8279-abcd-aksdj-19231”, - “CallbackUrl”:”<callback>” + "RequestId":"8279-abcd-aksdj-19231", + "CallbackUrl":"<callback>" }, } 5. If CallbackCapable field in the template is not present or set to - “False” ONAP will poll the Chef Server to check completion status of + "False" ONAP will poll the Chef Server to check completion status of the push job. -6. If “GetOutputFlag” is set to “True” in the template and - CallbackCapable is not set to “True”, ONAP will retrieve any output +6. If "GetOutputFlag" is set to "True" in the template and + CallbackCapable is not set to "True", ONAP will retrieve any output from each node where the push job has finished by accessing the Node - Object attribute node[‘PushJobOutput’]. + Object attribute node['PushJobOutput']. Ansible Standards and Capabilities ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -964,7 +967,7 @@ ONAP will support configuration of VNFs via Ansible subject to the requirements and guidelines defined in this section. Ansible allows agentless management of VNFs/VMs/VNFCs via execution -of ‘playbooks’ over ssh. The ‘playbooks’ are a structured set of +of 'playbooks' over ssh. The 'playbooks' are a structured set of tasks which contain all the necessary resources and execution capabilities to take the necessary action on one or more target VMs (and/or VNFCs) of the VNF. ONAP will utilize the framework of an Ansible Server that @@ -1033,14 +1036,14 @@ complete the desired action. generic templates. The Ansible Server will determine if a playbook invoked to execute a -xNF action finished successfully or not using the “PLAY_RECAP” summary +xNF action finished successfully or not using the "PLAY_RECAP" summary in Ansible log. The playbook will be considered to successfully finish -only if the “PLAY RECAP” section at the end of playbook execution output +only if the "PLAY RECAP" section at the end of playbook execution output has no unreachable hosts and no failed tasks. Otherwise, the playbook will be considered to have failed. * R-43253 The xNF **MUST** use playbooks designed to allow Ansible - Server to infer failure or success based on the “PLAY_RECAP” capability. + Server to infer failure or success based on the "PLAY_RECAP" capability. NOTE: There are cases where playbooks need to interpret results of a task and then determine success or failure and return result accordingly (failure for failed tasks). @@ -1050,10 +1053,10 @@ will be considered to have failed. xNF information. The text files must be written in the same directory as the one from which the playbook is being executed. A text file must be created for the xNF playbook run targets/affects, with the name - ‘<VNFname>_results.txt’ into which any desired output from each + '<VNFname>_results.txt' into which any desired output from each respective VM/xNF must be written. * R-51442 The xNF **SHOULD** use playbooks that are designed to - automatically ‘rollback’ to the original state in case of any errors + automatically 'rollback' to the original state in case of any errors for actions that change state of the xNF (e.g., configure). NOTE: In case rollback at the playbook level is not supported or possible, @@ -1112,7 +1115,7 @@ will be considered to have failed. A successful execution of a health-check playbook shall also create one file per VNF VM, named after the VNF instance name followed by - “_results.txt (<vnf_instance>_results.txt) to indicate health-check was + _results.txt (<vnf_instance>_results.txt) to indicate health-check was executed and completed successfully, example: vfdb9904v_results.txt, with the following contents: @@ -1145,7 +1148,7 @@ Example: A failed health-check playbook shall also create one file per VNF, named after the VNF instance name, followed by - “_results.txt to indicate health-check was executed and found issues + _results.txt to indicate health-check was executed and found issues in the health of the VNF. This is to differentiate from failure to run health-check playbook or playbook tasks to verify the health of the VNF, example: vfdb9904v_results.txt, with the following contents: @@ -1229,7 +1232,7 @@ Table 8. ONAP Controller APIs and NETCONF Commands | | |a VNF and place it |Ansible server in | | | |in the respective |a manner aligned | | | |Node Objects |with playbook | -| | |‘PushJobOutput’ |requirements listed | +| | |'PushJobOutput' |requirements listed | | | |attribute of all |in this document. | | | |nodes in NodeList | | | | |when triggered |The PlaybookName | @@ -1239,10 +1242,10 @@ Table 8. ONAP Controller APIs and NETCONF Commands | | |The JSON file for |NodeList must list | | | |this VNF action is |IP addresses or DNS | | | |required to set |supported FQDNs of | -| | |“PushJobFlag” to |an example VNF | -| | |“True” and |on which to | -| | |“GetOutputFlag” to |execute playbook. | -| | |“True”. The “Node” | | +| | |"PushJobFlag" to |an example VNF | +| | |"True" and |on which to | +| | |"GetOutputFlag" to |execute playbook. | +| | |"True". The "Node" | | | | |JSON dictionary | | | | |must have the run | | | | |list populated | | @@ -1309,7 +1312,7 @@ Monitoring & Management This section addresses data collection and event processing functionality that is directly dependent on the interfaces -provided by the VNFs’ APIs. These can be in the form of asynchronous +provided by the VNFs' APIs. These can be in the form of asynchronous interfaces for event, fault notifications, and autonomous data streams. They can also be synchronous interfaces for on-demand requests to retrieve various performance, usage, and other event information. @@ -1338,12 +1341,12 @@ Streaming (VES) specifications. While this document is focused on specifying some of the records from the ONAP perspective, there may be other external bodies using the same framework to specify additional records. For example, OPNFV has a VES project that is looking to specify -records for OpenStack’s internal telemetry to manage Application (VNFs), +records for OpenStack's internal telemetry to manage Application (VNFs), physical and virtual infrastructure (compute, storage, network devices), and virtual infrastructure managers (cloud controllers, SDN controllers). Note that any configurable parameters for these data records (e.g., frequency, granularity, policy-based configuration) will be managed -using the “Configuration” framework described in the prior sections +using the "Configuration" framework described in the prior sections of this document. The Data Model consists of: @@ -1510,7 +1513,7 @@ synchronous communications over secure connections. The specified encoding provides self-documenting content, so data fields can be changed as needs evolve, while minimizing changes to data delivery. -The term ‘Event Record’ is used throughout this document to represent +The term 'Event Record' is used throughout this document to represent various forms of telemetry or instrumentation made available by the VNF including, faults, status events, various other types of VNF measurements and logs. Headers received by themselves must be used @@ -1654,7 +1657,7 @@ VNF telemetry via standardized interface Encoding and Serialization ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Content delivered from VNFs to ONAP is to be encoded and serialized using JSON: +Content delivered from VNFs to ONAP is to be encoded and serialized using JSON. JSON ~~~~~~~~~~~~~~~~~~ @@ -1744,7 +1747,7 @@ Reporting Frequency or content may be summarized statistically over a time interval, or computed as a KPI, with the summary or KPI being delivered. - We expect the reporting frequency to be configurable depending - on the virtual network function’s needs for management. For example, + on the virtual network function's needs for management. For example, Service Provider may choose to vary the frequency of collection between normal and trouble-shooting scenarios. - Decisions about the frequency of data reporting will affect the @@ -1825,8 +1828,8 @@ Asynchronous and Synchronous Data Delivery * R-43327 The xNF **SHOULD** use `Modeling JSON text with YANG <https://tools.ietf.org/html/rfc7951>`_, If YANG models need to be translated to and from JSON{RFC7951]. YANG configuration and content can - be represented via JSON, consistent with Avro, as described in “Encoding - and Serialization” section. + be represented via JSON, consistent with Avro, as described in "Encoding + and Serialization" section. Security ~~~~~~~~~~ @@ -1849,7 +1852,7 @@ Security .. [2] Recall that the Node Object **is required** to be identical across - all VMs of a VNF invoked as part of the action except for the “name”. + all VMs of a VNF invoked as part of the action except for the "name". .. [3] Upstream elements must provide the appropriate FQDN in the request to @@ -1862,14 +1865,11 @@ Security This option is not currently supported in ONAP and it is currently under consideration. -.. [6] - https://wiki.opnfv.org/display/PROJ/VNF+Event+Stream .. |image0| image:: Data_Model_For_Event_Records.png :width: 7in :height: 8in - .. |image1| image:: VES_JSON_Driven_Model.png :width: 5in :height: 3in diff --git a/docs/Chapter8.rst b/docs/Chapter8.rst index c90a64a..86ae4c1 100644 --- a/docs/Chapter8.rst +++ b/docs/Chapter8.rst @@ -56,7 +56,7 @@ Table A1. Chef JSON File key value description | | as part of the desired | | | | | VNF action. | | | +----------------+--------------------------+---------+----------------------+ -| PushJobFlag | This field indicates |Mandatory| If set to “True”, | +| PushJobFlag | This field indicates |Mandatory| If set to "True", | | | whether the VNF action | | ONAP will request a | | | requires a push Job. Push| | push job. Ignored | | | job object will be | | otherwise. | @@ -66,7 +66,7 @@ Table A1. Chef JSON File key value description | CallbackCapable| This field indicates if | Optional| If Chef cookbook is | | | the chef-client run | | callback capable, VNF| | | invoked by push job | | owner is required to | -| | corresponding to the VNF | | set it to “True”. | +| | corresponding to the VNF | | set it to "True". | | | action is capable of | | Ignored otherwise. | | | posting results on a | | | | | callback URL. | | | @@ -74,9 +74,9 @@ Table A1. Chef JSON File key value description | GetOutputFlag | Flag which indicates |Mandatory| ONAP will retrieve | | | whether ONAP should | | output from | | | retrieve output generated| | NodeObject attributes| -| | in a chef-client run from| | [‘PushJobOutput’] for| +| | in a chef-client run from| | ['PushJobOutput'] for| | | Node object attribute | | all nodes in NodeList| -| | node[‘PushJobOutput’] for| | if set to “True”. | +| | node['PushJobOutput'] for| | if set to "True". | | | this VNF action (e.g., in| | Ignored otherwise. | | | Audit). | | | +----------------+--------------------------+---------+----------------------+ @@ -85,39 +85,39 @@ Chef Template example: .. code-block:: chef - “Environment”:{ + "Environment":{ "name": "HAR", "description": "VNF Chef environment for HAR", "json\_class": "Chef::Environment", "chef\_type": "environment", "default\_attributes": { }, "override\_attributes": { - “Retry\_Time”:”50”, - “MemCache”: “1024”, - “Database\_IP”:”10.10.1.5” + "Retry\_Time":"50", + "MemCache": "1024", + "Database\_IP":"10.10.1.5" }, } } - “Node”: { - “name” : “signal.network.com “ + "Node": { + "name" : "signal.network.com " "chef\_type": "node", "json\_class": "Chef::Node", "attributes": { - “IPAddress1”: “192.168.1.2”, - “IPAddress2”:”135.16.162.5”, - “MyRole”:”BE” + "IPAddress1": "192.168.1.2", + "IPAddress2":"135.16.162.5", + "MyRole":"BE" }, "override": {}, "default": {}, - “normal”:{}, - “automatic”:{}, - “chef\_environment” : “\_default” + "normal":{}, + "automatic":{}, + "chef\_environment" : "\_default" "run\_list": [ "configure\_signal" ] }, - “NodeList”:[“node1.vnf\_a.onap.com”, “node2.vnf\_a.onap.com”], - “PushJobFlag”: “True” - “CallbackCapable”:True - “GetOutputFlag” : “False” + "NodeList":["node1.vnf\_a.onap.com", "node2.vnf\_a.onap.com"], + "PushJobFlag": "True" + "CallbackCapable":True + "GetOutputFlag" : "False" } The example JSON file provided by the VNF provider for each VNF action will be @@ -129,8 +129,8 @@ Some points worth noting regarding the JSON fields: a. The JSON file must be created for each action for each VNF. b. If a VNF action involves multiple endpoints (VMs) of a VNF, ONAP will - replicate the “Node” JSON dictionary in the template and post it to - each FQDN (i.e., endpoint) in the NodeList after setting the “name” + replicate the "Node" JSON dictionary in the template and post it to + each FQDN (i.e., endpoint) in the NodeList after setting the "name" field in the Node object to be the respective FQDN [1]_. Hence, it is required that all end points (VMs) of a VNF involved in a VNF action support the same set of Node Object attributes. @@ -158,7 +158,7 @@ Table A2. JSON Dictionary to Post in Callback | | successfully 500 otherwise.| | | +--------------+----------------------------+---------+-----------------------+ | StatusMessage| A string which must be set |Mandatory| | -| | to ‘SUCCESS’ if StatusCode | | | +| | to 'SUCCESS' if StatusCode | | | | | was 200 | | | | | | | | | | Appropriate error message | | | @@ -208,11 +208,11 @@ Table B1. Ansible JSON File key value description | | value pairs to be | |Attribute names (variable | | | passed to the Ansible| |names) passed to Ansible | | | playbook. These | |shall follow Ansible valid | -| | values would | |variable names: “Variable | +| | values would | |variable names: "Variable | | | correspond to | |names should be letters, | | | instance specific | |numbers, and underscores. | | | parameters that a | |Variables should always | -| | playbook may need to | |start with a letter.” | +| | playbook may need to | |start with a letter." | | | execute an action. | | | +---------------+----------------------+---------+----------------------------+ | NodeList |Ansible inventory | Optional|If not provided, pre-loaded | @@ -254,28 +254,30 @@ Table B1. Ansible JSON File key value description Ansible JSON file example: -{ +.. code-block:: json - “Action”:”Configure”, + { - "PlaybookName": "<VNFCode>/<Version>/ansible/configure/site.yml", + "Action":"Configure", - "NodeList": ["test1.vnf\_b.onap.com", “test2.vnf\_b.onap.com”], + "PlaybookName": "<VNFCode>/<Version>/ansible/configure/site.yml", - "Timeout": 60, + "NodeList": ["test1.vnf\_b.onap.com", "test2.vnf\_b.onap.com"], - "EnvParameters": {"Retry": 3, "Wait": 5, “ConfigFile”:”config.txt”}, + "Timeout": 60, - “FileParameters”:{“config.txt”:”db\_ip=10.1.1.1, sip\_timer=10000”} + "EnvParameters": {"Retry": 3, "Wait": 5, "ConfigFile":"config.txt"}, -} + "FileParameters":{"config.txt":"db\_ip=10.1.1.1, sip\_timer=10000"} + + } In the above example, the Ansible Server will: -a. Process the “FileParameters” dictionary and generate a file named - ‘config.txt’ with contents set to the value of the ‘config.txt’ key. +a. Process the "FileParameters" dictionary and generate a file named + 'config.txt' with contents set to the value of the 'config.txt' key. -b. Execute the playbook named ‘<VNFCode>/<Version>/ansible/configure/site.yml’ +b. Execute the playbook named '<VNFCode>/<Version>/ansible/configure/site.yml' on nodes with FQDNs test1.vnf\_b.onap.com and test2.vnf\_b.onap.com respectively while providing the following key value pairs to the playbook: Retry=3, Wait=5, ConfigFile=config.txt @@ -939,11 +941,11 @@ execution environment) R-99656 The VNF **MUST** NOT terminate stable sessions if a VNFC instance fails. -R-84473 The VNF **MUST** enable DPDK in the guest OS for VNF’s requiring +R-84473 The VNF **MUST** enable DPDK in the guest OS for VNF's requiring high packets/sec performance. High packet throughput is defined as greater than 500K packets/sec. -R-54430 The VNF **MUST** use the NCSP’s supported library and compute +R-54430 The VNF **MUST** use the NCSP's supported library and compute flavor that supports DPDK to optimize network efficiency if using DPDK. [5]_ R-18864 The VNF **MUST** NOT use technologies that bypass virtualization @@ -1078,7 +1080,7 @@ connections, etc.) within the VNF application so that resources are not being created and destroyed resulting in resource management overhead. -R-55345 The VNF **SHOULD** use techniques such as “lazy loading” when +R-55345 The VNF **SHOULD** use techniques such as "lazy loading" when initialization includes loading catalogues and/or lists which can grow over time, so that the VNF startup time does not grow at a rate proportional to that of the list. @@ -1193,8 +1195,8 @@ VNF Security ~~~~~~~~~~~~~~ R-23740 The VNF **MUST** accommodate the security principle of -“least privilege” during development, implementation and operation. -The importance of “least privilege” cannot be overstated and must be +"least privilege" during development, implementation and operation. +The importance of "least privilege" cannot be overstated and must be observed in all aspects of VNF development and not limited to security. This is applicable to all sections of this document. @@ -1203,7 +1205,7 @@ services (e.g., restricting access to certain ports or applications). R-85633 The VNF **MUST** implement Data Storage Encryption (database/disk encryption) for Sensitive Personal Information (SPI) -and other subscriber identifiable data. Note: subscriber’s SPI/data +and other subscriber identifiable data. Note: subscriber's SPI/data must be encrypted at rest, and other subscriber identifiable data should be encrypted at rest. Other data protection requirements exist and should be well understood by the developer. @@ -1259,36 +1261,36 @@ R-69649 The VNF **MUST** have all vulnerabilities patched as soon as possible. Patching shall be controlled via change control process with vulnerabilities disclosed along with mitigation recommendations. -R-78010 The VNF **MUST** use the NCSP’s IDAM API for Identification, +R-78010 The VNF **MUST** use the NCSP's IDAM API for Identification, authentication and access control of customer or VNF application users. -R-42681 The VNF **MUST** use the NCSP’s IDAM API or comply with -the requirements if not using the NCSP’s IDAM API, for identification, +R-42681 The VNF **MUST** use the NCSP's IDAM API or comply with +the requirements if not using the NCSP's IDAM API, for identification, authentication and access control of OA&M and other system level functions. -R-68589 The VNF **MUST**, if not using the NCSP’s IDAM API, support +R-68589 The VNF **MUST**, if not using the NCSP's IDAM API, support User-IDs and passwords to uniquely identify the user/application. VNF needs to have appropriate connectors to the Identity, Authentication and Authorization systems that enables access at OS, Database and Application levels as appropriate. -R-52085 The VNF **MUST**, if not using the NCSP’s IDAM API, provide +R-52085 The VNF **MUST**, if not using the NCSP's IDAM API, provide the ability to support Multi-Factor Authentication (e.g., 1st factor = Software token on device (RSA SecureID); 2nd factor = User Name+Password, etc.) for the users. -R-98391 The VNF **MUST**, if not using the NCSP’s IDAM API, support +R-98391 The VNF **MUST**, if not using the NCSP's IDAM API, support Role-Based Access Control to permit/limit the user/application to performing specific activities. -R-63217 The VNF **MUST**, if not using the NCSP’s IDAM API, support -logging via ONAP for a historical view of “who did what and when”. +R-63217 The VNF **MUST**, if not using the NCSP's IDAM API, support +logging via ONAP for a historical view of "who did what and when". -R-62498 The VNF **MUST**, if not using the NCSP’s IDAM API, encrypt +R-62498 The VNF **MUST**, if not using the NCSP's IDAM API, encrypt OA&M access (e.g., SSH, SFTP). -R-79107 The VNF **MUST**, if not using the NCSP’s IDAM API, enforce +R-79107 The VNF **MUST**, if not using the NCSP's IDAM API, enforce a configurable maximum number of Login attempts policy for the users. VNF provider must comply with "terminate idle sessions" policy. Interactive sessions must be terminated, or a secure, locking screensaver @@ -1296,13 +1298,13 @@ must be activated requiring authentication, after a configurable period of inactivity. The system-based inactivity timeout for the enterprise identity and access management system must also be configurable. -R-35144 The VNF **MUST**, if not using the NCSP’s IDAM API, comply -with the NCSP’s credential management policy. +R-35144 The VNF **MUST**, if not using the NCSP's IDAM API, comply +with the NCSP's credential management policy. -R-75041 The VNF **MUST**, if not using the NCSP’s IDAM API, expire +R-75041 The VNF **MUST**, if not using the NCSP's IDAM API, expire passwords at regular configurable intervals. -R-46908 The VNF **MUST**, if not using the NCSP’s IDAM API, comply +R-46908 The VNF **MUST**, if not using the NCSP's IDAM API, comply with "password complexity" policy. When passwords are used, they shall be complex and shall at least meet the following password construction requirements: (1) be a minimum configurable number of characters in @@ -1315,22 +1317,22 @@ characters that may have command functions, and (6) new passwords must not contain sequences of three or more characters from the previous password. -R-39342 The VNF **MUST**, if not using the NCSP’s IDAM API, comply +R-39342 The VNF **MUST**, if not using the NCSP's IDAM API, comply with "password changes (includes default passwords)" policy. Products will support password aging, syntax and other credential management practices on a configurable basis. -R-40521 The VNF **MUST**, if not using the NCSP’s IDAM API, support +R-40521 The VNF **MUST**, if not using the NCSP's IDAM API, support use of common third party authentication and authorization tools such as TACACS+, RADIUS. -R-41994 The VNF **MUST**, if not using the NCSP’s IDAM API, comply +R-41994 The VNF **MUST**, if not using the NCSP's IDAM API, comply with "No Self-Signed Certificates" policy. Self-signed certificates must be used for encryption only, using specified and approved encryption protocols such as TLS 1.2 or higher or equivalent security protocols such as IPSec, AES. -R-23135 The VNF **MUST**, if not using the NCSP’s IDAM API, +R-23135 The VNF **MUST**, if not using the NCSP's IDAM API, authenticate system to system communications where one system accesses the resources of another system, and must never conceal individual accountability. @@ -1405,7 +1407,7 @@ must login with an account with admin privileges in a way that uniquely identifies the individual performing the function. R-85028 The VNF **MUST** authenticate system to system access and -do not conceal a VNF provider user’s individual accountability for +do not conceal a VNF provider user's individual accountability for transactions. R-80335 The VNF **MUST** make visible a Warning Notice: A formal @@ -1579,21 +1581,21 @@ inherent privilege level of users. R-94525 The VNF **MUST** log connections to a network listener of the resource. -R-31614 The VNF **MUST** log the field “event type” in the security +R-31614 The VNF **MUST** log the field "event type" in the security audit logs. -R-97445 The VNF **MUST** log the field “date/time” in the security +R-97445 The VNF **MUST** log the field "date/time" in the security audit logs. -R-25547 The VNF **MUST** log the field “protocol” in the security audit logs. +R-25547 The VNF **MUST** log the field "protocol" in the security audit logs. -R-06413 The VNF **MUST** log the field “service or program used for -access” in the security audit logs. +R-06413 The VNF **MUST** log the field "service or program used for +access" in the security audit logs. -R-15325 The VNF **MUST** log the field “success/failure” in the +R-15325 The VNF **MUST** log the field "success/failure" in the security audit logs. -R-89474 The VNF **MUST** log the field “Login ID” in the security audit logs. +R-89474 The VNF **MUST** log the field "Login ID" in the security audit logs. R-04982 The VNF **MUST NOT** include an authentication credential, e.g., password, in the security audit logs, even if encrypted. @@ -1618,19 +1620,19 @@ R-74958 The VNF **MUST** activate security alarms automatically when the following event is detected: unsuccessful attempts to gain permissions or assume the identity of another user -R-15884 The VNF **MUST** include the field “date” in the Security alarms +R-15884 The VNF **MUST** include the field "date" in the Security alarms (where applicable and technically feasible). -R-23957 The VNF **MUST** include the field “time” in the Security alarms +R-23957 The VNF **MUST** include the field "time" in the Security alarms (where applicable and technically feasible). -R-71842 The VNF **MUST** include the field “service or program used for -access” in the Security alarms (where applicable and technically feasible). +R-71842 The VNF **MUST** include the field "service or program used for +access" in the Security alarms (where applicable and technically feasible). -R-57617 The VNF **MUST** include the field “success/failure” in the +R-57617 The VNF **MUST** include the field "success/failure" in the Security alarms (where applicable and technically feasible). -R-99730 The VNF **MUST** include the field “Login ID” in the Security +R-99730 The VNF **MUST** include the field "Login ID" in the Security alarms (where applicable and technically feasible). R-29705 The VNF **MUST** restrict changing the criticality level of a @@ -1644,7 +1646,7 @@ abuse detection. R-21819 The VNF **MUST** support requests for information from law enforcement and government agencies. -R-56786 The VNF **MUST** implement “Closed Loop” automatic implementation +R-56786 The VNF **MUST** implement "Closed Loop" automatic implementation (without human intervention) for Known Threats with detection rate in low false positives. @@ -1751,9 +1753,9 @@ by the certificate — the "distinguished name". VNF Modularity ~~~~~~~~~~~~~~~~~~ -R-37028 The VNF **MUST** be composed of one “base” module. +R-37028 The VNF **MUST** be composed of one "base" module. -R-41215 The VNF **MAY** have zero to many “incremental” modules. +R-41215 The VNF **MAY** have zero to many "incremental" modules. R-20974 The VNF **MUST** deploy the base module first, prior to the incremental modules. @@ -1836,7 +1838,8 @@ testing and operations. Heat ~~~~ -R-95303 A VNF's Heat Orchestration Template **MUST** be defined using valid YAML. +R-95303 A VNF's Heat Orchestration Template **MUST** be defined +using valid YAML. R-27078 A VNF's Heat Orchestration template **MUST** contain the section "heat_template_version:". @@ -1851,7 +1854,7 @@ R-90279 A VNF Heat Orchestration's template's parameter **MUST** be used in a resource with the exception of the parameters for the OS::Nova::Server resource property availability_zone. -R-91273 A VNF Heat Orchestration’s template’s parameter for +R-91273 A VNF Heat Orchestration's template's parameter for the OS::Nova::Server resource property availability_zone **MAY NOT** be used in any OS::Nova::Resource. @@ -1859,10 +1862,10 @@ R-25877 A VNF's Heat Orchestration Template's parameter name (i.e., <param name>) **MUST** contain only alphanumeric characters and underscores ('_'). -R-36772 A VNF’s Heat Orchestration Template’s parameter -**MUST** include the attribute “type:”. +R-36772 A VNF's Heat Orchestration Template's parameter +**MUST** include the attribute "type:". -R-11441 A VNF’s Heat Orchestration Template’s parameter +R-11441 A VNF's Heat Orchestration Template's parameter type **MUST** be one of the following values: "string", "number", "json", "comma_delimited_list" or "boolean". @@ -1885,22 +1888,22 @@ R-88863 A VNF's Heat Orchestration Template's parameter defined as type "number" **MUST** have a parameter constraint of "range" or "allowed_values" defined. -R-40518 A VNF's Heat Orchestration Template’s parameter defined as +R-40518 A VNF's Heat Orchestration Template's parameter defined as type "string" **MAY** have a parameter constraint defined. -R-96227 A VNF's Heat Orchestration Template’s parameter defined as +R-96227 A VNF's Heat Orchestration Template's parameter defined as type "json" **MAY** have a parameter constraint defined. -R-79817 A VNF's Heat Orchestration Template’s parameter defined as +R-79817 A VNF's Heat Orchestration Template's parameter defined as type "comma_delimited_list" **MAY** have a parameter constraint defined. -R-06613 A VNF's Heat Orchestration Template’s parameter defined as +R-06613 A VNF's Heat Orchestration Template's parameter defined as type "boolean" **MAY** have a parameter constraint defined. R-00011 A VNF's Heat Orchestration Template's Nested YAML files parameter's **MUST NOT** have a parameter constraint defined. -R-22589 A VNF’s Heat Orchestration Template parameter declaration +R-22589 A VNF's Heat Orchestration Template parameter declaration **MAY** contain the attribute "immutable:". R-23664 A VNF's Heat Orchestration template **MUST** contain @@ -1920,10 +1923,10 @@ R-16447 A VNF's <resource ID> **MUST** be unique across all Heat Orchestration Templates and all HEAT Orchestration Template Nested YAML files that are used to create the VNF. -R-53952 A VNF’s Heat Orchestration Template’s Resource +R-53952 A VNF's Heat Orchestration Template's Resource **MUST NOT** reference a HTTP-based resource definitions. -R-71699 A VNF’s Heat Orchestration Template’s Resource +R-71699 A VNF's Heat Orchestration Template's Resource **MUST NOT** reference a HTTP-based Nested YAML file. R-10834 If a VNF Heat Orchestration Template resource attribute @@ -1933,19 +1936,20 @@ supported and the nested "get_param" **MUST** reference an index R-97199 A VNF's Heat Orchestration Template's OS::Nova::Server resource **MUST** contain the attribute "metadata". -R-46968 VNF’s Heat Orchestration Template’s Resource **MAY** -declare the attribute “depends_on:”. +R-46968 VNF's Heat Orchestration Template's Resource **MAY** +declare the attribute "depends_on:". -R-63137 VNF’s Heat Orchestration Template’s Resource **MAY** -declare the attribute “update_policy:”. +R-63137 VNF's Heat Orchestration Template's Resource **MAY** +declare the attribute "update_policy:". -R-43740 A VNF’s Heat Orchestration Template’s Resource -**MAY** declare the attribute “deletion_policy:”. +R-43740 A VNF's Heat Orchestration Template's Resource +**MAY** declare the attribute "deletion_policy:". -R-78569 A VNF’s Heat Orchestration Template’s Resouce **MAY** -declare the attribute “external_id:”. +R-78569 A VNF's Heat Orchestration Template's Resouce **MAY** +declare the attribute "external_id:". -R-36982 A VNF’s Heat Orchestration template **MAY** contain the “outputs:” section. +R-36982 A VNF's Heat Orchestration template **MAY** contain the +"outputs:" section. R-86285 The VNF Heat Orchestration Template **MUST** have a corresponding environment file, even if no parameters are required to be enumerated. @@ -1958,28 +1962,28 @@ R-03324 The VNF Heat Orchestration Template **MUST** contain the "parameters" section in the environment file -R-68198 A VNF’s Heat Orchestration template’s Environment File’s -“parameters:” section **MAY** enumerate parameters. +R-68198 A VNF's Heat Orchestration template's Environment File's +"parameters:" section **MAY** enumerate parameters. -R-59930 A VNF’s Heat Orchestration template’s Environment -File’s **MAY** contain the “parameter_defaults:” section. +R-59930 A VNF's Heat Orchestration template's Environment +File's **MAY** contain the "parameter_defaults:" section. -R-46096 A VNF’s Heat Orchestration template’s Environment File’s -**MAY** contain the “encrypted_parameters:” section. +R-46096 A VNF's Heat Orchestration template's Environment File's +**MAY** contain the "encrypted_parameters:" section. -R-24893 A VNF’s Heat Orchestration template’s Environment File’s -**MAY** contain the “event_sinks:” section. +R-24893 A VNF's Heat Orchestration template's Environment File's +**MAY** contain the "event_sinks:" section. -R-42685 A VNF’s Heat Orchestration template’s Environment File’s -**MAY** contain the “parameter_merge_strategies:” section. +R-42685 A VNF's Heat Orchestration template's Environment File's +**MAY** contain the "parameter_merge_strategies:" section. -R-67231 A VNF’s Heat Orchestration template’s Environment File’s **MUST NOT** -contain the “resource_registry:” section. +R-67231 A VNF's Heat Orchestration template's Environment File's **MUST NOT** +contain the "resource_registry:" section. R-69663 A VNF **MAY** be composed from one or more Heat Orchestration Templates, each of which represents a subset of the overall VNF. -R-33132 A VNF’s Heat Orchestration Template **MAY** be 1.) Base Module +R-33132 A VNF's Heat Orchestration Template **MAY** be 1.) Base Module Heat Orchestration Template (also referred to as a Base Module), 2.) Incremental Module Heat Orchestration Template (referred to as an Incremental Module), or 3.) a Cinder Volume Module Heat Orchestration Template @@ -1987,147 +1991,147 @@ Module), or 3.) a Cinder Volume Module Heat Orchestration Template R-13196 A VNF **MAY** be composed of zero to many Incremental Modules -R-28980 A VNF’s incremental module **MAY** be used for initial VNF +R-28980 A VNF's incremental module **MAY** be used for initial VNF deployment only. -R-86926 A VNF’s incremental module **MAY** be used for scale out only. +R-86926 A VNF's incremental module **MAY** be used for scale out only. -R-91497 A VNF’s incremental module **MAY** be used for both deployment +R-91497 A VNF's incremental module **MAY** be used for both deployment and scale out. -R-68122 A VNF’s incremental module **MAY** be deployed more than once, +R-68122 A VNF's incremental module **MAY** be deployed more than once, either during initial VNF deployment and/or scale out. -R-46119 A VNF’s Heat Orchestration Template’s Resource OS::Heat::CinderVolume +R-46119 A VNF's Heat Orchestration Template's Resource OS::Heat::CinderVolume **MAY** be defined in a Base Module. -R-90748 A VNF’s Heat Orchestration Template’s Resource OS::Cinder::Volume +R-90748 A VNF's Heat Orchestration Template's Resource OS::Cinder::Volume **MAY** be defined in an Incremental Module. -R-03251 A VNF’s Heat Orchestration Template’s Resource OS::Cinder::Volume +R-03251 A VNF's Heat Orchestration Template's Resource OS::Cinder::Volume **MAY** be defined in a Cinder Volume Module. -* R-11200 The VNF **MUST** keep the scope of a Cinder volume module, +R-11200 The VNF **MUST** keep the scope of a Cinder volume module, when it exists, to be 1:1 with the VNF Base Module or Incremental Module. R-11200 The VNF **MUST** keep the scope of a Cinder volume module, when it exists, to be 1:1 with the VNF Base Module or Incremental Module -R-36582 A VNF’s Base Module **MAY** utilize nested heat. +R-36582 A VNF's Base Module **MAY** utilize nested heat. -R-56721 A VNF’s Incremental Module **MAY** utilize nested heat. +R-56721 A VNF's Incremental Module **MAY** utilize nested heat. -R-30395 A VNF’s Cinder Volume Module **MAY** utilize nested heat. +R-30395 A VNF's Cinder Volume Module **MAY** utilize nested heat. -R-87485 A VNF’s Heat Orchestration Template’s file extension **MUST** -be in the lower case format ‘.yaml’ or ‘.yml’. +R-87485 A VNF's Heat Orchestration Template's file extension **MUST** +be in the lower case format '.yaml' or '.yml'. -R-56438 A VNF’s Heat Orchestration Template’s Nested YAML file extension -**MUST** be in the lower case format ‘.yaml’ or ‘.yml’. +R-56438 A VNF's Heat Orchestration Template's Nested YAML file extension +**MUST** be in the lower case format '.yaml' or '.yml'. -R-74304 A VNF’s Heat Orchestration Template’s Environment file extension -**MUST** be in the lower case format ‘.env’. +R-74304 A VNF's Heat Orchestration Template's Environment file extension +**MUST** be in the lower case format '.env'. -R-81339 A VNF Heat Orchestration Template’s Base Module file name **MUST** -include ‘base’ in the filename and **MUST** match one of the following four -formats: 1.) ‘base_<text>.y[a]ml’, 2.) ‘<text>_base.y[a]ml’, 3.) -‘base.y[a]ml’, or 4.) ‘<text>_base_<text>’.y[a]ml; where ‘base’ is case -insensitive and where ‘<text>’ **MUST** contain only alphanumeric characters -and underscores ‘_’ and **MUST NOT** contain the case insensitive word ‘base’. +R-81339 A VNF Heat Orchestration Template's Base Module file name **MUST** +include 'base' in the filename and **MUST** match one of the following four +formats: 1.) 'base_<text>.y[a]ml', 2.) '<text>_base.y[a]ml', 3.) +'base.y[a]ml', or 4.) '<text>_base_<text>'.y[a]ml; where 'base' is case +insensitive and where '<text>' **MUST** contain only alphanumeric characters +and underscores '_' and **MUST NOT** contain the case insensitive word 'base'. -R-91342 A VNF Heat Orchestration Template’s Base Module’s Environment File -**MUST** be named identical to the VNF Heat Orchestration Template’s Base -Module with ‘.y[a]ml’ replaced with ‘.env’. +R-91342 A VNF Heat Orchestration Template's Base Module's Environment File +**MUST** be named identical to the VNF Heat Orchestration Template's Base +Module with '.y[a]ml' replaced with '.env'. -R-87247 A VNF Heat Orchestration Template’s Incremental Module file name -**MUST** contain only alphanumeric characters and underscores ‘_’ and -**MUST NOT** contain the case insensitive word ‘base’. +R-87247 A VNF Heat Orchestration Template's Incremental Module file name +**MUST** contain only alphanumeric characters and underscores '_' and +**MUST NOT** contain the case insensitive word 'base'. -R-94509 A VNF Heat Orchestration Template’s Incremental Module’s Environment -File **MUST** be named identical to the VNF Heat Orchestration Template’s -Incremental Module with ‘.y[a]ml’ replaced with ‘.env’. +R-94509 A VNF Heat Orchestration Template's Incremental Module's Environment +File **MUST** be named identical to the VNF Heat Orchestration Template's +Incremental Module with '.y[a]ml' replaced with '.env'. -R-82732 A VNF Heat Orchestration Template’s Cinder Volume Module **MUST** be +R-82732 A VNF Heat Orchestration Template's Cinder Volume Module **MUST** be named identical to the base or incremental module it is supporting with -‘_volume appended’ +'_volume appended' -R-31141 A VNF Heat Orchestration Template’s Cinder Volume Module’s Environment -File **MUST** be named identical to the VNF Heat Orchestration Template’s -Cinder Volume Module with .y[a]ml replaced with ‘.env’. +R-31141 A VNF Heat Orchestration Template's Cinder Volume Module's Environment +File **MUST** be named identical to the VNF Heat Orchestration Template's +Cinder Volume Module with .y[a]ml replaced with '.env'. -R-76057 A VNF Heat Orchestration Template’s Nested YAML file name **MUST** -contain only alphanumeric characters and underscores ‘_’ and **MUST NOT** -contain the case insensitive word ‘base’. +R-76057 A VNF Heat Orchestration Template's Nested YAML file name **MUST** +contain only alphanumeric characters and underscores '_' and **MUST NOT** +contain the case insensitive word 'base'. R-18224 The VNF Heat Orchestration Template **MUST** pass in as properties all parameter values associated with the nested heat file in the resource definition defined in the parent heat template. -R-52753 VNF’s Heat Orchestration Template’s Base Module’s output parameter’s -name and type **MUST** match the VNF’s Heat Orchestration Template’s -incremental Module’s name and type unless the output parameter is of type -‘comma_delimited_list’, then the corresponding input parameter **MUST** -be declared as type ‘json’. +R-52753 VNF's Heat Orchestration Template's Base Module's output parameter's +name and type **MUST** match the VNF's Heat Orchestration Template's +incremental Module's name and type unless the output parameter is of type +'comma_delimited_list', then the corresponding input parameter **MUST** +be declared as type 'json'. -R-22608 When a VNF’s Heat Orchestration Template’s Base Module’s output +R-22608 When a VNF's Heat Orchestration Template's Base Module's output parameter is declared as an input parameter in an Incremental Module, -the parameter attribute ‘constraints:’ **MUST NOT** be declared. +the parameter attribute 'constraints:' **MUST NOT** be declared. -R-89913 A VNF’s Heat Orchestration Template’s Cinder Volume Module Output +R-89913 A VNF's Heat Orchestration Template's Cinder Volume Module Output Parameter(s) **MUST** include the UUID(s) of the Cinder Volumes created in template, while other Output Parameters **MAY** be included. -R-07443 A VNF’s Heat Orchestration Templates’ Cinder Volume Module Output -Parameter’s name and type **MUST** match the input parameter name and type +R-07443 A VNF's Heat Orchestration Templates' Cinder Volume Module Output +Parameter's name and type **MUST** match the input parameter name and type in the corresponding Base Module or Incremental Module unless the Output -Parameter is of the type ‘comma_delimited_list’, then the corresponding input -parameter **MUST** be declared as type ‘json’. +Parameter is of the type 'comma_delimited_list', then the corresponding input +parameter **MUST** be declared as type 'json'. R-20547 When an ONAP Volume Module Output Parameter is declared as an input parameter in a base or an incremental module Heat Orchestration Template, parameter constraints **MUST NOT** be declared. R-39349 A VNF Heat Orchestration Template **MUST NOT** be designed to -utilize the OpenStack ‘heat stack-update’ command for scaling +utilize the OpenStack 'heat stack-update' command for scaling (growth/de-growth). R-43413 A VNF **MUST** utilize a modular Heat Orchestration Template design to support scaling (growth/de-growth). -R-59482 A VNF’s Heat Orchestration Template **MUST NOT** be VNF instance +R-59482 A VNF's Heat Orchestration Template **MUST NOT** be VNF instance specific or Cloud site specific -R-56750 A VNF’s Heat Orchestration Template’s parameter values that are +R-56750 A VNF's Heat Orchestration Template's parameter values that are constant across all deployments **MUST** be declared in a Heat Orchestration Template Environment File. -R-01896 A VNF’s Heat Orchestration Template’s parameter values that are +R-01896 A VNF's Heat Orchestration Template's parameter values that are constant across all deployments **MUST** be declared in a Heat Orchestration Template Environment File. -R-16968 A VNF’s Heat Orchestration Templates **MUST NOT** include heat +R-16968 A VNF's Heat Orchestration Templates **MUST NOT** include heat resources to create external networks. R-00606 A VNF **MAY** be connected to zero, one or more than one external networks. -R-57424 A VNF’s port connected to an external network **MUST** connect the +R-57424 A VNF's port connected to an external network **MUST** connect the port to VMs in another VNF and/or an external gateway and/or external router. -R-29865 A VNF’s port connected to an external network **MUST NOT** connect +R-29865 A VNF's port connected to an external network **MUST NOT** connect the port to VMs in the same VNF. R-69014 When a VNF connects to an external network, a network role, referred -to as the ‘{network-role}’ **MUST** be assigned to the external network -for use in the VNF’s Heat Orchestration Template. +to as the '{network-role}' **MUST** be assigned to the external network +for use in the VNF's Heat Orchestration Template. R-05201 When a VNF connects to two or more external networks, each external -network **MUST** be assigned a unique ‘{network-role}’ in the context of -the VNF for use in the VNF’s Heat Orchestration Template. +network **MUST** be assigned a unique '{network-role}' in the context of +the VNF for use in the VNF's Heat Orchestration Template. -R-83015 A VNF’s ‘{network-role}’ assigned to an external network **MUST** -be different than the ‘{network-role}’ assigned to the VNF’s internal +R-83015 A VNF's '{network-role}' assigned to an external network **MUST** +be different than the '{network-role}' assigned to the VNF's internal networks, if internal networks exist. R-87096 A VNF **MAY** contain zero, one or more than one internal networks. @@ -2135,40 +2139,41 @@ R-87096 A VNF **MAY** contain zero, one or more than one internal networks. R-35666 If a VNF has an internal network, the VNF Heat Orchestration Template **MUST** include the heat resources to create the internal network. -R-86972 A VNF **SHOULD** create the internal network in the VNF’s Heat +R-86972 A VNF **SHOULD** create the internal network in the VNF's Heat Orchestration Template Base Module. -R-52425 A VNF’s port connected to an internal network **MUST** connect +R-52425 A VNF's port connected to an internal network **MUST** connect the port to VMs in the same VNF. -R-46461 A VNF’s port connected to an internal network **MUST NOT** connect +R-46461 A VNF's port connected to an internal network **MUST NOT** connect the port to VMs in another VNF and/or an external gateway and/or external router. R-68936 When a VNF creates an internal network, a network role, referred to -as the ‘{network-role}’ **MUST** be assigned to the internal network for -use in the VNF’s Heat Orchestration Template. +as the '{network-role}' **MUST** be assigned to the internal network for +use in the VNF's Heat Orchestration Template. R-32025 When a VNF creates two or more internal networks, each internal -network **MUST** be assigned a unique ‘{network-role}’ in the context of -the VNF for use in the VNF’s Heat Orchestration Template. +network **MUST** be assigned a unique '{network-role}' in the context of +the VNF for use in the VNF's Heat Orchestration Template. -R-69874 A VNF’s ‘{network-role}’ assigned to an internal network **MUST** -be different than the ‘{network-role}’ assigned to the VNF’s external +R-69874 A VNF's '{network-role}' assigned to an internal network **MUST** +be different than the '{network-role}' assigned to the VNF's external networks. -R-34726 If a VNF’s port is connected to an internal network and the port +R-34726 If a VNF's port is connected to an internal network and the port is created in the same Heat Orchestration Template as the internal network, -then the port resource **MUST** use a ‘get_resource’ to obtain +then the port resource **MUST** use a 'get_resource' to obtain the network UUID. -R-22688 If a VNF’s port is connected to an internal network and the +R-22688 If a VNF's port is connected to an internal network and the port is created in an Incremental Module and the internal network is created in the Base Module then the UUID of the internal network **MUST** be exposed -as a parameter in the ‘outputs:’ section of the Base Module and the port -resource **MUST** use a ‘get_param’ to obtain the network UUID. +as a parameter in the 'outputs:' section of the Base Module and the port +resource **MUST** use a 'get_param' to obtain the network UUID. -R-01455 When a VNF's Heat Orchestration Template creates a Virtual Machine (i.e., 'OS::Nova::Server'), +R-01455 When a VNF's Heat Orchestration Template creates a +Virtual Machine (i.e., 'OS::Nova::Server'), each 'class' of VMs **MUST** be assigned a VNF unique '{vm-type}'; where 'class' defines VMs that **MUST** have the following identical characteristics: @@ -2179,9 +2184,9 @@ associated with a unique Virtual Machine type **MUST** include '{vm-type}' as part of the parameter name with two exceptions: -R-66729 A VNF’s Heat Orchestration Template’s Resource that is +R-66729 A VNF's Heat Orchestration Template's Resource that is associated with a unique Virtual Machine type **MUST** include -‘{vm-type}’ as part of the resource ID. +'{vm-type}' as part of the resource ID. R-98407 A VNF's Heat Orchestration Template's '{vm-type}' **MUST** contain only alphanumeric characters and/or underscores '_' and @@ -2191,18 +2196,19 @@ or '\_int\_'. R-48067 A VNF's Heat Orchestration Template's {vm-type} **MUST NOT** be a substring of {network-role}. -R-32394 A VNF’s Heat Orchestration Template’s use of ‘{vm-type}’ +R-32394 A VNF's Heat Orchestration Template's use of '{vm-type}' in all Resource property parameter names **MUST** be the same case. -R-46839 A VNF’s Heat Orchestration Template’s use of -‘{vm-type}’ in all Resource IDs **MUST** be the same case. +R-46839 A VNF's Heat Orchestration Template's use of +'{vm-type}' in all Resource IDs **MUST** be the same case. -R-36687 A VNF’s Heat Orchestration Template’s ‘{vm-type}’ case in +R-36687 A VNF's Heat Orchestration Template's '{vm-type}' case in Resource property parameter names **SHOULD** match the case of -‘{vm-type}’ in Resource IDs and vice versa. +'{vm-type}' in Resource IDs and vice versa. -R-21330 A VNF’s Heat Orchestration Template’s Resource property parameter -that is associated with external network **MUST** include the ‘{network-role}’’ as part of the parameter name +R-21330 A VNF's Heat Orchestration Template's Resource property +parameter that is associated with external network **MUST** +include the '{network-role}' as part of the parameter name R-11168 A VNF's Heat Orchestration Template's Resource ID that is associated with an external network **MUST** include the @@ -2223,29 +2229,29 @@ R-26506 A VNF's Heat Orchestration Template's '{network-role}' underscores '_' and **MUST NOT** contain any of the following strings: '_int' or 'int\_' or '\_int\_'. -R-00977 A VNF’s Heat Orchestration Template’s ‘{network-role}’ -**MUST NOT** be a substring of ‘{vm-type}’. +R-00977 A VNF's Heat Orchestration Template's '{network-role}' +**MUST NOT** be a substring of '{vm-type}'. -R-58424 A VNF’s Heat Orchestration Template’s use of ‘{network-role}’ +R-58424 A VNF's Heat Orchestration Template's use of '{network-role}' in all Resource property parameter names **MUST** be the same case -R-21511 A VNF’s Heat Orchestration Template’s use of ‘{network-role}’ +R-21511 A VNF's Heat Orchestration Template's use of '{network-role}' in all Resource IDs **MUST** be the same case. -R-86588 A VNF’s Heat Orchestration Template’s ‘{network-role}’ case +R-86588 A VNF's Heat Orchestration Template's '{network-role}' case in Resource property parameter names **SHOULD** match the case -of ‘{network-role}’ in Resource IDs and vice versa. +of '{network-role}' in Resource IDs and vice versa. -R-54517 When a VNF’s Heat Orchestration Template’s resource is associated -with a single ‘{vm-type}’, the Resource ID **MUST** contain the ‘{vm-type}’. +R-54517 When a VNF's Heat Orchestration Template's resource is associated +with a single '{vm-type}', the Resource ID **MUST** contain the '{vm-type}'. -R-96482 When a VNF’s Heat Orchestration Template’s resource is associated +R-96482 When a VNF's Heat Orchestration Template's resource is associated with a single external network, the Resource ID MUST contain the text -‘{network-role}’. +'{network-role}'. -R-98138 When a VNF’s Heat Orchestration Template’s resource is associated +R-98138 When a VNF's Heat Orchestration Template's resource is associated with a single internal network, the Resource ID MUST contain the text -‘int\_{network-role}’. +'int\_{network-role}'. R-82115 When a VNF's Heat Orchestration Template's resource is associated with a single '{vm-type}' and a single external network, the Resource @@ -2267,463 +2273,472 @@ with a single '{vm-type}' and a single internal network, the Resource ID - the '{vm-type}' **MUST** appear before the 'int\_{network-role}' and **MUST** be separated by an underscore '_' - - (e.g., '{vm-type}\_int\_{network-role}', '{vm-type}_{index}\_int\_{network-role}') + - (e.g., '{vm-type}\_int\_{network-role}', + '{vm-type}_{index}\_int\_{network-role}') - note that an '{index}' value **MAY** separate the '{vm-type}' and the 'int\_{network-role}' and when this occurs underscores **MUST** separate the three values. -R-67793 When a VNF’s Heat Orchestration Template’s resource is associated -with more than one ‘{vm-type}’ and/or more than one internal and/or -external network, the Resource ID **MUST NOT** contain the ‘{vm-type}’ -and/or ‘{network-role}’/’int\_{network-role}’. It also should contain the -term ‘shared’ and/or contain text that identifies the VNF +R-67793 When a VNF's Heat Orchestration Template's resource is associated +with more than one '{vm-type}' and/or more than one internal and/or +external network, the Resource ID **MUST NOT** contain the '{vm-type}' +and/or '{network-role}'/'int\_{network-role}'. It also should contain the +term 'shared' and/or contain text that identifies the VNF -R-27970 When a VNF’s Heat Orchestration Template’s resource is associated -with more than one ‘{vm-type}’ and/or more than one internal and/or -external network, the Resource ID **MAY** contain the term ‘shared’ +R-27970 When a VNF's Heat Orchestration Template's resource is associated +with more than one '{vm-type}' and/or more than one internal and/or +external network, the Resource ID **MAY** contain the term 'shared' and/or **MAY** contain text that identifies the VNF. -R-11690 When a VNF’s Heat Orchestration Template’s Resource ID contains -an {index} value (e.g. multiple VMs of same {vm-type}), the ‘{index}’ +R-11690 When a VNF's Heat Orchestration Template's Resource ID contains +an {index} value (e.g. multiple VMs of same {vm-type}), the '{index}' **MUST** start at zero and increment by one. -R-71152 The VNF’s Heat Orchestration Template’s Resource -‘OS::Nova::Server’ property ‘image’ parameter **MUST** be declared as -type: ‘string’. +R-71152 The VNF's Heat Orchestration Template's Resource +'OS::Nova::Server' property 'image' parameter **MUST** be declared as +type: 'string'. -R-58670 The VNF’s Heat Orchestration Template’s Resource -‘OS::Nova::Server’ property ‘image’ parameter name **MUST** follow the -naming convention ‘{vm-type}_image_name’. +R-58670 The VNF's Heat Orchestration Template's Resource +'OS::Nova::Server' property 'image' parameter name **MUST** follow the +naming convention '{vm-type}_image_name'. -R-91125 The VNF’s Heat Orchestration Template’s Resource -‘OS::Nova::Server’ property ‘image’ parameter **MUST** be enumerated in -the Heat Orchestration Template’s Environment File and a value **MUST** be +R-91125 The VNF's Heat Orchestration Template's Resource +'OS::Nova::Server' property 'image' parameter **MUST** be enumerated in +the Heat Orchestration Template's Environment File and a value **MUST** be assigned. -R-57282 Each VNF’s Heat Orchestration Template’s ‘{vm-type}’ -**MUST** have a unique parameter name for the ‘OS::Nova::Server’ -property ‘image’ even if more than one {vm-type} shares the same image. +R-57282 Each VNF's Heat Orchestration Template's '{vm-type}' +**MUST** have a unique parameter name for the 'OS::Nova::Server' +property 'image' even if more than one {vm-type} shares the same image. -R-50436 The VNF’s Heat Orchestration Template’s Resource -‘OS::Nova::Server’ property ‘flavor’ parameter **MUST** be declared as -type: ‘string’. +R-50436 The VNF's Heat Orchestration Template's Resource +'OS::Nova::Server' property 'flavor' parameter **MUST** be declared as +type: 'string'. -R-45188 The VNF’s Heat Orchestration Template’s Resource -‘OS::Nova::Server’ property ‘flavor’ parameter name **MUST** follow the -naming convention ‘{vm-type}_flavor_name’. +R-45188 The VNF's Heat Orchestration Template's Resource +'OS::Nova::Server' property 'flavor' parameter name **MUST** follow the +naming convention '{vm-type}_flavor_name'. -R-69431 The VNF’s Heat Orchestration Template’s Resource -‘OS::Nova::Server’ property ‘flavor’ parameter **MUST** be enumerated in the -Heat Orchestration Template’s Environment File and a value **MUST** be +R-69431 The VNF's Heat Orchestration Template's Resource +'OS::Nova::Server' property 'flavor' parameter **MUST** be enumerated in the +Heat Orchestration Template's Environment File and a value **MUST** be assigned. -R-40499 Each VNF’s Heat Orchestration Template’s ‘{vm-type}’ **MUST** -have a unique parameter name for the ‘OS::Nova::Server’ property -‘flavor’ even if more than one {vm-type} shares the same flavor. +R-40499 Each VNF's Heat Orchestration Template's '{vm-type}' **MUST** +have a unique parameter name for the 'OS::Nova::Server' property +'flavor' even if more than one {vm-type} shares the same flavor. -R-51430 The VNF’s Heat Orchestration Template’s Resource -‘OS::Nova::Server’ property ‘name’ parameter **MUST** be declared as -either type ‘string’ or type ‘comma_delimited_list”. +R-51430 The VNF's Heat Orchestration Template's Resource +'OS::Nova::Server' property 'name' parameter **MUST** be declared as +either type 'string' or type 'comma_delimited_list". -R-54171 When the VNF’s Heat Orchestration Template’s Resource -‘OS::Nova::Server’ property ‘name’ parameter is defined as a ‘string’, +R-54171 When the VNF's Heat Orchestration Template's Resource +'OS::Nova::Server' property 'name' parameter is defined as a 'string', the parameter name **MUST** follow the naming convention -‘{vm-type}\_name\_{index}’, where {index} is a numeric value that starts +'{vm-type}\_name\_{index}', where {index} is a numeric value that starts at zero and increments by one. -R-40899 When the VNF’s Heat Orchestration Template’s Resource -‘OS::Nova::Server’ property ‘name’ parameter is defined as a ‘string’, -a parameter **MUST** be declared for each ‘OS::Nova::Server’ resource -associated with the ‘{vm-type}’. - -R-87817 When the VNF’s Heat Orchestration Template’s Resource -‘OS::Nova::Server’ property ‘name’ parameter is defined as a -‘comma_delimited_list’, the parameter name **MUST** follow the naming -convention ‘{vm-type}_names’. - -R-85800 When the VNF’s Heat Orchestration Template’s Resource -‘OS::Nova::Server’ property ‘name’ parameter is defined as a -‘comma_delimited_list’, a parameter **MUST** be delcared once for all -‘OS::Nova::Server’ resources associated with the ‘{vm-type}’. - -R-22838 The VNF’s Heat Orchestration Template’s Resource -‘OS::Nova::Server’ property ‘name’ parameter **MUST NOT** be enumerated -in the Heat Orchestration Template’s Environment File. - -R-44271 The VNF's Heat Orchestration Template's Resource 'OS::Nova::Server' property -'name' parameter value **SHOULD NOT** contain special characters -since the Contrail GUI has a limitation displaying special characters. - -R-98450 The VNF’s Heat Orchestration Template’s Resource -‘OS::Nova::Server’ property ‘availability_zone’ parameter name -**MUST** follow the naming convention ‘availability\_zone\_{index}’ -where the ‘{index}’ **MUST** start at zero and increment by one. - -R-23311 The VNF’s Heat Orchestration Template’s Resource -‘OS::Nova::Server’ property ‘availability_zone’ parameter **MUST** -be declared as type: ‘string’. - -R-59568 The VNF’s Heat Orchestration Template’s Resource -‘OS::Nova::Server’ property ‘availability_zone’ parameter **MUST NOT** -be enumerated in the Heat Orchestration Template’s Environment File. - -R-01359 A VNF’s Heat Orchstration Template that contains an -‘OS::Nova:Server’ Resource **MAY** define a parameter for the property -‘availability_zone’ that is not utilized in any ‘OS::Nova::Server’ +R-40899 When the VNF's Heat Orchestration Template's Resource +'OS::Nova::Server' property 'name' parameter is defined as a 'string', +a parameter **MUST** be declared for each 'OS::Nova::Server' resource +associated with the '{vm-type}'. + +R-87817 When the VNF's Heat Orchestration Template's Resource +'OS::Nova::Server' property 'name' parameter is defined as a +'comma_delimited_list', the parameter name **MUST** follow the naming +convention '{vm-type}_names'. + +R-85800 When the VNF's Heat Orchestration Template's Resource +'OS::Nova::Server' property 'name' parameter is defined as a +'comma_delimited_list', a parameter **MUST** be delcared once for all +'OS::Nova::Server' resources associated with the '{vm-type}'. + +R-22838 The VNF's Heat Orchestration Template's Resource +'OS::Nova::Server' property 'name' parameter **MUST NOT** be enumerated +in the Heat Orchestration Template's Environment File. + +R-44271 The VNF's Heat Orchestration Template's Resource +'OS::Nova::Server' property 'name' parameter value **SHOULD NOT** +contain special characters since the Contrail GUI has a limitation +displaying special characters. + +R-98450 The VNF's Heat Orchestration Template's Resource +'OS::Nova::Server' property 'availability_zone' parameter name +**MUST** follow the naming convention 'availability\_zone\_{index}' +where the '{index}' **MUST** start at zero and increment by one. + +R-23311 The VNF's Heat Orchestration Template's Resource +'OS::Nova::Server' property 'availability_zone' parameter **MUST** +be declared as type: 'string'. + +R-59568 The VNF's Heat Orchestration Template's Resource +'OS::Nova::Server' property 'availability_zone' parameter **MUST NOT** +be enumerated in the Heat Orchestration Template's Environment File. + +R-01359 A VNF's Heat Orchstration Template that contains an +'OS::Nova:Server' Resource **MAY** define a parameter for the property +'availability_zone' that is not utilized in any 'OS::Nova::Server' resources in the Heat Orchestration Template. -R-99798 A VNF’s Heat Orchestration Template’s Virtual Machine +R-99798 A VNF's Heat Orchestration Template's Virtual Machine (i.e., OS::Nova::Server Resource) **MAY** boot from an image or **MAY** boot from a Cinder Volume. -R-83706 When a VNF’s Heat Orchestration Template’s Virtual Machine -(i.e., ‘OS::Nova::Server’ Resource) boots from an image, the -‘OS::Nova::Server’ resource property ‘image’ **MUST** be used. +R-83706 When a VNF's Heat Orchestration Template's Virtual Machine +(i.e., 'OS::Nova::Server' Resource) boots from an image, the +'OS::Nova::Server' resource property 'image' **MUST** be used. -R-69588 When a VNF’s Heat Orchestration Template’s Virtual Machine -(i.e., ‘OS::Nova::Server’ Resource) boots from Cinder Volume, the -‘OS::Nova::Server’ resource property ‘block_device_mapping’ or -‘block_device_mapping_v2’ **MUST** be used. +R-69588 When a VNF's Heat Orchestration Template's Virtual Machine +(i.e., 'OS::Nova::Server' Resource) boots from Cinder Volume, the +'OS::Nova::Server' resource property 'block_device_mapping' or +'block_device_mapping_v2' **MUST** be used. -R-37437 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource **MUST** contain the metadata map value parameter ‘vnf_id’. +R-37437 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource **MUST** contain the metadata map value parameter 'vnf_id'. -R-07507 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vnf_id’ **MUST** be declared -as type: ‘string’. +R-07507 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vnf_id' **MUST** be declared +as type: 'string'. -R-55218 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vnf_id’ **MUST NOT** have +R-55218 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vnf_id' **MUST NOT** have parameter contraints defined. -R-20856 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vnf_id’ **MUST NOT** be -enumerated in the Heat Orchestration Template’s environment file. +R-20856 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vnf_id' **MUST NOT** be +enumerated in the Heat Orchestration Template's environment file. -R-44491 If a VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vnf_id’ is passed into a -Nested YAML file, the parameter name ‘vnf_id’ **MUST NOT** change. +R-44491 If a VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vnf_id' is passed into a +Nested YAML file, the parameter name 'vnf_id' **MUST NOT** change. -R-71493 A VNF’s Heat Orchestration Template’s OS::Nova::Server +R-71493 A VNF's Heat Orchestration Template's OS::Nova::Server Resource **MUST** contain the metadata map value parameter -‘vf\_module\_id’. +'vf\_module\_id'. -R-82134 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vf\_module\_id’ **MUST** -be declared as type: ‘string’. +R-82134 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vf\_module\_id' **MUST** +be declared as type: 'string'. -R-98374 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vf\_module\_id’ **MUST NOT** +R-98374 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vf\_module\_id' **MUST NOT** have parameter contraints defined. -R-72871 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vf\_module\_id’ **MUST NOT** -be enumerated in the Heat Orchestration Template’s environment file. +R-72871 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vf\_module\_id' **MUST NOT** +be enumerated in the Heat Orchestration Template's environment file. -R-86237 If a VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vf_module_id’ is passed -into a Nested YAML file, the parameter name ‘vf\_module\_id’ +R-86237 If a VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vf_module_id' is passed +into a Nested YAML file, the parameter name 'vf\_module\_id' **MUST NOT** change. -R-72483 A VNF’s Heat Orchestration Template’s OS::Nova::Server +R-72483 A VNF's Heat Orchestration Template's OS::Nova::Server Resource **MUST** contain the metadata map value parameter -‘vnf_name’. +'vnf_name'. -R-62428 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vnf_name’ **MUST** be -declared as type: ‘string’. +R-62428 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vnf_name' **MUST** be +declared as type: 'string'. -R-44318 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vnf_name’ **MUST NOT** have +R-44318 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vnf_name' **MUST NOT** have parameter contraints defined. -R-36542 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vnf_name’ **MUST NOT** be -enumerated in the Heat Orchestration Template’s environment file. +R-36542 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vnf_name' **MUST NOT** be +enumerated in the Heat Orchestration Template's environment file. -R-16576 If a VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vnf_name’ is passed into a -Nested YAML file, the parameter name ‘vnf_name’ **MUST NOT** change. +R-16576 If a VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vnf_name' is passed into a +Nested YAML file, the parameter name 'vnf_name' **MUST NOT** change. -R-68023 A VNF’s Heat Orchestration Template’s OS::Nova::Server +R-68023 A VNF's Heat Orchestration Template's OS::Nova::Server Resource **SHOULD** contain the metadata map value parameter -‘vf\_module\_name’. +'vf\_module\_name'. -R-39067 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vf\_module\_name’ **MUST** -be declared as type: ‘string’. +R-39067 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vf\_module\_name' **MUST** +be declared as type: 'string'. -R-15480 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vf\_module\_name’ +R-15480 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vf\_module\_name' **MUST NOT** have parameter contraints defined. -R-80374 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vf\_module\_name’ -**MUST NOT** be enumerated in the Heat Orchestration Template’s +R-80374 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vf\_module\_name' +**MUST NOT** be enumerated in the Heat Orchestration Template's environment file. -R-49177 If a VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vf\_module\_name’ is passed -into a Nested YAML file, the parameter name ‘vf\_module\_name’ +R-49177 If a VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vf\_module\_name' is passed +into a Nested YAML file, the parameter name 'vf\_module\_name' **MUST NOT** change. -R-85328 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource **MAY** contain the metadata map value parameter ‘vm_role’. +R-85328 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource **MAY** contain the metadata map value parameter 'vm_role'. -R-95430 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vm_role’ **MUST** be -declared as type: ‘string’. +R-95430 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vm_role' **MUST** be +declared as type: 'string'. -R-67597 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vm_role’ **MUST NOT** have +R-67597 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vm_role' **MUST NOT** have parameter contraints defined. -R-46823 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vnf_name’ **MUST** be +R-46823 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vnf_name' **MUST** be either - - enumerated in the VNF’s Heat Orchestration - Template’s environment file. + - enumerated in the VNF's Heat Orchestration + Template's environment file. - - hard coded in the VNF’s Heat Orchestration - Template’s OS::Nova::Resource metadata property. + - hard coded in the VNF's Heat Orchestration + Template's OS::Nova::Resource metadata property. -R-86476 If a VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vm_role’ value **MUST only** -contain alphanumeric characters and underscores ‘_’. +R-86476 If a VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vm_role' value **MUST only** +contain alphanumeric characters and underscores '_'. -R-70757 If a VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vm_role’ is passed into a -Nested YAML file, the parameter name ‘vm_role’ **MUST NOT** change. +R-70757 If a VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vm_role' is passed into a +Nested YAML file, the parameter name 'vm_role' **MUST NOT** change. -R-50816 A VNF’s Heat Orchestration Template’s OS::Nova::Server +R-50816 A VNF's Heat Orchestration Template's OS::Nova::Server Resource **MAY** contain the metadata map value parameter -‘vf\_module\_index’. +'vf\_module\_index'. -R-54340 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vf\_module\_index’ **MUST** be -declared as type: ‘number’. +R-54340 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vf\_module\_index' **MUST** be +declared as type: 'number'. -R-09811 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vf\_module\_index’ **MUST NOT** +R-09811 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vf\_module\_index' **MUST NOT** have parameter contraints defined. -R-37039 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vf\_module\_index’ **MUST NOT** -be enumerated in the Heat Orchestration Template’s environment file. +R-37039 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vf\_module\_index' **MUST NOT** +be enumerated in the Heat Orchestration Template's environment file. -R-22441 If a VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vf\_module\_index’ is passed -into a Nested YAML file, the parameter name ‘vf\_module\_index’ +R-22441 If a VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vf\_module\_index' is passed +into a Nested YAML file, the parameter name 'vf\_module\_index' **MUST NOT** change. -R-55306 If a VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘vf\_module\_index’ **MUST NOT** be -used in a VNF’s Volume Template; it is not supported. +R-55306 If a VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'vf\_module\_index' **MUST NOT** be +used in a VNF's Volume Template; it is not supported. -R-47061 A VNF’s Heat Orchestration Template’s OS::Nova::Server +R-47061 A VNF's Heat Orchestration Template's OS::Nova::Server Resource **SHOULD** contain the metadata map value parameter -‘workload_context’. +'workload_context'. -R-74978 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘workload_context’ **MUST** be -declared as type: ‘string’. +R-74978 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'workload_context' **MUST** be +declared as type: 'string'. -R-34055 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘workload_context’ **MUST NOT** +R-34055 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'workload_context' **MUST NOT** have parameter contraints defined. -R-02691 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘workload_context’ **MUST NOT** -be enumerated in the Heat Orchestration Template’s environment file. +R-02691 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'workload_context' **MUST NOT** +be enumerated in the Heat Orchestration Template's environment file. -R-75202 If a VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘workload_context’ is passed -into a Nested YAML file, the parameter name ‘workload_context’ +R-75202 If a VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'workload_context' is passed +into a Nested YAML file, the parameter name 'workload_context' **MUST NOT** change. -R-88536 A VNF’s Heat Orchestration Template’s OS::Nova::Server +R-88536 A VNF's Heat Orchestration Template's OS::Nova::Server Resource **SHOULD** contain the metadata map value parameter -‘environment_context’. +'environment_context'. -R-20308 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘environment_context’ **MUST** -be declared as type: ‘string’. +R-20308 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'environment_context' **MUST** +be declared as type: 'string'. -R-56183 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘environment_context’ **MUST NOT** +R-56183 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'environment_context' **MUST NOT** have parameter contraints defined. -R-13194 A VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘environment_context’ **MUST NOT** -be enumerated in the Heat Orchestration Template’s environment file. +R-13194 A VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'environment_context' **MUST NOT** +be enumerated in the Heat Orchestration Template's environment file. -R-62954 If a VNF’s Heat Orchestration Template’s OS::Nova::Server -Resource metadata map value parameter ‘environment_context’ is +R-62954 If a VNF's Heat Orchestration Template's OS::Nova::Server +Resource metadata map value parameter 'environment_context' is passed into a Nested YAML file, the parameter name -‘environment_context’ **MUST NOT** change. +'environment_context' **MUST NOT** change. -R-18008 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ -property ‘network’ parameter **MUST** be declared as type: ‘string’. +R-18008 The VNF's Heat Orchestration Template's Resource 'OS::Neutron::Port' +property 'network' parameter **MUST** be declared as type: 'string'. -R-62983 When the VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ -is attaching to an external network, the ‘network’ parameter name **MUST** +R-62983 When the VNF's Heat Orchestration Template's Resource 'OS::Neutron::Port' +is attaching to an external network, the 'network' parameter name **MUST** -- follow the naming convention ‘{network-role}_net_id’ if the Neutron +- follow the naming convention '{network-role}_net_id' if the Neutron network UUID value is used to reference the network -- follow the naming convention ‘{network-role}_net_name’ if the OpenStack +- follow the naming convention '{network-role}_net_name' if the OpenStack network name is used to reference the network. -where ‘{network-role}’ is the network-role of the external network and -a ‘get_param’ **MUST** be used as the intrinsic function. +where '{network-role}' is the network-role of the external network and +a 'get_param' **MUST** be used as the intrinsic function. -R-86182 When the VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ +R-86182 When the VNF's Heat Orchestration Template's Resource 'OS::Neutron::Port' is attaching to an internal network, and the internal network is created in a different -Heat Orchestration Template than the ‘OS::Neutron::Port’, the ‘network’ +Heat Orchestration Template than the 'OS::Neutron::Port', the 'network' parameter name **MUST** -- follow the naming convention ‘int\_{network-role}_net_id’ if the Neutron +- follow the naming convention 'int\_{network-role}_net_id' if the Neutron network UUID value is used to reference the network -- follow the naming convention ‘int\_{network-role}_net_name’ if the +- follow the naming convention 'int\_{network-role}_net_name' if the OpenStack network name in is used to reference the network. -where ‘{network-role}’ is the network-role of the internal network and a ‘get_param’ **MUST** be used as the intrinsic function. +where '{network-role}' is the network-role of the internal network and a 'get_param' **MUST** be used as the intrinsic function. -R-93177 When the VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ -is attaching to an internal network, and the internal network is created in the same Heat -Orchestration Template than the ‘OS::Neutron::Port’, the ‘network’ +R-93177 When the VNF's Heat Orchestration Template's +Resource 'OS::Neutron::Port' is attaching to an internal +network, and the internal network is created in the same Heat +Orchestration Template than the 'OS::Neutron::Port', the 'network' parameter name **MUST** obtain the UUID of the internal network by using -the intrinsic function ‘get_resource’ or ‘get_attr’ and referencing the +the intrinsic function 'get_resource' or 'get_attr' and referencing the Resource ID of the internal network. -R-29872 The VNF’s Heat Orchestration Template’s Resource ‘OS::Nova::Server’ -property ‘network’ parameter **MUST NOT** be enumerated in the Heat -Orchestration Template’s Environment File. +R-29872 The VNF's Heat Orchestration Template's Resource 'OS::Nova::Server' +property 'network' parameter **MUST NOT** be enumerated in the Heat +Orchestration Template's Environment File. -R-34037 The VNF’s Heat Orchestration Template’s resource ‘OS::Neutron::Port’ -property ‘fixed_ips’ map property ‘ip_address’ parameter **MUST** be declared as -either type ‘string’ or type ‘comma_delimited_list’. +R-34037 The VNF's Heat Orchestration Template's resource 'OS::Neutron::Port' +property 'fixed_ips' map property 'ip_address' parameter **MUST** be +declared as either type 'string' or type 'comma_delimited_list'. -R-40971 When the VNF’s Heat Orchestration Template’s Resource -‘OS::Neutron::Port’ is attaching to an external network, and an IPv4 address is +R-40971 When the VNF's Heat Orchestration Template's Resource +'OS::Neutron::Port' is attaching to an external network, and an IPv4 address is assigned using the property -‘fixed_ips’ map property ‘ip_address’ and the parameter type is defined +'fixed_ips' map property 'ip_address' and the parameter type is defined as a string, the parameter name **MUST** follow the naming -convention ‘{vm-type}_{network-role}\_ip\_{index}’, where +convention '{vm-type}_{network-role}\_ip\_{index}', where -- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server -- ‘{network-role}’ is the {network-role} of the external network +- '{vm-type}' is the {vm-type} associated with the OS::Nova::Server +- '{network-role}' is the {network-role} of the external network - the value for {index} must start at zero (0) and increment by one -R-39841 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ -property ‘fixed_ips’ map property ‘ip_address’ parameter -‘{vm-type}_{network-role}\_ip\_{index}’ **MUST NOT** be enumerated in the -VNF’s Heat Orchestration Template’s Environment File. +R-39841 The VNF's Heat Orchestration Template's Resource 'OS::Neutron::Port' +property 'fixed_ips' map property 'ip_address' parameter +'{vm-type}_{network-role}\_ip\_{index}' **MUST NOT** be enumerated in the +VNF's Heat Orchestration Template's Environment File. -R-04697 When the VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ -is attaching to an external network, and an IPv4 address is assigned using -the property ‘fixed_ips’ map property ‘ip_address’ and the parameter type +R-04697 When the VNF's Heat Orchestration Template's +Resource 'OS::Neutron::Port' is attaching to an external +network, and an IPv4 address is assigned using +the property 'fixed_ips' map property 'ip_address' and the parameter type is defined as a comma_delimited_list, the parameter name **MUST** follow the -naming convention ‘{vm-type}_{network-role}_ips’, where +naming convention '{vm-type}_{network-role}_ips', where -- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server -- ‘{network-role}’ is the {network-role} of the external network +- '{vm-type}' is the {vm-type} associated with the OS::Nova::Server +- '{network-role}' is the {network-role} of the external network -R-98905 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ -property ‘fixed_ips’ map property ‘ip_address’ parameter -‘{vm-type}_{network-role}_ips’ **MUST NOT** be enumerated in the VNF’s -Heat Orchestration Template’s Environment File. +R-98905 The VNF's Heat Orchestration Template's Resource 'OS::Neutron::Port' +property 'fixed_ips' map property 'ip_address' parameter +'{vm-type}_{network-role}_ips' **MUST NOT** be enumerated in the VNF's +Heat Orchestration Template's Environment File. -R-71577 When the VNF’s Heat Orchestration Template’s Resource -‘OS::Neutron::Port’ is attaching to an external network, and an IPv6 address -is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and +R-71577 When the VNF's Heat Orchestration Template's Resource +'OS::Neutron::Port' is attaching to an external network, and an IPv6 address +is assigned using the property 'fixed_ips' map property 'ip_address' and the parameter type is defined as a string, the parameter name **MUST** follow -the naming convention ‘{vm-type}_{network-role}\_v6\_ip\_{index}’, where +the naming convention '{vm-type}_{network-role}\_v6\_ip\_{index}', where -- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server -- ‘{network-role}’ is the {network-role} of the external network +- '{vm-type}' is the {vm-type} associated with the OS::Nova::Server +- '{network-role}' is the {network-role} of the external network - the value for {index} must start at zero (0) and increment by one -R-87123 The VNF’s Heat Orchestration Template’s Resource -‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’ -parameter ‘{vm-type}_{network-role}\_v6\_ip\_{index}’ **MUST NOT** be enumerated -in the VNF’s Heat Orchestration Template’s Environment File. +R-87123 The VNF's Heat Orchestration Template's Resource +'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address' +parameter '{vm-type}_{network-role}\_v6\_ip\_{index}' +**MUST NOT** be enumerated in the VNF's Heat Orchestration +Template's Environment File. -R-23503 When the VNF’s Heat Orchestration Template’s Resource -‘OS::Neutron::Port’ is attaching to an external network, and an IPv6 -address is assigned using the property ‘fixed_ips’ map property ‘ip_address’ +R-23503 When the VNF's Heat Orchestration Template's Resource +'OS::Neutron::Port' is attaching to an external network, and an IPv6 +address is assigned using the property 'fixed_ips' map property 'ip_address' and the parameter type is defined as a comma_delimited_list, the parameter -name **MUST** follow the naming convention ‘{vm-type}_{network-role}_v6_ips’, where +name **MUST** follow the naming convention +'{vm-type}_{network-role}_v6_ips', where -- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server -- ‘{network-role}’ is the {network-role} of the external network +- '{vm-type}' is the {vm-type} associated with the OS::Nova::Server +- '{network-role}' is the {network-role} of the external network -R-93030 The VNF’s Heat Orchestration Template’s Resource -‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’ -parameter ‘{vm-type}_{network-role}_v6_ips’ **MUST NOT** be enumerated in the -VNF’s Heat Orchestration Template’s Environment File. +R-93030 The VNF's Heat Orchestration Template's Resource +'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address' +parameter '{vm-type}_{network-role}_v6_ips' **MUST NOT** be enumerated in the +VNF's Heat Orchestration Template's Environment File. -R-78380 When the VNF’s Heat Orchestration Template’s Resource -‘OS::Neutron::Port’ is attaching to an internal network, and an IPv4 address -is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and +R-78380 When the VNF's Heat Orchestration Template's Resource +'OS::Neutron::Port' is attaching to an internal network, and an IPv4 address +is assigned using the property 'fixed_ips' map property 'ip_address' and the parameter type is defined as a string, the parameter name **MUST** follow -the naming convention ‘{vm-type}\_int\_{network-role}\_ip\_{index}’, where +the naming convention '{vm-type}\_int\_{network-role}\_ip\_{index}', where -- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server -- ‘{network-role}’ is the {network-role} of the internal network +- '{vm-type}' is the {vm-type} associated with the OS::Nova::Server +- '{network-role}' is the {network-role} of the internal network - the value for {index} must start at zero (0) and increment by one -R-28795 The VNF’s Heat Orchestration Template’s Resource -‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’ -parameter ‘{vm-type}\_int\_{network-role}\_ip\_{index}’ **MUST** be enumerated -in the VNF’s Heat Orchestration Template’s Environment File. +R-28795 The VNF's Heat Orchestration Template's Resource +'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address' +parameter '{vm-type}\_int\_{network-role}\_ip\_{index}' **MUST** be enumerated +in the VNF's Heat Orchestration Template's Environment File. -R-85235 When the VNF’s Heat Orchestration Template’s Resource -‘OS::Neutron::Port’ is attaching to an internal network, and an IPv4 -address is assigned using the property ‘fixed_ips’ map property ‘ip_address’ +R-85235 When the VNF's Heat Orchestration Template's Resource +'OS::Neutron::Port' is attaching to an internal network, and an IPv4 +address is assigned using the property 'fixed_ips' map property 'ip_address' and the parameter type is defined as a comma_delimited_list, the parameter -name **MUST** follow the naming convention ‘{vm-type}\_int\_{network-role}_ips’, where +name **MUST** follow the naming convention +'{vm-type}\_int\_{network-role}_ips', where -- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server -- ‘{network-role}’ is the {network-role} of the internal network +- '{vm-type}' is the {vm-type} associated with the OS::Nova::Server +- '{network-role}' is the {network-role} of the internal network -R-90206 The VNF’s Heat Orchestration Template’s Resource -‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’ -parameter ‘{vm-type}\_int\_{network-role}_int_ips’ **MUST** be enumerated in -the VNF’s Heat Orchestration Template’s Environment File. +R-90206 The VNF's Heat Orchestration Template's Resource +'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address' +parameter '{vm-type}\_int\_{network-role}_int_ips' **MUST** be enumerated in +the VNF's Heat Orchestration Template's Environment File. -R-27818 When the VNF’s Heat Orchestration Template’s Resource -‘OS::Neutron::Port’ is attaching to an internal network, and an IPv6 address -is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and +R-27818 When the VNF's Heat Orchestration Template's Resource +'OS::Neutron::Port' is attaching to an internal network, and an IPv6 address +is assigned using the property 'fixed_ips' map property 'ip_address' and the parameter type is defined as a string, the parameter name **MUST** follow -the naming convention ‘{vm-type}\_int\_{network-role}\_v6\_ip\_{index}’, where +the naming convention '{vm-type}\_int\_{network-role}\_v6\_ip\_{index}', where -- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server -- ‘{network-role}’ is the {network-role} of the internal network +- '{vm-type}' is the {vm-type} associated with the OS::Nova::Server +- '{network-role}' is the {network-role} of the internal network - the value for {index} must start at zero (0) and increment by one -R-97201 The VNF’s Heat Orchestration Template’s Resource -‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’ -parameter ‘{vm-type}\_int\_{network-role}\_v6\_ip\_{index}’ **MUST** be enumerated -in the VNF’s Heat Orchestration Template’s Environment File. +R-97201 The VNF's Heat Orchestration Template's Resource +'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address' +parameter '{vm-type}\_int\_{network-role}\_v6\_ip\_{index}' +**MUST** be enumerated in the VNF's Heat Orchestration +Template's Environment File. -R-29765 When the VNF’s Heat Orchestration Template’s Resource -‘OS::Neutron::Port’ is attaching to an internal network, and an IPv6 -address is assigned using the property ‘fixed_ips’ map property ‘ip_address’ +R-29765 When the VNF's Heat Orchestration Template's Resource +'OS::Neutron::Port' is attaching to an internal network, and an IPv6 +address is assigned using the property 'fixed_ips' map property 'ip_address' and the parameter type is defined as a comma_delimited_list, the parameter -name **MUST** follow the naming convention ‘{vm-type}\_int\_{network-role}_v6_ips’, where +name **MUST** follow the naming convention +'{vm-type}\_int\_{network-role}_v6_ips', where -- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server -- ‘{network-role}’ is the {network-role} of the internal network +- '{vm-type}' is the {vm-type} associated with the OS::Nova::Server +- '{network-role}' is the {network-role} of the internal network -R-98569 The VNF’s Heat Orchestration Template’s Resource -‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’ -parameter ‘{vm-type}\_int\_{network-role}_v6_ips’ **MUST** be enumerated in -the VNF’s Heat Orchestration Template’s Environment File. +R-98569 The VNF's Heat Orchestration Template's Resource +'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address' +parameter '{vm-type}\_int\_{network-role}_v6_ips' **MUST** be enumerated in +the VNF's Heat Orchestration Template's Environment File. -R-62590 The VNF’s Heat Orchestration Template’s Resource -‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’ +R-62590 The VNF's Heat Orchestration Template's Resource +'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address' parameter associated with an external network, i.e., - {vm-type}_{network-role}\_ip\_{index} @@ -2731,11 +2746,12 @@ parameter associated with an external network, i.e., - {vm-type}_{network-role}_ips - {vm-type}_{network-role}_v6_ips -**MUST NOT** be enumerated in the Heat Orchestration Template’s Environment File. -ONAP provides the IP address assignments at orchestration time. +**MUST NOT** be enumerated in the Heat Orchestration Template's +Environment File. ONAP provides the IP address assignments at +orchestration time. -R-93496 The VNF’s Heat Orchestration Template’s Resource -‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’ +R-93496 The VNF's Heat Orchestration Template's Resource +'OS::Neutron::Port' property 'fixed_ips' map property 'ip_address' parameter associated with an internal network, i.e., - {vm-type}\_int\_{network-role}\_ip\_{index} @@ -2743,113 +2759,115 @@ parameter associated with an internal network, i.e., - {vm-type}\_int\_{network-role}_ips - {vm-type}\_int\_{network-role}_v6_ips -**MUST** be enumerated in the Heat Orchestration Template’s Environment +**MUST** be enumerated in the Heat Orchestration Template's Environment File and IP addresses **MUST** be assigned. -R-38236 The VNF’s Heat Orchestration Template’s resource -‘OS::Neutron::Port’ property ‘fixed_ips’ map property -‘subnet’/’subnet_id’ parameter **MUST** be declared type ‘string’. +R-38236 The VNF's Heat Orchestration Template's resource +'OS::Neutron::Port' property 'fixed_ips' map property +'subnet'/'subnet_id' parameter **MUST** be declared type 'string'. -R-62802 When the VNF’s Heat Orchestration Template’s resource -‘OS::Neutron::Port’ is attaching to an external network, and an IPv4 -address is being Cloud Assigned by OpenStack’s DHCP Service and the +R-62802 When the VNF's Heat Orchestration Template's resource +'OS::Neutron::Port' is attaching to an external network, and an IPv4 +address is being Cloud Assigned by OpenStack's DHCP Service and the external network IPv4 subnet is to be specified using the property -‘fixed_ips’ map property ‘subnet’/’subnet_id’, the parameter **MUST** -follow the naming convention ‘{network-role}_subnet_id’, where -‘{network-role}’ is the network role of the network. - -R-83677 The VNF’s Heat Orchestration Template’s Resource -‘OS::Neutron::Port’ property ‘fixed_ips’ map property -subnet’/’subnet_id’ parameter ‘{network-role}_subnet_id’ -**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s +'fixed_ips' map property 'subnet'/'subnet_id', the parameter **MUST** +follow the naming convention '{network-role}_subnet_id', where +'{network-role}' is the network role of the network. + +R-83677 The VNF's Heat Orchestration Template's Resource +'OS::Neutron::Port' property 'fixed_ips' map property +subnet'/'subnet_id' parameter '{network-role}_subnet_id' +**MUST NOT** be enumerated in the VNF's Heat Orchestration Template's Environment File. -R-15287 When the VNF’s Heat Orchestration Template’s resource -‘OS::Neutron::Port’ is attaching to an external network, and an IPv6 -address is being Cloud Assigned by OpenStack’s DHCP Service and the +R-15287 When the VNF's Heat Orchestration Template's resource +'OS::Neutron::Port' is attaching to an external network, and an IPv6 +address is being Cloud Assigned by OpenStack's DHCP Service and the external network IPv6 subnet is to be specified using the property -‘fixed_ips’ map property ‘subnet’/’subnet_id’, the parameter **MUST** -follow the naming convention ‘{network-role}_subnet_v6_id’, where -‘{network-role}’ is the network role of the network. - -R-80829 The VNF’s Heat Orchestration Template’s Resource -‘OS::Neutron::Port’ property ‘fixed_ips’ map property -subnet’/’subnet_id’ parameter ‘{network-role}_subnet_v6_id’ -**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s +'fixed_ips' map property 'subnet'/'subnet_id', the parameter **MUST** +follow the naming convention '{network-role}_subnet_v6_id', where +'{network-role}' is the network role of the network. + +R-80829 The VNF's Heat Orchestration Template's Resource +'OS::Neutron::Port' property 'fixed_ips' map property +subnet'/'subnet_id' parameter '{network-role}_subnet_v6_id' +**MUST NOT** be enumerated in the VNF's Heat Orchestration Template's Environment File. R-84123 When -- the VNF’s Heat Orchestration Template’s resource ‘OS::Neutron::Port’ +- the VNF's Heat Orchestration Template's resource 'OS::Neutron::Port' in an Incremental Module is attaching to an internal network that is created in the Base Module, AND -- an IPv4 address is being Cloud Assigned by OpenStack’s DHCP Service AND +- an IPv4 address is being Cloud Assigned by OpenStack's DHCP Service AND - the internal network IPv4 subnet is to be specified using the - property ‘fixed_ips’ map property ‘subnet’/’subnet_id’, + property 'fixed_ips' map property 'subnet'/'subnet_id', the parameter **MUST** follow the naming convention -‘int\_{network-role}_subnet_id’, where ‘{network-role}’ is the +'int\_{network-role}_subnet_id', where '{network-role}' is the network role of the internal network -- Note that the parameter **MUST** be defined as an ‘output’ parameter in +- Note that the parameter **MUST** be defined as an 'output' parameter in the base module. -R-69634 The VNF’s Heat Orchestration Template’s Resource -‘OS::Neutron::Port’ property ‘fixed_ips’ map property -subnet’/’subnet_id’ parameter ‘int\_{network-role}_subnet_id’ -**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s +R-69634 The VNF's Heat Orchestration Template's Resource +'OS::Neutron::Port' property 'fixed_ips' map property +subnet'/'subnet_id' parameter 'int\_{network-role}_subnet_id' +**MUST NOT** be enumerated in the VNF's Heat Orchestration Template's Environment File. R-76160 When -- the VNF’s Heat Orchestration Template’s resource - ‘OS::Neutron::Port’ in an Incremental Module is attaching to an +- the VNF's Heat Orchestration Template's resource + 'OS::Neutron::Port' in an Incremental Module is attaching to an internal network that is created in the Base Module, AND -- an IPv6 address is being Cloud Assigned by OpenStack’s DHCP Service AND +- an IPv6 address is being Cloud Assigned by OpenStack's DHCP Service AND - the internal network IPv6 subnet is to be specified using the property - ‘fixed_ips’ map property ‘subnet’/’subnet_id’, + 'fixed_ips' map property 'subnet'/'subnet_id', the parameter **MUST** follow the naming convention -‘int\_{network-role}_v6_subnet_id’, where ‘{network-role}’ +'int\_{network-role}_v6_subnet_id', where '{network-role}' is the network role of the internal network -- Note that the parameter **MUST** be defined as an ‘output’ parameter in +- Note that the parameter **MUST** be defined as an 'output' parameter in the base module. -R-22288 The VNF’s Heat Orchestration Template’s Resource -‘OS::Neutron::Port’ property ‘fixed_ips’ map property -‘subnet’/’subnet_id’ parameter ‘int\_{network-role}_v6_subnet_id’ -**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s +R-22288 The VNF's Heat Orchestration Template's Resource +'OS::Neutron::Port' property 'fixed_ips' map property +'subnet'/'subnet_id' parameter 'int\_{network-role}_v6_subnet_id' +**MUST NOT** be enumerated in the VNF's Heat Orchestration Template's Environment File. R-61282 The VNF Heat Orchestration Template **MUST** adhere to the following naming convention for the property allowed\_address\_pairs and Map Property ip\_address parameter, -when the parameter is referencing an “external” network: +when the parameter is referencing an "external" network: - {vm-type}\_{network-role}\_floating\_ip for an IPv4 address - {vm-type}\_{network-role}\_floating\_v6\_ip for an IPv6 address -R-16805 The VNF Heat Orchestration Template **MUST** adhere to the following naming convention -for the property allowed\_address\_pairs and Map Property ip\_address -parameter when the parameter is referencing an “internal” network. +R-16805 The VNF Heat Orchestration Template **MUST** adhere to the +following naming convention for the property allowed\_address\_pairs +and Map Property ip\_address parameter when the parameter is +referencing an "internal" network. -R-85734 The VNF Heat Orchestration Template **MUST** use the intrinsic function str\_replace -in conjunction with the ONAP supplied metadata parameter -vnf\_name to generate a unique value, -when the property name for a non OS::Nova::Server resources is defined -in a Heat Orchestration Template. +R-85734 The VNF Heat Orchestration Template **MUST** use the +intrinsic function str\_replace in conjunction with the ONAP +supplied metadata parameter vnf\_name to generate a unique +value, when the property name for a non OS::Nova::Server +resources is defined in a Heat Orchestration Template. -R-47788 The VNF Heat Orchestration Template **MUST** have a 1:1 scope of a cinder volume module, -when it exists, with the Base Module or Incremental Module +R-47788 The VNF Heat Orchestration Template **MUST** have a 1:1 +scope of a cinder volume module, when it exists, with the Base +Module or Incremental Module R-86285 The VNF Heat Orchestration Template **MUST** have a corresponding environment file, even if no parameters are required to be enumerated. R-86285 The VNF Heat Orchestration Template **MUST** have a -corresponding environment file, even if no parameters are required to be -enumerated. +corresponding environment file, even if no parameters are required +to be enumerated. R-67205 The VNF Heat Orchestration Template **MUST** have a corresponding environment file for a Base Module. @@ -2857,24 +2875,25 @@ environment file for a Base Module. R-35727 The VNF Heat Orchestration Template **MUST** have a corresponding environment file for an Incremental module. -R-22656 The VNF Heat Orchestration Template **MUST** have a corresponding environment file -for a Cinder Volume Module. +R-22656 The VNF Heat Orchestration Template **MUST** have a +corresponding environment file for a Cinder Volume Module. -R-89868 The VNF Heat Orchestration Template **MUST** have unique file names within the scope -of the VNF for a nested heat yaml file. +R-89868 The VNF Heat Orchestration Template **MUST** have unique +file names within the scope of the VNF for a nested heat yaml file. -R-52530 The VNF Heat Orchestration Template **MUST NOT** use a directory hierarchy for -nested templates. All templates must be in a single, flat directory -(per VNF). +R-52530 The VNF Heat Orchestration Template **MUST NOT** use a +directory hierarchy for nested templates. All templates must be +in a single, flat directory (per VNF). -R-76718 The VNF Heat Orchestration Template **MUST** reference the get\_files targets in -Heat templates by file name, and the corresponding files should be -delivered to ONAP along with the Heat templates. +R-76718 The VNF Heat Orchestration Template **MUST** reference +the get\_files targets in Heat templates by file name, and the +corresponding files should be delivered to ONAP along with the +Heat templates. R-41888 The VNE Heat **MUST NOT** use URL-based file retrieval. -R-62177 The VNF Heat Orchestration Template **MUST** have unique file names for the included -files within the scope of the VNF. +R-62177 The VNF Heat Orchestration Template **MUST** have unique +file names for the included files within the scope of the VNF. **ONAP Management Requirements** ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -2941,7 +2960,8 @@ on the appropriate Chef Server. R-18525 The xNF provider **MUST** provide a JSON file for each supported action for the xNF. The JSON file must contain key value pairs with all relevant values populated with sample data that illustrates -its usage. The fields and their description are defined in Tables A1 and A2 in the Appendix. +its usage. The fields and their description are defined in Tables A1 and +A2 in the Appendix. R-75608 The xNF provider **MUST** provide playbooks to be loaded on the appropriate Ansible Server. @@ -2949,7 +2969,8 @@ on the appropriate Ansible Server. R-16777 The xNF provider **MUST** provide a JSON file for each supported action for the xNF. The JSON file must contain key value pairs with all relevant values populated with sample data that illustrates -its usage. The fields and their description are defined in Table B1 in the Appendix. +its usage. The fields and their description are defined in Table B1 in +the Appendix. R-46567 The xNF Package **MUST** include configuration scripts for boot sequence and configuration. @@ -3087,7 +3108,7 @@ R-40827 The xNF provider **MUST** enumerate all of the open source licenses their xNF(s) incorporate. R-97293 The xNF provider **MUST NOT** require audits of -Service Provider’s business. +Service Provider's business. R-44569 The xNF provider **MUST NOT** require additional infrastructure such as a xNF provider license server for xNF provider @@ -3098,7 +3119,7 @@ purposes to allow automated scale up/down by the management system. R-27511 The VNF provider **MUST** provide the ability to scale up a VNF provider supplied product during growth and scale down a -VNF provider supplied product during decline without “real-time” +VNF provider supplied product during decline without "real-time" restrictions based upon VNF provider permissions. R-85991 The xNF provider **MUST** provide a universal license key @@ -3115,65 +3136,65 @@ use of the xNF software. This metadata will be used to facilitate onboarding the xNF into the ONAP environment and automating processes for putting the licenses into use and managing the full lifecycle of the licenses. The details of this license model are described in -Tables C1 to C8 in the Appendix. Note: License metadata support in - ONAP is not currently available and planned for 1Q 2018. +Tables C1 to C8 in the Appendix. Note: License metadata support in +ONAP is not currently available and planned for 1Q 2018. Configuration Management ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -R-20741 The xNF **MUST** support ONAP Controller’s **Configure** command. +R-20741 The xNF **MUST** support ONAP Controller's **Configure** command. -R-19366 The xNF **MUST** support ONAP Controller’s **ConfigModify** command. +R-19366 The xNF **MUST** support ONAP Controller's **ConfigModify** command. -R-32981 The xNF **MUST** support ONAP Controller’s **ConfigBackup** command. +R-32981 The xNF **MUST** support ONAP Controller's **ConfigBackup** command. -R-48247 The xNF **MUST** support ONAP Controller’s **ConfigRestore** command. +R-48247 The xNF **MUST** support ONAP Controller's **ConfigRestore** command. -R-94084 The xNF **MUST** support ONAP Controller’s **ConfigScaleOut** +R-94084 The xNF **MUST** support ONAP Controller's **ConfigScaleOut** command. -R-56385 The xNF **MUST** support ONAP Controller’s **Audit** command. +R-56385 The xNF **MUST** support ONAP Controller's **Audit** command. -R-12706 The xNF **MUST** support ONAP Controller’s **QuiesceTraffic** +R-12706 The xNF **MUST** support ONAP Controller's **QuiesceTraffic** command. -R-07251 The xNF **MUST** support ONAP Controller’s **ResumeTraffic** +R-07251 The xNF **MUST** support ONAP Controller's **ResumeTraffic** command. -R-83146 The xNF **MUST** support ONAP Controller’s **StopApplication** +R-83146 The xNF **MUST** support ONAP Controller's **StopApplication** command. -R-82811 The xNF **MUST** support ONAP Controller’s **StartApplication** +R-82811 The xNF **MUST** support ONAP Controller's **StartApplication** command. -R-19922 The xNF **MUST** support ONAP Controller’s **UpgradePrecheck** +R-19922 The xNF **MUST** support ONAP Controller's **UpgradePrecheck** command. -R-49466 The xNF **MUST** support ONAP Controller’s **UpgradeSoftware** +R-49466 The xNF **MUST** support ONAP Controller's **UpgradeSoftware** command. -R-45856 The xNF **MUST** support ONAP Controller’s **UpgradePostCheck** +R-45856 The xNF **MUST** support ONAP Controller's **UpgradePostCheck** command. -R-97343 The xNF **MUST** support ONAP Controller’s **UpgradeBackup** +R-97343 The xNF **MUST** support ONAP Controller's **UpgradeBackup** command. -R-65641 The xNF **MUST** support ONAP Controller’s **UpgradeBackOut** +R-65641 The xNF **MUST** support ONAP Controller's **UpgradeBackOut** command. -R-11790 The VNF **MUST** support ONAP Controller’s +R-11790 The VNF **MUST** support ONAP Controller's **Restart (stop/start or reboot)** command. -R-56218 The VNF **MUST** support ONAP Controller’s Migrate command that +R-56218 The VNF **MUST** support ONAP Controller's Migrate command that moves container (VM) from a live Physical Server / Compute Node to another live Physical Server / Compute Node. - -R-38001 The VNF MUST support ONAP Controller’s **Rebuild** command. + +R-38001 The VNF MUST support ONAP Controller's **Rebuild** command. R-76901 VNF MUST support a container rebuild mechanism based on existing image (e.g. Glance image in Openstack environment) or a snapshot. -R-41430 The xNF **MUST** support ONAP Controller’s **HealthCheck** +R-41430 The xNF **MUST** support ONAP Controller's **HealthCheck** command. R-88026 The xNF **MUST** include a NETCONF server enabling @@ -3355,6 +3376,11 @@ R-80898 The xNF **MUST** support heartbeat via a <get> with null filter. R-25238 The xNF PACKAGE **MUST** validated YANG code using the open source pyang [3]_ program using the following commands: +.. code-block:: python + + $ pyang --verbose --strict <YANG-file-name(s)> + $ echo $! + R-63953 The xNF **MUST** have the echo command return a zero value otherwise the validation has failed @@ -3365,57 +3391,57 @@ query each state (non-configuration) data element, execute each YANG RPC, and receive data through each notification statement. R-28545 The xNF **MUST** conform its YANG model to RFC 6060, -“YANG - A Data Modeling Language for the Network Configuration -Protocol (NETCONF)” +"YANG - A Data Modeling Language for the Network Configuration +Protocol (NETCONF)" R-22700 The xNF **MUST** conform its YANG model to RFC 6470, -“NETCONF Base Notifications”. +"NETCONF Base Notifications". R-10353 The xNF **MUST** conform its YANG model to RFC 6244, -“An Architecture for Network Management Using NETCONF and YANG”. +"An Architecture for Network Management Using NETCONF and YANG". R-53317 The xNF **MUST** conform its YANG model to RFC 6087, -“Guidelines for Authors and Reviewers of YANG Data Model Documents”. +"Guidelines for Authors and Reviewers of YANG Data Model Documents". R-33955 The xNF **SHOULD** conform its YANG model to RFC 6991, -“Common YANG Data Types”. +"Common YANG Data Types". R-22946 The xNF **SHOULD** conform its YANG model to RFC 6536, -“NETCONF Access Control Model”. +"NETCONF Access Control Model". R-10129 The xNF **SHOULD** conform its YANG model to RFC 7223, -“A YANG Data Model for Interface Management”. +"A YANG Data Model for Interface Management". R-12271 The xNF **SHOULD** conform its YANG model to RFC 7223, -“IANA Interface Type YANG Module”. +"IANA Interface Type YANG Module". R-49036 The xNF **SHOULD** conform its YANG model to RFC 7277, -“A YANG Data Model for IP Management”. +"A YANG Data Model for IP Management". R-87564 The xNF **SHOULD** conform its YANG model to RFC 7317, -“A YANG Data Model for System Management”. +"A YANG Data Model for System Management". R-24269 The xNF **SHOULD** conform its YANG model to RFC 7407, -“A YANG Data Model for SNMP Configuration”, if Netconf used to +"A YANG Data Model for SNMP Configuration", if Netconf used to configure SNMP engine. R-33946 The xNF **MUST** conform to the NETCONF RFC 4741, -“NETCONF Configuration Protocol”. +"NETCONF Configuration Protocol". R-04158 The xNF **MUST** conform to the NETCONF RFC 4742, -“Using the NETCONF Configuration Protocol over Secure Shell (SSH)”. +"Using the NETCONF Configuration Protocol over Secure Shell (SSH)". R-13800 The xNF **MUST** conform to the NETCONF RFC 5277, -“NETCONF Event Notification”. +"NETCONF Event Notification". R-01334 The xNF **MUST** conform to the NETCONF RFC 5717, -“Partial Lock Remote Procedure Call”. +"Partial Lock Remote Procedure Call". R-08134 The xNF **MUST** conform to the NETCONF RFC 6241, -“NETCONF Configuration Protocol”. +"NETCONF Configuration Protocol". R-78282 The xNF **MUST** conform to the NETCONF RFC 6242, -“Using the Network Configuration Protocol over Secure Shell”. +"Using the Network Configuration Protocol over Secure Shell". R-31809 The xNF **MUST** support the HealthCheck RPC. The HealthCheck RPC executes a xNF Provider-defined xNF HealthCheck over the scope of @@ -3469,12 +3495,12 @@ chef-client run encounters any critical errors/failures when executing a xNF action. R-44013 The xNF **MUST** populate an attribute, defined as node -[‘PushJobOutput’] with the desired output on all nodes in the push job +['PushJobOutput'] with the desired output on all nodes in the push job that execute chef-client run if the xNF action requires the output of a chef-client run be made available (e.g., get running configuration). R-30654 The xNF Package **MUST** have appropriate cookbooks that are -designed to automatically ‘rollback’ to the original state in case of +designed to automatically 'rollback' to the original state in case of any errors for actions that change state of the xNF (e.g., configure). R-65755 The xNF **SHOULD** support callback URLs to return information @@ -3536,7 +3562,7 @@ the Ansible Server API, unless they are bundled with playbooks, example, generic templates. R-43253 The xNF **MUST** use playbooks designed to allow Ansible -Server to infer failure or success based on the “PLAY_RECAP” capability. +Server to infer failure or success based on the "PLAY_RECAP" capability. NOTE: There are cases where playbooks need to interpret results of a task and then determine success or failure and return result accordingly (failure for failed tasks). @@ -3547,11 +3573,11 @@ of a xNF action (e.g., audit), a playbook is required to return any xNF information. The text files must be written in the same directory as the one from which the playbook is being executed. A text file must be created for the xNF playbook run targets/affects, with the name -‘<VNFname>_results.txt’ into which any desired output from each +'<VNFname>_results.txt' into which any desired output from each respective VM/xNF must be written. R-51442 The xNF **SHOULD** use playbooks that are designed to -automatically ‘rollback’ to the original state in case of any errors +automatically 'rollback' to the original state in case of any errors for actions that change state of the xNF (e.g., configure). R-58301 The xNF **SHOULD NOT** use playbooks that make requests to @@ -3619,7 +3645,7 @@ Note: summarized statistically over a time interval, or computed as a KPI, with the summary or KPI being delivered. - We expect the reporting frequency to be configurable depending - on the virtual network function’s needs for management. For example, + on the virtual network function's needs for management. For example, Service Provider may choose to vary the frequency of collection between normal and trouble-shooting scenarios. - Decisions about the frequency of data reporting will affect the @@ -3704,8 +3730,8 @@ configuration model for the xNF by returning the requested data elements. R-43327 The xNF **SHOULD** use `Modeling JSON text with YANG <https://tools.ietf.org/html/rfc7951>`_, If YANG models need to be translated to and from JSON[RFC7951]. YANG configuration and content can -be represented via JSON, consistent with Avro, as described in “Encoding -and Serialization” section. +be represented via JSON, consistent with Avro, as described in "Encoding +and Serialization" section. R-42366 The xNF **MUST** support secure connections and transports such as Transport Layer Security (TLS) protocol @@ -3781,7 +3807,7 @@ Comments: - Playbook Name relative path provided in the request as PlaybookName -- Ansible Server Rest API is aware of playbook’s root directory which may +- Ansible Server Rest API is aware of playbook's root directory which may vary from instance to instance or Ansible Server cluster to cluster. Ansible Playbooks will use the VNF instance name (passed using @@ -4022,7 +4048,7 @@ Example: tmp/<VNF\_instance\_name>/all.yml Files containing site specific (Openstack location non-instance -specific) attribute name value pairs, like NTP server and DNS server’s +specific) attribute name value pairs, like NTP server and DNS server's IP addresses and other parameters, referenced/included by playbooks, not VNF specific – Could/should be stored under inventory/group_vars directory, in a subdirectory named after the string used to identify the site (nyc1, @@ -4157,7 +4183,7 @@ Optional: <VNF type>/<Version>/ansible/inventory/group_vars/<VNF instance name> NOTE: Default groups will be created based on VNFC type, 3 characters, -on VNFC name. Example: “oam”, “rdb”, “dbs”, “man”, “iox”, “app”,… +on VNFC name. Example: "oam", "rdb", "dbs", "man", "iox", "app",… Ansible Directories for other artifacts – VNF (special) other files – Optional – Example – License file: @@ -4212,7 +4238,7 @@ found under ONAP (onap.org). Once playbooks are developed following the guidelines listed in prior section(s), playbooks need to be on-boarded onto Ansible Server(s). In -the future, they’ll be on-boarded and distributed through ONAP, at least +the future, they'll be on-boarded and distributed through ONAP, at least that is the proposed plan, but for now they need to be uploaded manually. There is work in progress to use a Git as the playbook repository to store and track playbooks by version, version control. @@ -4230,7 +4256,7 @@ Ansible Server. a. Includes VNF type using VNF function code 4 characters under /storage. - b. Includes VNF “Version” directory as part of the path to store + b. Includes VNF "Version" directory as part of the path to store playbooks for this VNF version. c. Include generic ansible root directory. Creating full directory @@ -4313,10 +4339,10 @@ example: vm\_config\_rdb4\_hostname: vfdb9904vm006 vm\_config\_rdb4\_provider\_ip\_address: 1xx.2yy.zzz.yyy -NOTE: Please note names in this file shall use underscore “\_” not dots -“.” or dashes “-“. +NOTE: Please note names in this file shall use underscore "\_" not dots +"." or dashes "-". -7. Perform some basic playbook validation running with “--check” option, +7. Perform some basic playbook validation running with "--check" option, running dummy playbooks or other. NOTE: Each Ansible Server or cluster of Ansible Server will have its own @@ -4427,7 +4453,7 @@ UpgradePostCheck: .. [1] - The “name” field is a mandatory field in a valid Chef Node Object + The "name" field is a mandatory field in a valid Chef Node Object JSON dictionary. .. [2] @@ -4441,7 +4467,7 @@ UpgradePostCheck: ONAP for the desired action. .. [5] - Refer to NCSP’s Network Cloud specification + Refer to NCSP's Network Cloud specification .. [6] This option is not currently supported in ONAP and it is currently diff --git a/docs/release-notes.rst b/docs/release-notes.rst index 7083146..a537d44 100644 --- a/docs/release-notes.rst +++ b/docs/release-notes.rst @@ -63,7 +63,7 @@ Version: 2.0.0 - More information on the new header structure is available on `Headers <https://wiki.onap.org/display/DW/VNF+Requirement+Updated+Header+Structure>`_ **Other** - NA + NA Version: 1.0.0 -------------- @@ -106,8 +106,9 @@ Version: 1.0.0 - Initial release - none **Other** - NA + NA =========== -End of Release Notes
\ No newline at end of file +End of Release Notes + |