diff options
Diffstat (limited to 'docs/Chapter8')
| -rw-r--r-- | docs/Chapter8/Ansible-JSON-Key-Value-Description.rst | 111 | ||||
| -rw-r--r-- | docs/Chapter8/Ansible-Playbook-Examples.rst | 706 | ||||
| -rw-r--r-- | docs/Chapter8/Chef-JSON-Key-Value-Description.rst | 178 | ||||
| -rw-r--r-- | docs/Chapter8/Requirement-List.rst | 2888 | ||||
| -rw-r--r-- | docs/Chapter8/TOSCA-model.rst | 111 | ||||
| -rw-r--r-- | docs/Chapter8/VNF-License-Information-Guidelines.rst | 493 | ||||
| -rw-r--r-- | docs/Chapter8/index.rst | 17 |
7 files changed, 4504 insertions, 0 deletions
diff --git a/docs/Chapter8/Ansible-JSON-Key-Value-Description.rst b/docs/Chapter8/Ansible-JSON-Key-Value-Description.rst new file mode 100644 index 0000000..4eb8131 --- /dev/null +++ b/docs/Chapter8/Ansible-JSON-Key-Value-Description.rst @@ -0,0 +1,111 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. Copyright 2017 AT&T Intellectual Property. All rights reserved. + +Ansible JSON Key Value Description +------------------------------------------------------------- + +The following provides the key value pairs that must be contained in the +JSON file supporting Ansible action. + +Table B1. Ansible JSON File key value description +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + ++---------------+----------------------+---------+----------------------------+ +| **Field Name**| **Description** | **Type**| **Comment** | ++===============+======================+=========+============================+ +| PlaybookName | VNF providor must |Mandatory|Currently following | +| | list name of the | |Ansible standard | +| | playbook relative | |naming, where main | +| | path used to | |playbook is always | +| | execute the VNF | |named site.yml, and | +| | action. | |directory name where | +| | | |this main playbook resides, | +| | | |is named after the | +| | | |command/action playbook | +| | | |performs, in lower case, | +| | | |example, configure. | ++---------------+----------------------+---------+----------------------------+ +| Action | Name of VNF action. | Optional| | ++---------------+----------------------+---------+----------------------------+ +| EnvParameters | A JSON dictionary | Optional|Depends on the VNF action. | +| | which should list key| | | +| | 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 | +| | 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.” | +| | execute an action. | | | ++---------------+----------------------+---------+----------------------------+ +| NodeList |Ansible inventory | Optional|If not provided, pre-loaded | +| |hosts file with | |(VNF) inventory hosts | +| |VNF groups and | |file must exist in the | +| |respective IP | |Ansible Server otherwise | +| |addresses or DNS | |request fails. | +| |supported FQDNs | | | +| |that the playbook must| | | +| |be executed against. | | | ++---------------+----------------------+---------+----------------------------+ +| FileParameters| A JSON dictionary | Optional| Depends on the VNF action | +| | where keys are | | and playbook design. | +| | filenames and values | | | +| | are contents of | | | +| | files. The Ansible | | | +| | Server will utilize | | | +| | this feature to | | | +| | generate files with | | | +| | keys as filenames and| | | +| | values as content. | | | +| | This attribute can be| | | +| | used to generate | | | +| | files that a playbook| | | +| | may require as part | | | +| | of execution. | | | ++---------------+----------------------+---------+----------------------------+ +| Timeout | Time (in seconds) | Optional| | +| | that a playbook is | | | +| | expected to take to | | | +| | finish execution for | | | +| | the VNF. If playbook | | | +| | execution time | | | +| | exceeds this value, | | | +| | Ansible Server will | | | +| | terminate the | | | +| | playbook process. | | | ++---------------+----------------------+---------+----------------------------+ + +Ansible JSON file example: + +{ + + “Action”:”Configure”, + + "PlaybookName": "<VNFCode>/<Version>/ansible/configure/site.yml", + + "NodeList": ["test1.vnf\_b.onap.com", “test2.vnf\_b.onap.com”], + + "Timeout": 60, + + "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. + +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 + + +c. If execution time of the playbook exceeds 60 secs (across all hosts), + it will be terminated. + diff --git a/docs/Chapter8/Ansible-Playbook-Examples.rst b/docs/Chapter8/Ansible-Playbook-Examples.rst new file mode 100644 index 0000000..4be9944 --- /dev/null +++ b/docs/Chapter8/Ansible-Playbook-Examples.rst @@ -0,0 +1,706 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. Copyright 2017 AT&T Intellectual Property. All rights reserved. + +Ansible Playbook Examples +----------------------------------------------- + +The following sections contain examples of Ansible playbooks +which follow the guidelines. + +Guidelines for Playbooks to properly integrate with APPC +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +NOTE: To support concurrent requests to multiple VNF instances of same +or different type, VNF hosts and other files with VNF specific default +values are kept or created in separate directories. + +Example of an Ansible command (after pwd) to run playbook again +vfdb9904v VNF instance: + +.. code-block:: none + + $ pwd + /storage/vfdb/V16.1/ansible/configure + $ ansible-playbook -i ../inventory/vfdb9904vhosts site.yml --extra-vars "vnf_instance=vfdb9904v" + + NOTE: To preserve Ansible inventory/group_vars capability, that makes + group_vars contents global variables available to all playbooks, when they + reside in the inventory directory, guidelines are being updated to name the + VNF inventory hosts file as (a flat file) <VNFName>hosts, stored in the + inventory directory, not a subdirectory under inventory. In the above + example: vfdb9904vhosts (removed / VNF name and hosts vfdb9904/vhosts) + +Example of corresponding APPC API Call from ONAP – Ansible Server +Specifications: + +An example of a curl request simulating a Rest API POST requesting execution +of configure Playbook (using playbook relative path): + +.. code-block:: none + + curl -u APIUser:APIPassword -H "Content-type:application/json" -X POST + -d '{"Id": "8412", "PlaybookName": "vfdb/V5.x.x/ansible/configure/site.yml", + "Timeout":"600", "EnvParameters": { "vnf_instance": "vfdb9904v" }}' + http://ansible.server.com:5000/Dispatch + +Rest API GET request to obtain response/results for prior request +(same Id as POST request above): + +.. code-block:: none + + curl -u APIUser:APIPassword -H 'Content-type: application/json' -X GET + 'http://ansible.server.com:5000/Dispatch/?Id=8412&Type=GetResult' + +Comments: + +- An ID number is assigned to each request. This ID number is used to + track request down to completion and provide status to APPC when + requested. + +- Playbook Name relative path provided in the request as PlaybookName + +- 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 +--extra-vars "vnf\_instance=vfdb9904v") to identify other default values +to run the playbook(s) against the target VNF instance. Same example as +above: + +.. code-block:: none + + $ ansible-playbook -i ../inventory/vfdb9904vhosts site.yml --extra-vars "vnf_instance=vfdb9904v" + +Each Ansible Server or cluster is assigned its own identification to be used +to authenticate to VNF VMs using Ansible Server or cluster specific set of +SSH keys that may be rotated regularly. Here hosts file, no longer referencing +file with SSH key credentials, to run ansible-playbook listed in this example +above (IP addresses were scrubbed): + +.. code-block:: none + + $ more ../inventory/vfdb9904v/hosts + [host] + localhost ansible_connection=local + + [oam] + 1xx.2yy.zzz.109 + 1xx.2yy.zzz.110 + + [rdb] + 1xx.2yy.zzz.105 + 1xx.2yy.zzz.106 + +NOTE: APPC requests to run Playbooks/Cookbooks are specific to a VNF, +but could be more limited to one VM or one type of VM by the request +parameters. Actions that may impact a site (LCP), a service, or an +entire platform must be orchestrated by MSO in order to execute requests +via APPC which then invoke VNF level playbooks. Playbooks that impact +more than a single VNF are not the current focus of these guidelines. + +Since last release of these guidelines, based on recent learnings, +moving VNF Type global variables under inventory/group_vars files, this +way variables and respective values are available to all playbooks without +being explicitly referenced though an include statement. Also creating +templates that are VNF Type specific, but moving away from static files +that are VNF instance specific, working to obtain VNF instance specific +from other sources, inventory database, etc. + +And here the scrubbed default arguments for this VNF instance(originated +from previously re-factored playbooks now being phased out): + +.. code-block:: none + + vnf_instance=vfdb9904v + + $ more ../vars/vfdb9904v/default_args.yml + vm_config_oam_vnfc_name: vfdb9904vm001oam001 + vm_config_oam_hostname: vfdb9904vm001 + vm_config_oam_provider_ip_address: 1xx.2yy.zzz.109 + … + +IMPORTANT: The APPC and default file attribute name for +vm\_config\_oam\_vnfc\_name, as an example, is derived from vm\_config +array structure (list) in the CSAR package ENV file, with dots replaced +by underscore: + +.. code-block:: none + + vm_config: + + oam: {vnfc_name: {{ vm_config_oam_vnfc_name }}, hostname: {{ + vm_config_oam_hostname }}, provider_ip_address: {{ + vm_config_oam_provider_ip_address } + }, + … + +Parameters like VNF names, VNFC names, OA&M IP addresses, after +February, 2018 ONAP release, will be extracted from A&AI by APPC and +then passed down to Ansible Server, as part of APPC request through REST +API. In the meantime, VNF instance specific required values, will +be stored on VNF instance directory, default arguments file and will be +used as defaults. For parameterized playbooks attribute-value pairs +passed down by APPC to Ansible Server always take precedence over +template or VNF instance specific defaults stored in defaults file(s). + +.. code-block:: none + + $ pwd + /storage/vfdb/latest/ansible + Again, originated from previously re-factored playbooks now being phased out: + + $ more vars/vfdb9904v/default_args.yml + + vm_config_oam1_vnfc_name: vfdb9904vm001oam001 + vm_config_oam1_hostname: vfdb9904vm001 + vm_config_oam1_provider_ip_address: 1xx.2yy.zzz.109 + + vm_config_oam2_vnfc_name: vfdb9904vm002oam001 + vm_config_oam2_hostname: vfdb9904vm002 + vm_config_oam2_provider_ip_address: 1xx.2yy.zzz.110 + + vm_config_rdb1_vnfc_name: vfdb9904vm003rdb001 + vm_config_rdb1_hostname: vfdb9904vm003 + vm_config_rdb1_provider_ip_address: 1xx.2yy.zzz.105 + + vm_config_rdb2_vnfc_name: vfdb9904vm004rdb001 + vm_config_rdb2_hostname: vfdb9904vm004 + vm_config_rdb2_provider_ip_address: 1xx.2yy.zzz.106 + + vm_config_rdb3_vnfc_name: vfdb9904vm005rdb001 + vm_config_rdb3_hostname: vfdb9904vm005 + vm_config_rdb3_provider_ip_address: 1xx.2yy.zzz.xxx + + vm_config_rdb4_vnfc_name: vfdb9904vm006rdb001 + vm_config_rdb4_hostname: vfdb9904vm006 + vm_config_rdb4_provider_ip_address: 1xx.2yy.zzz.yyy + +One of the first tasks on the Ansible Playbooks is to combine the VNF +type generic template, derived from ENV files in CSAR or other files, +with these default values stored on the Ansible Server, together with +the overriding parameters passed down from APPC, to create the VNF +instance specific set of attribute-value pairs to be used for the run, in +INI format. Here is an excerpt from such a file that should look +somewhat similar to ENV files: + +.. code-block:: none + + $ more tmp/vfdb9904v/all.yml + + deployment_prefix: vfdb9904v + … + timezone: Etc/UTC + … + template_version: '2014-10-16' + stack_name: vfdb9904v + c3dbtype: OAM + stackName: vfdb9904v + juno_base: true + … + +# logins list contain 'login name', 'login group', 'login password' + +.. code-block:: none + + logins: + - { name: 'm99999', group: 'm99999', password: 'abcdefgha' } + - { name: 'gsuser', group: 'gsuser', password: ' abcdefgha' } + - { name: 'peruser', group: 'peruser', password: ' abcdefgha' } + - { name: 'dbuser', group: 'dbuser', password: ' abcdefgha' } + +NOTE: Arguments passed by APPC to Ansible Server to run a playbook take +precedence over any defaults stored in Ansible Server. + +Ansible Playbooks – Notes On Artifacts Required to Run Playbooks +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Inventory hosts file: should be VNF instance specific. + +Default variables: should be VNF instance specific. + +NOTE: Some playbooks may rely on inventory directory contents to target +the collection of VNFs in the Services Platform supported through +Ansible. + +Playbooks and paths to referenced files: Playbooks shall not use +absolute paths in include or import entries (variables or playbooks) or +other types of references. + +For this to work properly, when running playbooks, the directory where +the main playbook resides shall be the current directory. + +Playbook imports, when used, shall use paths relative to the main +playbook directory. + +Root directory named ansible - Any files provided with playbooks, +included, imported, or referenced by playbooks, shall reside under the ansible +playbooks (root) directory, containing all playbook subdirectories, or +below that ansible root directory, in other subdirectories to support +on-boarding and portability of VNF collection of playbooks and related +artifacts. + +Designing for a shared environment, concurrently running playbooks, +targeting multiple VNF instances – inventory hosts file: + +To avoid inventory hosts file overwrites or collisions between multiple +concurrently running VNF instance requests, chosen approach is for each +VNF instance hosts file, to be stored under the Ansible Server Playbooks +root directory, under the inventory subdirectory, and under a directory +for each VNF instance, named after the VNF instance, as follows: + +ansible/inventory/<VNF\_instance\_name>/hosts + +Example of inventory hosts file path, relative to ansible playbooks root +directory (playbooks\_dir): ansible/inventory/vnfx0001v/hosts + +**Designing for a shared environment, concurrently running multiple playbooks, +targeting multiple VNF instances – default argument variables for +specific VNF instances:** + +Files containing attribute name value pairs (variable name and default +values), referenced/included by playbooks – Files containing VNF +instance specific default values – in a later APPC release, some or all +the default attribute value pairs contained in the defaults file, may be +passed down by APPC, to the Ansible Server, overriding these defaults: + +VNF instance specific files +referenced/included by playbooks, containing default values, example, +default\_args.yml, shall be stored under a directory with VNF instance +name on the path. + +Example: + +ansible/vars/<VNF\_instance\_name>/default\_args.yml + +Example of include statement: + +- include_vars: ../vars/{{ vnf_instance }}/default_args.yml + +Again, this was originated from previously re-factored playbooks, now being +phased out, to move away from having to create VNF instance specific files +with VNF instance default variables. Moving to extract these values from +inventory databases and provide them to Ansible Server as part of the APPC +request, but may be used in a transition from having everything stored in the +Ansible Server to APPC extracting and providing VNF instance specific +attribute-value pairs to the Ansible Server as part of the request. + +Files containing attribute name value pairs (variable name and default +values), referenced/included by playbooks – created dynamically by +playbooks: + +To avoid +overwrites or collisions of multiple concurrently running VNF instance +requests, files created dynamically by playbooks, based on VNF generic +templates, combined with default values and arguments passed down by +APPC (as part of the request), shall be stored under a directory with +VNF instance name on the path. + +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 +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, +lax2,…). + +Examples: + +ansible/inventory/group_vars/<Site> + +ansible/inventory/group_vars/nyc1 + +ansible/inventory/group_vars/lax2 + + +\ **Ansible Server Design - Directory Structure** + +To help understanding the contents of this section, here are few basic +definitions: + +**VNF type a.k.a VNF Function Code** - Based on current Services +Platform naming convention, each Virtual Network Function is assigned a +4 character string (example vfdb), these are 4 characters in +the VNF instance name, followed by (4) numbers, ending in a "v", but the +naming convention is evolving. VNF instance name in +some cases corresponds to the stack name for the VNF when VNF instance +is built based on a single module, single stack. Example of VNF instance +name: vfdb9904v. All VNF performing this function, running the same +software, coming from the same VNF provider will have the same 4 +characters in the VNF instance name, in this example, vfdb. + +NOTE: New naming convention includes a prefix indicating geographical +location where VNF is instantiated. + +VNF type, determined through these 4 characters, is also known as VNF +Function Code and is assigned by inventory team. All Services Platform +VNF Function Codes can be found in inventory database and/or A&AI as +well as Services Platform Network Design Documents. + +Version – As in VNF software version is the release of the software +running on the VNF for which the playbooks were developed. VNF +configuration steps may change from release to release and this +<Version> in the path will allow the Ansible Server to host playbooks +associated with each software release. And run the playbooks that match +the software release running on each VNF instance. APPC initially will +not support playbook versioning only latest playbook is supported or a hard +coded version that later should become a variable to allow multiple +actively in use playbook versions according to VNF release. + +Playbook Function - Is a name associated with a life cycle management +task(s) performed by the playbook(s) stored in this directory. It should +clearly identify the type of action(s) performed by the main playbook +and possibly other playbooks stored in this same directory. Ideally, +playbook function would match APPC corresponding command or function that +is performed by the main playbook in this directory. Following Ansible naming +standards main playbook is usually named site.yml. There can be other +playbooks on the same directory that use a subset of the roles used by the +main playbook site.yml. Examples of Playbook Function directory names: + +- configure – Contains post-instantiation (bulk) configuration + playbooks, roles,… + +- healthcheck – Contains VNF health check playbook(s), roles,… + +- stop – Contains VNF application stop (stopApplication) playbook(s), + roles,… + +- start – Contains VNF application start (startApplication) playbook(s), + roles,… + +Directory structure to allow hosting multiple version sets of playbooks, +for the same VNF type, to be hosted in the runtime environment on the +Ansible Servers. Generic directory structure: + +Ansible Playbooks – Function directory and main playbook: + +.. code-block:: none + + <VNF type>/<Version>/ansible/<Playbook Function>/site.yml + +Example – Post-instantiation (bulk) configuration –APPC Function - +Configure: + +.. code-block:: none + + <VNF type>/<Version>/ansible/configure/site.yml + +Example – Post-instantiation (bulk) configuration –APPC Function +– Configure – VNF software version 16.1: + +.. code-block:: none + + vfdb/V16.1/ansible/configure/site.yml + +Example – Health-check –APPC Function - HealthCheck: + +.. code-block:: none + + <VNF type>/<Version>/ansible/healthcheck/site.yml + +OR (Function directory name does not need to match APPC function name) + +.. code-block:: none + + <VNF type>/<Version>/ansible/check/site.yml + +Ansible Directories for other artifacts – VNF inventory hosts file - +Required: + +.. code-block:: none + + <VNF type>/<Version>/ansible/inventory/<VNF instance name>hosts + +Ansible Directories for other artifacts – VNF instance specific default +arguments – Optional: + +.. code-block:: none + + <VNF type>/<Version>/ansible/group_vars/<VNF instance name> + +NOTE: This requirement is expected to be deprecated all or in part in the +future, for automated actions, once APPC can pass down all VNF specific +arguments for each action. Requirement remains while manual actions are +to be supported. Other automated inventory management mechanisms may be +considered in the future, Ansible supports many automated inventory +management mechanisms/tools/solutions. + +Ansible Directories for other artifacts – VNF (special) groups – +Optional: + +.. code-block:: none + + <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”,… + +Ansible Directories for other artifacts – VNF (special) other files – +Optional – Example – License file: + +.. code-block:: none + + <VNF type>/<Version>/ansible/<Other directory(s)> + +CAUTION: On referenced files used/required by playbooks. + +- To avoid missing files, during on-boarding or uploading of Ansible + Playbooks and related artifacts, all permanent files (not generated + by playbooks as part of execution), required to run any playbook, + shall reside under the ansible root directory or below on other + subdirectories. + +- Any references to files, on includes or other playbook entries, shall + use relative paths. + +- This is the ansible (root) directory referenced on this + note (Ansible Server mount point not included): + +.. code-block:: none + + <VNF type>/<Version>/ansible/ + +There will be a soft link to the latest set of Ansible Playbooks for +each VNF type. + +VNF type directories use A&AI inventory VNF function code. Ansible +Playbooks will be stored on a Cinder Volume mounted on the Ansible +Servers as /storage. Example: + +/storage/vfdb/latest/ansible – This soft link point to the latest set of +playbooks (or the only set) + +/storage/vfdb/V16.1/ansible – Root directory for database VNF Ansible +Playbooks for release 16.1 + +CAUTION: To support this directory structure as the repository to store +Ansible Playbooks run by APPC, APPC API in the Ansible Server side needs +to be configured to run playbooks from directory, not MySQL database. + +Ansible Server HTTP will be configured to support APPC REST API requests +to run playbooks as needed, against specific VNF instances, or specific +VM(s) as specified in the request. + +ONAP APPC REST API to Ansible Server is documented separately and can be +found under ONAP (onap.org). + +**Ansible Server – On-boarding Ansible Playbooks** + +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 +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. + +These are the basic steps to on-board playbooks manually onto the +Ansible Server. + +1. Upload CSAR, zip, or tar file containing VNF playbooks and related + artifacts. + +2. Create full directory (using –p option below) to store Ansible + Playbooks and other artifacts under /storage (or other configured) + file system. + + a. Includes VNF type using VNF function code 4 characters under + /storage. + + 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 + path as an example: + +.. code-block:: none + + $ mkdir –p /storage/vfdb/V16.1/ansible**/** + +3. Make this directory (VNF ansible root directory) current directory + for next few steps: + +.. code-block:: none + + cd /storage/vfdb/V16.1/ansible/ + +4. Extract Ansible Playbooks and other Ansible artifacts associated with + the playbooks onto the ansible directory. Command depends on the type + of file uploaded, examples would be: + +.. code-block:: none + + tar xvf .. + unzip … + bunzip .. + +5. Create VNF inventory hosts file with all VMs and + OA&M IP addresses for all VNF instances with known OA&M IP addresses + for respective VMs, example: + +.. code-block:: none + + $ mkdir inventory + + $ touch inventory/vfdb9904vhosts + + $ cat inventory/vfdb9904vhosts + + [host] + localhost ansible\_connection=local + + [oam] + 1xx.2yy.zzz.109 + 1xx.2yy.zzz.110 + + [rdb] + 1xx.2yy.zzz.105 + 1xx.2yy.zzz.106 + +6. (Optional, being deprecated) Create directory to hold default +arguments for each VNF instance, +example: + +.. code-block:: none + + $ mkdir –p vars/vfdb9904v + $ touch vars/vfdb9904v/default\_args.yml + $ cat vars/vfdb9904v/default\_args.yml + vm\_config\_oam1\_vnfc\_name: vfdb9904vm001oam001 + vm\_config\_oam1\_hostname: vfdb9904vm001 + vm\_config\_oam1\_provider\_ip\_address: 1xx.2yy.zzz.109 + + vm\_config\_oam2\_vnfc\_name: vfdb9904vm002oam001 + vm\_config\_oam2\_hostname: vfdb9904vm002 + vm\_config\_oam2\_provider\_ip\_address: 1xx.2yy.zzz.110 + + vm\_config\_rdb1\_vnfc\_name: vfdb9904vm003rdb001 + vm\_config\_rdb1\_hostname: vfdb9904vm003 + vm\_config\_rdb1\_provider\_ip\_address: 1xx.2yy.zzz.105 + + vm\_config\_rdb2\_vnfc\_name: vfdb9904vm004rdb001 + vm\_config\_rdb2\_hostname: vfdb9904vm004 + vm\_config\_rdb2\_provider\_ip\_address: 1xx.2yy.zzz.106 + + vm\_config\_rdb3\_vnfc\_name: vfdb9904vm005rdb001 + vm\_config\_rdb3\_hostname: vfdb9904vm005 + vm\_config\_rdb3\_provider\_ip\_address: 1xx.2yy.zzz.xxx + + vm\_config\_rdb4\_vnfc\_name: vfdb9904vm006rdb001 + 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 “-“. + +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 +credentials to authenticate to VNF VMs. Ansible Server SSH public key(s) +have to be loaded onto VNF VMs during instantiation or other way before +Ansible Server can access VNF VMs and run playbooks. HOT templates used +by heat to instantiate VNFs to be configured by these Ansible Servers running +playbooks shall include the same SSH public key and load them onto VNF VM(s) +as part of instantiation. + +Other non-vendor specific playbook tasks need to be incorporated in overall +post-instantiation configuration playbook. Alternative is for company +developed playbooks to be uploaded and executed, after VNF vendor provided +playbooks are run. + +**A couple of playbooks used for proof-of-concept testing as examples:** + +UpgradePreCheck: + +.. code-block:: none + + $ pwd + /storage/comx/V5.3.1.3/ansible/upgradeprecheck + + $ more site.yml + --- + + - import_playbook: ../common/create_vars.yml + - import_playbook: ../common/create_hosts.yml + + - name: upgrade software pre check + hosts: oam,dbs,cpm + gather_facts: no + become: true + become_method: sudo + become_user: root + max_fail_percentage: 0 + any_errors_fatal: True + roles: + - precheck + tags: precheck + + $ more roles/precheck/tasks/main.yml + --- + + - include_vars: /tmp/{{ vnf_instance }}/all.yml + + - name: get software version installed on vnf + shell: grep "^SW_VERSION =" /vendor/software/config/param_common.cfg | grep -c "{{ existing_software_version }}" + register: version_line + ignore_errors: yes + + - name: send msg when matches expected version + debug: msg="*** OK *** VNF software release matches (old) release to be upgraded." + verbosity=1 + when: version_line.stdout.find('1') != -1 + + # send warning message and failure when release is not a match + - fail: + msg="*** WARNING *** VNF software release does not match expected (pre-upgrade) release." + when: (version_line | failed) or version_line.stdout.find('1') == -1 + + +UpgradePostCheck: + +.. code-block:: none + + $ pwd + /storage/comx/V5.3.1.3/ansible/upgradepostcheck + + $ more site.yml + --- + + - import_playbook: ../common/create_vars.yml + - import_playbook: ../common/create_hosts.yml + + - name: upgrade software post check + hosts: oam,dbs,cpm + gather_facts: no + become: true + become_method: sudo + become_user: root + max_fail_percentage: 0 + any_errors_fatal: True + roles: + - postcheck + tags: postcheck + + $ more roles/postcheck/tasks/main.yml + --- + + - include_vars: /tmp/{{ vnf_instance }}/all.yml + + - name: get post upgrade software version installed on vnf + shell: grep "^SW_VERSION =" /vendor/software/config/param_common.cfg | grep -c "{{ new_software_version }}" + register: version_line + ignore_errors: yes + + - name: send msg when matches expected version + debug: msg="*** OK *** VNF software release matches new release." + verbosity=1 + when: version_line.stdout.find('1') != -1 + + # send warning message and failure when release is not a match + - fail: + msg="*** WARNING *** VNF software release does not match expected new (post-upgrade) release." + when: (version_line | failed) or version_line.stdout.find('1') == -1 + diff --git a/docs/Chapter8/Chef-JSON-Key-Value-Description.rst b/docs/Chapter8/Chef-JSON-Key-Value-Description.rst new file mode 100644 index 0000000..7144159 --- /dev/null +++ b/docs/Chapter8/Chef-JSON-Key-Value-Description.rst @@ -0,0 +1,178 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. Copyright 2017 AT&T Intellectual Property. All rights reserved. + +Chef JSON Key Value Description +------------------------------------- + +The following provides the key value pairs that must be contained in the +JSON file supporting Chef action. + +Table A1. Chef JSON File key value description +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + ++----------------+--------------------------+---------+----------------------+ +| **Field Name** | **Description** | **Type**| **Comment** | ++================+==========================+=========+======================+ +| Environment | A JSON dictionary | Optional|Depends on VNF action.| +| | representing a Chef | | | +| | Environment object. If | | | +| | the VNF action requires | | | +| | loading or modifying Chef| | | +| | environment attributes | | | +| | associated with the VNF, | | | +| | all the relevant | | | +| | information must be | | | +| | provided in this JSON | | | +| | dictionary in a structure| | | +| | that conforms to a Chef | | | +| | Environment Object. | | | ++----------------+--------------------------+---------+----------------------+ +| Node | A JSON dictionary |Mandatory| | +| | representing a Chef Node | | | +| | Object. | | | +| | | | | +| | The Node JSON dictionary | | | +| | must include the run list| | | +| | to be triggered for the | | | +| | desired VNF action by the| | | +| | push job. It should also | | | +| | include any attributes | | | +| | that need to be | | | +| | configured on the Node | | | +| | Object as part of the VNF| | | +| | action. | | | ++----------------+--------------------------+---------+----------------------+ +| NodeList | Array of FQDNs that |Mandatory| | +| | correspond to the | | | +| | endpoints (VMs) of a VNF | | | +| | registered with the Chef | | | +| | Server that need to | | | +| | trigger a chef-client run| | | +| | as part of the desired | | | +| | VNF action. | | | ++----------------+--------------------------+---------+----------------------+ +| 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. | +| | created by ONAP if | | | +| | required. | | | ++----------------+--------------------------+---------+----------------------+ +| 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”. | +| | action is capable of | | Ignored otherwise. | +| | posting results on a | | | +| | callback URL. | | | ++----------------+--------------------------+---------+----------------------+ +| 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| +| | Node object attribute | | all nodes in NodeList| +| | node[‘PushJobOutput’] for| | if set to “True”. | +| | this VNF action (e.g., in| | Ignored otherwise. | +| | Audit). | | | ++----------------+--------------------------+---------+----------------------+ + +Chef Template example: + +.. code-block:: chef + + “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” + }, + } + } + “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” + }, + "override": {}, + "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” + } + +The example JSON file provided by the VNF provider for each VNF action will be +turned into a template by ONAP, that can be updated with instance +specific values at run-time. + +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” + 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. + +The following table describes the JSON dictionary to post in Callback. + +Table A2. JSON Dictionary to Post in Callback +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + ++--------------+----------------------------+---------+-----------------------+ +| **Key** | **Description** | **Type**| **Comment** | ++==============+============================+=========+=======================+ +| RequestId | A unique string associated |Mandatory| | +| | with the original request | | | +| | by ONAP. This key-value | | | +| | pair will be provided by | | | +| | ONAP in the environment of | | | +| | the push job request and | | | +| | must be returned as part of| | | +| | the POST message. | | | ++--------------+----------------------------+---------+-----------------------+ +| StatusCode | An integer that must be set|Mandatory| | +| | to 200 if chef-client run | | | +| | on the node finished | | | +| | successfully 500 otherwise.| | | ++--------------+----------------------------+---------+-----------------------+ +| StatusMessage| A string which must be set |Mandatory| | +| | to ‘SUCCESS’ if StatusCode | | | +| | was 200 | | | +| | | | | +| | Appropriate error message | | | +| | otherwise. | | | ++--------------+----------------------------+---------+-----------------------+ +| Name | A string which corresponds |Mandatory| | +| | to the name of the node | | | +| | where push job is run. It | | | +| | is required that the value | | | +| | be retrieved from the node | | | +| | object attributes (where it| | | +| | is always defined). | | | ++--------------+----------------------------+---------+-----------------------+ +| PushJobOutput| Any output from the |Optional | Depends on VNF action.| +| | chef-client run that needs | | If empty, it must not | +| | to be returned to ONAP. | | be included. | ++--------------+----------------------------+---------+-----------------------+ + +.. [1] + The “name” field is a mandatory field in a valid Chef Node Object + JSON dictionary. diff --git a/docs/Chapter8/Requirement-List.rst b/docs/Chapter8/Requirement-List.rst new file mode 100644 index 0000000..41c9ea2 --- /dev/null +++ b/docs/Chapter8/Requirement-List.rst @@ -0,0 +1,2888 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. Copyright 2017 AT&T Intellectual Property. All rights reserved. + +Requirement List +-------------------------------- + +**VNF Development Requirements** +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +VNF Design +~~~~~~~~~~~~~ + +R-58421 The VNF **SHOULD** be decomposed into granular re-usable VNFCs. + +R-82223 The VNF **MUST** be decomposed if the functions have +significantly different scaling characteristics (e.g., signaling +versus media functions, control versus data plane functions). + +R-16496 The VNF **MUST** enable instantiating only the functionality that +is needed for the decomposed VNF (e.g., if transcoding is not needed it +should not be instantiated). + +R-02360 The VNFC **MUST** be designed as a standalone, executable process. + +R-34484 The VNF **SHOULD** create a single component VNF for VNFCs +that can be used by other VNFs. + +R-23035 The VNF **MUST** be designed to scale horizontally (more +instances of a VNF or VNFC) and not vertically (moving the existing +instances to larger VMs or increasing the resources within a VM) +to achieve effective utilization of cloud resources. + +R-30650 The VNF **MUST** utilize cloud provided infrastructure and +VNFs (e.g., virtualized Local Load Balancer) as part of the VNF so +that the cloud can manage and provide a consistent service resiliency +and methods across all VNF's. + +R-12709 The VNFC **SHOULD** be independently deployed, configured, +upgraded, scaled, monitored, and administered by ONAP. + +R-37692 The VNFC **MUST** provide API versioning to allow for +independent upgrades of VNFC. + +R-86585 The VNFC **SHOULD** minimize the use of state within +a VNFC to facilitate the movement of traffic from one instance +to another. + +R-65134 The VNF **SHOULD** maintain state in a geographically +redundant datastore that may, in fact, be its own VNFC. + +R-75850 The VNF **SHOULD** decouple persistent data from the VNFC +and keep it in its own datastore that can be reached by all instances +of the VNFC requiring the data. + +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) + +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 +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 +flavor that supports DPDK to optimize network efficiency if using DPDK. [4]_ + +R-18864 The VNF **MUST** NOT use technologies that bypass virtualization +layers (such as SR-IOV) unless approved by the NCSP (e.g., if necessary +to meet functional or performance requirements). + +R-64768 The VNF **MUST** limit the size of application data packets +to no larger than 9000 bytes for SDN network-based tunneling when +guest data packets are transported between tunnel endpoints that +support guest logical networks. + +R-74481 The VNF **MUST** NOT require the use of a dynamic routing +protocol unless necessary to meet functional requirements. + +VNF Resiliency +~~~~~~~~~~~~~~~~~~~~~~~~~ + +R-52499 The VNF **MUST** meet their own resiliency goals and not rely +on the Network Cloud. + +R-42207 The VNF **MUST** design resiliency into a VNF such that the +resiliency deployment model (e.g., active-active) can be chosen at +run-time. + +R-03954 The VNF **MUST** survive any single points of failure within +the Network Cloud (e.g., virtual NIC, VM, disk failure). + +R-89010 The VNF **MUST** survive any single points of software failure +internal to the VNF (e.g., in memory structures, JMS message queues). + +R-67709 The VNF **MUST** be designed, built and packaged to enable +deployment across multiple fault zones (e.g., VNFCs deployed in +different servers, racks, OpenStack regions, geographies) so that +in the event of a planned/unplanned downtime of a fault zone, the +overall operation/throughput of the VNF is maintained. + +R-35291 The VNF **MUST** support the ability to failover a VNFC +automatically to other geographically redundant sites if not +deployed active-active to increase the overall resiliency of the VNF. + +R-36843 The VNF **MUST** support the ability of the VNFC to be deployable +in multi-zoned cloud sites to allow for site support in the event of cloud +zone failure or upgrades. + +R-00098 The VNF **MUST NOT** impact the ability of the VNF to provide +service/function due to a single container restart. + +R-79952 The VNF **SHOULD** support container snapshots if not for rebuild +and evacuate for rollback or back out mechanism. + +R-92935 The VNF **SHOULD** minimize the propagation of state information +across multiple data centers to avoid cross data center traffic. + +R-26371 The VNF **MUST** detect communication failure for inter VNFC +instance and intra/inter VNF and re-establish communication +automatically to maintain the VNF without manual intervention to +provide service continuity. + +R-18725 The VNF **MUST** handle the restart of a single VNFC instance +without requiring all VNFC instances to be restarted. + +R-06668 The VNF **MUST** handle the start or restart of VNFC instances +in any order with each VNFC instance establishing or re-establishing +required connections or relationships with other VNFC instances and/or +VNFs required to perform the VNF function/role without requiring VNFC +instance(s) to be started/restarted in a particular order. + +R-80070 The VNF **MUST** handle errors and exceptions so that they do +not interrupt processing of incoming VNF requests to maintain service +continuity (where the error is not directly impacting the software +handling the incoming request). + +R-32695 The VNF **MUST** provide the ability to modify the number of +retries, the time between retries and the behavior/action taken after +the retries have been exhausted for exception handling to allow the +NCSP to control that behavior, where the interface and/or functional +specification allows for altering behaviour. + +R-48356 The VNF **MUST** fully exploit exception handling to the extent +that resources (e.g., threads and memory) are released when no longer +needed regardless of programming language. + +R-67918 The VNF **MUST** handle replication race conditions both locally +and geo-located in the event of a data base instance failure to maintain +service continuity. + +R-36792 The VNF **MUST** automatically retry/resubmit failed requests +made by the software to its downstream system to increase the success rate. + +R-70013 The VNF **MUST NOT** require any manual steps to get it ready for +service after a container rebuild. + +R-65515 The VNF **MUST** provide a mechanism and tool to start VNF +containers (VMs) without impacting service or service quality assuming +another VNF in same or other geographical location is processing service +requests. + +R-94978 The VNF **MUST** provide a mechanism and tool to perform a graceful +shutdown of all the containers (VMs) in the VNF without impacting service +or service quality assuming another VNF in same or other geographical +location can take over traffic and process service requests. + +R-22059 The VNF **MUST NOT** execute long running tasks (e.g., IO, +database, network operations, service calls) in a critical section +of code, so as to minimize blocking of other operations and increase +concurrent throughput. + +R-63473 The VNF **MUST** automatically advertise newly scaled +components so there is no manual intervention required. + +R-74712 The VNF **MUST** utilize FQDNs (and not IP address) for +both Service Chaining and scaling. + +R-41159 The VNF **MUST** deliver any and all functionality from any +VNFC in the pool (where pooling is the most suitable solution). The +VNFC pool member should be transparent to the client. Upstream and +downstream clients should only recognize the function being performed, +not the member performing it. + +R-85959 The VNF **SHOULD** automatically enable/disable added/removed +sub-components or component so there is no manual intervention required. + +R-06885 The VNF **SHOULD** support the ability to scale down a VNFC pool +without jeopardizing active sessions. Ideally, an active session should +not be tied to any particular VNFC instance. + +R-12538 The VNF **SHOULD** support load balancing and discovery +mechanisms in resource pools containing VNFC instances. + +R-98989 The VNF **SHOULD** utilize resource pooling (threads, +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 +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. + +R-35532 The VNF **SHOULD** release and clear all shared assets (memory, +database operations, connections, locks, etc.) as soon as possible, +especially before long running sync and asynchronous operations, so as +to not prevent use of these assets by other entities. + +R-77334 The VNF **MUST** allow configurations and configuration parameters +to be managed under version control to ensure consistent configuration +deployment, traceability and rollback. + +R-99766 The VNF **MUST** allow configurations and configuration parameters +to be managed under version control to ensure the ability to rollback to +a known valid configuration. + +R-73583 The VNF **MUST** allow changes of configuration parameters +to be consumed by the VNF without requiring the VNF or its sub-components +to be bounced so that the VNF availability is not effected. + +R-21558 The VNF **SHOULD** use intelligent routing by having knowledge +of multiple downstream/upstream endpoints that are exposed to it, to +ensure there is no dependency on external services (such as load balancers) +to switch to alternate endpoints. + +R-08315 The VNF **SHOULD** use redundant connection pooling to connect +to any backend data source that can be switched between pools in an +automated/scripted fashion to ensure high availability of the connection +to the data source. + +R-27995 The VNF **SHOULD** include control loop mechanisms to notify +the consumer of the VNF of their exceeding SLA thresholds so the consumer +is able to control its load against the VNF. + +R-73364 The VNF **MUST** support at least two major versions of the +VNF software and/or sub-components to co-exist within production +environments at any time so that upgrades can be applied across +multiple systems in a staggered manner. + +R-02454 The VNF **MUST** support the existence of multiple major/minor +versions of the VNF software and/or sub-components and interfaces that +support both forward and backward compatibility to be transparent to +the Service Provider usage. + +R-57855 The VNF **MUST** support hitless staggered/rolling deployments +between its redundant instances to allow "soak-time/burn in/slow roll" +which can enable the support of low traffic loads to validate the +deployment prior to supporting full traffic loads. + +R-64445 The VNF **MUST** support the ability of a requestor of the +service to determine the version (and therefore capabilities) of the +service so that Network Cloud Service Provider can understand the +capabilities of the service. + +R-56793 The VNF **MUST** test for adherence to the defined performance +budgets at each layer, during each delivery cycle with delivered +results, so that the performance budget is measured and the code +is adjusted to meet performance budget. + +R-77667 The VNF **MUST** test for adherence to the defined performance +budget at each layer, during each delivery cycle so that the performance +budget is measured and feedback is provided where the performance budget +is not met. + +R-49308 The VNF **SHOULD** test for adherence to the defined resiliency +rating recommendation at each layer, during each delivery cycle with +delivered results, so that the resiliency rating is measured and the +code is adjusted to meet software resiliency requirements. + +R-16039 The VNF **SHOULD** test for adherence to the defined +resiliency rating recommendation at each layer, during each +delivery cycle so that the resiliency rating is measured and +feedback is provided where software resiliency requirements are +not met. + +R-34957 The VNF **MUST** provide a method of metrics gathering for each +layer's performance to identify/document variances in the allocations so +they can be addressed. + +R-49224 The VNF **MUST** provide unique traceability of a transaction +through its life cycle to ensure quick and efficient troubleshooting. + +R-52870 The VNF **MUST** provide a method of metrics gathering +and analysis to evaluate the resiliency of the software from both +a granular as well as a holistic standpoint. This includes, but is +not limited to thread utilization, errors, timeouts, and retries. + +R-92571 The VNF **MUST** provide operational instrumentation such as +logging, so as to facilitate quick resolution of issues with the VNF to +provide service continuity. + +R-48917 The VNF **MUST** monitor for and alert on (both sender and +receiver) errant, running longer than expected and missing file transfers, +so as to minimize the impact due to file transfer errors. + +R-28168 The VNF **SHOULD** use an appropriately configured logging +level that can be changed dynamically, so as to not cause performance +degradation of the VNF due to excessive logging. + +R-87352 The VNF **SHOULD** utilize Cloud health checks, when available +from the Network Cloud, from inside the application through APIs to check +the network connectivity, dropped packets rate, injection, and auto failover +to alternate sites if needed. + +R-16560 The VNF **SHOULD** conduct a resiliency impact assessment for all +inter/intra-connectivity points in the VNF to provide an overall resiliency +rating for the VNF to be incorporated into the software design and +development of the VNF. + +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 +observed in all aspects of VNF development and not limited to security. +This is applicable to all sections of this document. + +R-61354 The VNF **MUST** implement access control list for OA&M +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 +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. + +R-92207 The VNF **SHOULD** implement a mechanism for automated and +frequent "system configuration (automated provisioning / closed loop)" +auditing. + +R-23882 The VNF **SHOULD** be scanned using both network scanning +and application scanning security tools on all code, including underlying +OS and related configuration. Scan reports shall be provided. Remediation +roadmaps shall be made available for any findings. + +R-46986 The VNF **SHOULD** have source code scanned using scanning +tools (e.g., Fortify) and provide reports. + +R-55830 The VNF **MUST** distribute all production code from NCSP +internal sources only. No production code, libraries, OS images, etc. +shall be distributed from publically accessible depots. + +R-99771 The VNF **MUST** provide all code/configuration files in a +"Locked down" or hardened state or with documented recommendations for +such hardening. All unnecessary services will be disabled. VNF provider +default credentials, community strings and other such artifacts will be +removed or disclosed so that they can be modified or removed during +provisioning. + +R-19768 The VNF **SHOULD** support L3 VPNs that enable segregation of +traffic by application (dropping packets not belonging to the VPN) (i.e., +AVPN, IPSec VPN for Internet routes). + +R-33981 The VNF **SHOULD** interoperate with various access control +mechanisms for the Network Cloud execution environment (e.g., +Hypervisors, containers). + +R-40813 The VNF **SHOULD** support the use of virtual trusted platform +module, hypervisor security testing and standards scanning tools. + +R-56904 The VNF **MUST** interoperate with the ONAP (SDN) Controller so that +it can dynamically modify the firewall rules, ACL rules, QoS rules, virtual +routing and forwarding rules. + +R-26586 The VNF **SHOULD** support the ability to work with aliases +(e.g., gateways, proxies) to protect and encapsulate resources. + +R-49956 The VNF **MUST** pass all access to applications (Bearer, +signaling and OA&M) through various security tools and platforms from +ACLs, stateful firewalls and application layer gateways depending on +manner of deployment. The application is expected to function (and in +some cases, interwork) with these security tools. + +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, +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, +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 +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 +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 +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-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 +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 +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-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 +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 +length, (2) include 3 of the 4 following types of characters: +upper-case alphabetic, lower-case alphabetic, numeric, and special, +(3) not be the same as the UserID with which they are associated or +other common strings as specified by the environment, (4) not contain +repeating or sequential characters or numbers, (5) not to use special +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 +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 +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 +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, +authenticate system to system communications where one system +accesses the resources of another system, and must never conceal +individual accountability. + +R-95105 The VNF **MUST** host connectors for access to the application +layer. + +R-45496 The VNF **MUST** host connectors for access to the OS +(Operating System) layer. + +R-05470 The VNF **MUST** host connectors for access to the database layer. + +R-99174 The VNF **MUST** comply with Individual Accountability +(each person must be assigned a unique ID) when persons or non-person +entities access VNFs. + +R-42874 The VNF **MUST** comply with Least Privilege (no more +privilege than required to perform job functions) when persons +or non-person entities access VNFs. + +R-71787 The VNF **MUST** comply with Segregation of Duties (access to a +single layer and no developer may access production without special +oversight) when persons or non-person entities access VNFs. + +R-86261 The VNF **MUST NOT** allow VNF provider access to VNFs remotely. + +R-49945 The VNF **MUST** authorize VNF provider access through a +client application API by the client application owner and the resource +owner of the VNF before provisioning authorization through Role Based +Access Control (RBAC), Attribute Based Access Control (ABAC), or other +policy based mechanism. + +R-31751 The VNF **MUST** subject VNF provider access to privilege +reconciliation tools to prevent access creep and ensure correct +enforcement of access policies. + +R-34552 The VNF **MUST** provide or support the Identity and Access +Management (IDAM) based threat detection data for OWASP Top 10. + +R-29301 The VNF **MUST** provide or support the Identity and Access +Management (IDAM) based threat detection data for Password Attacks. + +R-72243 The VNF **MUST** provide or support the Identity and Access +Management (IDAM) based threat detection data for Phishing / SMishing. + +R-58998 The VNF **MUST** provide or support the Identity and Access +Management (IDAM) based threat detection data for Malware (Key Logger). + +R-14025 The VNF **MUST** provide or support the Identity and Access +Management (IDAM) based threat detection data for Session Hijacking. + +R-31412 The VNF **MUST** provide or support the Identity and Access +Management (IDAM) based threat detection data for XSS / CSRF. + +R-51883 The VNF **MUST** provide or support the Identity and Access +Management (IDAM) based threat detection data for Replay. + +R-44032 The VNF **MUST** provide or support the Identity and Access +Management (IDAM) based threat detection data for Man in the Middle (MITM). + +R-58977 The VNF **MUST** provide or support the Identity and Access +Management (IDAM) based threat detection data for Eavesdropping. + +R-24825 The VNF **MUST** provide Context awareness data (device, +location, time, etc.) and be able to integrate with threat detection system. + +R-59391 The VNF provider **MUST**, where a VNF provider requires +the assumption of permissions, such as root or administrator, first +log in under their individual user login ID then switch to the other +higher level account; or where the individual user login is infeasible, +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 +transactions. + +R-80335 The VNF **MUST** make visible a Warning Notice: A formal +statement of resource intent, i.e., a warning notice, upon initial +access to a VNF provider user who accesses private internal networks +or Company computer resources, e.g., upon initial logon to an internal +web site, system or application which requires authentication. + +R-73541 The VNF **MUST** use access controls for VNFs and their +supporting computing systems at all times to restrict access to +authorized personnel only, e.g., least privilege. These controls +could include the use of system configuration or access control +software. + +R-64503 The VNF **MUST** provide minimum privileges for initial +and default settings for new user accounts. + +R-86835 The VNF **MUST** set the default settings for user access +to sensitive commands and data to deny authorization. + +R-77157 The VNF **MUST** conform to approved request, workflow +authorization, and authorization provisioning requirements when +creating privileged users. + +R-81147 The VNF **MUST** have greater restrictions for access and +execution, such as up to 3 factors of authentication and restricted +authorization, for commands affecting network services, such as +commands relating to VNFs. + +R-49109 The VNF **MUST** encrypt TCP/IP--HTTPS (e.g., TLS v1.2) +transmission of data on internal and external networks. + +R-39562 The VNF **MUST** disable unnecessary or vulnerable cgi-bin programs. + +R-15671 The VNF **MUST NOT** provide public or unrestricted access +to any data without the permission of the data owner. All data +classification and access controls must be followed. + +R-89753 The VNF **MUST NOT** install or use systems, tools or +utilities capable of capturing or logging data that was not created +by them or sent specifically to them in production, without +authorization of the VNF system owner. + +R-19082 The VNF **MUST NOT** run security testing tools and +programs, e.g., password cracker, port scanners, hacking tools +in production, without authorization of the VNF system owner. + +R-19790 The VNF **MUST NOT** include authentication credentials +in security audit logs, even if encrypted. + +R-85419 The VNF **SHOULD** use REST APIs exposed to Client +Applications for the implementation of OAuth 2.0 Authorization +Code Grant and Client Credentials Grant, as the standard interface +for a VNF. + +R-48080 The VNF **SHOULD** support SCEP (Simple Certificate +Enrollment Protocol). + +R-37608 The VNF **MUST** provide a mechanism to restrict access based +on the attributes of the VNF and the attributes of the subject. + +R-43884 The VNF **MUST** integrate with external authentication +and authorization services (e.g., IDAM). + +R-25878 The VNF **MUST** use certificates issued from publicly +recognized Certificate Authorities (CA) for the authentication process +where PKI-based authentication is used. + +R-19804 The VNF **MUST** validate the CA signature on the certificate, +ensure that the date is within the validity period of the certificate, +check the Certificate Revocation List (CRL), and recognize the identity +represented by the certificate where PKI-based authentication is used. + +R-47204 The VNF **MUST** protect the confidentiality and integrity of +data at rest and in transit from unauthorized access and modification. + +R-33488 The VNF **MUST** protect against all denial of service +attacks, both volumetric and non-volumetric, or integrate with external +denial of service protection tools. + +R-21652 The VNF **MUST** implement the following input validation +control: Check the size (length) of all input. Do not permit an amount +of input so great that it would cause the VNF to fail. Where the input +may be a file, the VNF API must enforce a size limit. + +R-54930 The VNF **MUST** implement the following input validation +control: Do not permit input that contains content or characters +inappropriate to the input expected by the design. Inappropriate input, +such as SQL insertions, may cause the system to execute undesirable +and unauthorized transactions against the database or allow other +inappropriate access to the internal network. + +R-21210 The VNF **MUST** implement the following input validation +control: Validate that any input file has a correct and valid +Multipurpose Internet Mail Extensions (MIME) type. Input files +should be tested for spoofed MIME types. + +R-23772 The VNF **MUST** validate input at all layers implementing VNF APIs. + +R-87135 The VNF **MUST** comply with NIST standards and industry +best practices for all implementations of cryptography. + +R-02137 The VNF **MUST** implement all monitoring and logging as +described in the Security Analytics section. + +R-15659 The VNF **MUST** restrict changing the criticality level of +a system security alarm to administrator(s). + +R-19367 The VNF **MUST** monitor API invocation patterns to detect +anomalous access patterns that may represent fraudulent access or +other types of attacks, or integrate with tools that implement anomaly +and abuse detection. + +R-78066 The VNF **MUST** support requests for information from law +enforcement and government agencies. + +R-48470 The VNF **MUST** support Real-time detection and +notification of security events. + +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. + +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. + +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 +as part of VNFs (e.g., PGW, MME). + +R-20912 The VNF **MUST** support alternative monitoring capabilities +when VNFs do not expose data or control traffic or use proprietary and +optimized protocols for inter VNF communication. + +R-73223 The VNF **MUST** support proactive monitoring to detect and +report the attacks on resources so that the VNFs and associated VMs can +be isolated, such as detection techniques for resource exhaustion, namely +OS resource attacks, CPU attacks, consumption of kernel memory, local +storage attacks. + +R-58370 The VNF **MUST** coexist and operate normally with commercial +anti-virus software which shall produce alarms every time when there is a +security incident. + +R-56920 The VNF **MUST** protect all security audit logs (including +API, OS and application-generated logs), security audit software, data, +and associated documentation from modification, or unauthorized viewing, +by standard OS access control mechanisms, by sending to a remote system, +or by encryption. + +R-54520 The VNF **MUST** log successful and unsuccessful login attempts. + +R-55478 The VNF **MUST** log logoffs. + +R-08598 The VNF **MUST** log successful and unsuccessful changes to +a privilege level. + +R-13344 The VNF **MUST** log starting and stopping of security +logging. + +R-07617 The VNF **MUST** log creating, removing, or changing the +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 +audit logs. + +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-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 +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. + +R-63330 The VNF **MUST** detect when the security audit log storage +medium is approaching capacity (configurable) and issue an alarm via +SMS or equivalent as to allow time for proper actions to be taken to +pre-empt loss of audit data. + +R-41252 The VNF **MUST** support the capability of online storage of +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 + +R-43332 The VNF **MUST** activate security alarms automatically when +the following event is detected: successful modification of critical +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 + +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 +(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 +Security alarms (where applicable and technically feasible). + +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 +system security alarm to administrator(s). + +R-13627 The VNF **MUST** monitor API invocation patterns to detect +anomalous access patterns that may represent fraudulent access or other +types of attacks, or integrate with tools that implement anomaly and +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 +(without human intervention) for Known Threats with detection rate in low +false positives. + +R-25094 The VNF **MUST** perform data capture for security functions. + +R-04492 The VNF **MUST** generate security audit logs that must be sent +to Security Analytics Tools for analysis. + +R-19219 The VNF **MUST** provide audit logs that include user ID, dates, +times for log-on and log-off, and terminal location at minimum. + +R-30932 The VNF **MUST** provide security audit logs including records +of successful and rejected system access data and other resource access +attempts. + +R-54816 The VNF **MUST** support the storage of security audit logs +for agreed period of time for forensic analysis. + +R-57271 The VNF **MUST** provide the capability of generating security +audit logs by interacting with the operating system (OS) as appropriate. + +R-84160 The VNF **MUST** have security logging for VNFs and their +OSs be active from initialization. Audit logging includes automatic +routines to maintain activity records and cleanup programs to ensure +the integrity of the audit/logging systems. + +R-58964 The VNF **MUST** provide the capability to restrict read +and write access to data. + +R-99112 The VNF **MUST** provide the capability to restrict access +to data to specific users. + +R-83227 The VNF **MUST** Provide the capability to encrypt data in +transit on a physical or virtual network. + +R-32641 The VNF **MUST** provide the capability to encrypt data on +non-volatile memory. + +R-13151 The VNF **SHOULD** disable the paging of the data requiring +encryption, if possible, where the encryption of non-transient data is +required on a device for which the operating system performs paging to +virtual memory. If not possible to disable the paging of the data +requiring encryption, the virtual memory should be encrypted. + +R-93860 The VNF **MUST** provide the capability to integrate with an +external encryption service. + +R-73067 The VNF **MUST** use industry standard cryptographic algorithms +and standard modes of operations when implementing cryptography. + +R-22645 The VNF **SHOULD** use commercial algorithms only when there +are no applicable governmental standards for specific cryptographic +functions, e.g., public key cryptography, message digests. + +R-12467 The VNF **MUST NOT** use the SHA, DSS, MD5, SHA-1 and +Skipjack algorithms or other compromised encryption. + +R-02170 The VNF **MUST** use, whenever possible, standard implementations +of security applications, protocols, and format, e.g., S/MIME, TLS, SSH, +IPSec, X.509 digital certificates for cryptographic implementations. +These implementations must be purchased from reputable vendors and must +not be developed in-house. + +R-70933 The VNF **MUST** provide the ability to migrate to newer +versions of cryptographic algorithms and protocols with no impact. + +R-44723 The VNF **MUST** use symmetric keys of at least 112 bits in length. + +R-25401 The VNF **MUST** use asymmetric keys of at least 2048 bits in length. + +R-95864 The VNF **MUST** use commercial tools that comply with X.509 +standards and produce x.509 compliant keys for public/private key generation. + +R-12110 The VNF **MUST NOT** use keys generated or derived from +predictable functions or values, e.g., values considered predictable +include user identity information, time of day, stored/transmitted data. + +R-52060 The VNF **MUST** provide the capability to configure encryption +algorithms or devices so that they comply with the laws of the jurisdiction +in which there are plans to use data encryption. + +R-69610 The VNF **MUST** provide the capability of using certificates +issued from a Certificate Authority not provided by the VNF provider. + +R-83500 The VNF **MUST** provide the capability of allowing certificate +renewal and revocation. + +R-29977 The VNF **MUST** provide the capability of testing the validity +of a digital certificate by validating the CA signature on the certificate. + +R-24359 The VNF **MUST** provide the capability of testing the validity +of a digital certificate by validating the date the certificate is being +used is within the validity period for the certificate. + +R-39604 The VNF **MUST** provide the capability of testing the +validity of a digital certificate by checking the Certificate Revocation +List (CRL) for the certificates of that type to ensure that the +certificate has not been revoked. + +R-75343 The VNF **MUST** provide the capability of testing the +validity of a digital certificate by recognizing the identity represented +by the certificate — the "distinguished name". + +VNF Modularity +~~~~~~~~~~~~~~~~~~ + +R-37028 The VNF **MUST** be composed of one “base” module. + +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. + +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-38474 The VNF **MUST** have a corresponding environment file for +a Base Module. + +R-81725 The VNF **MUST** have a corresponding environment file for +an Incremental Module. + +R-53433 The VNF **MUST** have a corresponding environment file for +a Cinder Volume Module. + +VNF Devops +~~~~~~~~~~~~~~ + +R-46960 NCSPs **MAY** operate a limited set of Guest OS and CPU +architectures and families, virtual machines, etc. + +R-23475 VNFCs **SHOULD** be agnostic to the details of the Network Cloud +(such as hardware, host OS, Hypervisor or container technology) and must run +on the Network Cloud with acknowledgement to the paradigm that the Network +Cloud will continue to rapidly evolve and the underlying components of +the platform will change regularly. + +R-33846 The VNF **MUST** install the NCSP required software on Guest OS +images when not using the NCSP provided Guest OS images. [4]_ + +R-09467 The VNF **MUST** utilize only NCSP standard compute flavors. [4]_ + +R-02997 The VNF **MUST** preserve their persistent data. Running VMs +will not be backed up in the Network Cloud infrastructure. + +R-29760 The VNFC **MUST** be installed on non-root file systems, +unless software is specifically included with the operating system +distribution of the guest image. + +R-20860 The VNF **MUST** be agnostic to the underlying infrastructure +(such as hardware, host OS, Hypervisor), any requirements should be +provided as specification to be fulfilled by any hardware. + +R-89800 The VNF **MUST NOT** require Hypervisor-level customization +from the cloud provider. + +R-86758 The VNF **SHOULD** provide an automated test suite to validate +every new version of the software on the target environment(s). The tests +should be of sufficient granularity to independently test various +representative VNF use cases throughout its lifecycle. Operations might +choose to invoke these tests either on a scheduled basis or on demand to +support various operations functions including test, turn-up and +troubleshooting. + +R-39650 The VNF **SHOULD** provide the ability to test incremental +growth of the VNF. + +R-14853 The VNF **MUST** respond to a "move traffic" [1]_ command +against a specific VNFC, moving all existing session elsewhere with +minimal disruption if a VNF provides a load balancing function across +multiple instances of its VNFCs. Note: Individual VNF performance +aspects (e.g., move duration or disruption scope) may require further +constraints. + +R-06327 The VNF **MUST** respond to a "drain VNFC" [1]_ command against +a specific VNFC, preventing new session from reaching the targeted VNFC, +with no disruption to active sessions on the impacted VNFC, if a VNF +provides a load balancing function across multiple instances of its VNFCs. +This is used to support scenarios such as proactive maintenance with no +user impact. + +R-64713 The VNF **SHOULD** support a software promotion methodology +from dev/test -> pre-prod -> production in software, development & +testing and operations. + +**VNF Modeling Requirements** +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Heat +~~~~ + +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:". + +R-39402 A VNF's Heat Orchestration Template **MUST** +contain the section "description:". + +R-35414 A VNF Heat Orchestration's template **MUST** +contain the section "parameters:". + +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 +the OS::Nova::Server resource property availability_zone +**MAY NOT** be used in any OS::Nova::Resource. + +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-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". + +R-32094 A VNF's Heat Orchestration Template parameter +declaration **MAY** contain the attribute "label:" + +R-44001 A VNF's Heat Orchestration Template parameter +declaration **MUST** contain the attribute "description". + +R-90526 A VNF Heat Orchestration Template parameter +declaration **MUST** not contain the default attribute. + +R-26124 If a VNF Heat Orchestration Template parameter +requires a default value, it **MUST** be enumerated in the environment file. + +R-32557 A VNF's Heat Orchestration Template parameter +declaration MAY contain the attribute "hidden:". + +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 +type "string" **MAY** have a parameter constraint defined. + +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 +type "comma_delimited_list" **MAY** have a parameter constraint defined. + +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 +**MAY** contain the attribute "immutable:". + +R-23664 A VNF's Heat Orchestration template **MUST** contain +the section "resources:". + +R-90152 A VNF's Heat Orchestration Template's "resources:" +section **MUST** contain the declaration of at least one resource. + +R-40551 A VNF's Heat Orchestration Template's Nested YAML files +**MAY** contain the section "resources:". + +R-75141 A VNF's Heat Orchestration Template's resource name +(i.e., <resource ID>) **MUST** only contain alphanumeric +characters and underscores ('_'). + +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 +**MUST NOT** reference a HTTP-based resource definitions. + +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 +"property:" uses a nested "get_param", one level of nesting is +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-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-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-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. + +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-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-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-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 +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 +(referred to as Cinder Volume Module). + +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 +deployment 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 +and scale out. + +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 +**MAY** be defined in a Base Module. + +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 +**MAY** be defined in 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-56721 A VNF’s Incremental 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-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-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-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-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’ + +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-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-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. + +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 +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’. + +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 +(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 +specific or Cloud site specific + +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 +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 +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 +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 +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. + +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. + +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. + +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 +Orchestration Template Base Module. + +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 +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. + +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. + +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 +is created in the same Heat Orchestration Template as the internal network, +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 +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. + +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: + +R-82481 A VNF's Heat Orchestration Template's Resource +property parameter that is 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 +associated with a unique Virtual Machine type **MUST** include +‘{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 +**MUST NOT** contain any of the following strings: '_int' or 'int\_' +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}’ +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-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. + +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 +'{network-role}' as part of the resource ID. + +R-84322 A VNF's Heat Orchestration Template's Resource property +parameter that is associated with an internal network +**MUST** include 'int\_{network-role}' as part of the parameter +name, where 'int\_' is a hard coded string. + +R-96983 A VNF's Heat Orchestration Template's Resource ID that is +associated with an internal network **MUST** include +'int\_{network-role}' as part of the Resource ID, where +'int\_' is a hard coded string. + +R-26506 A VNF's Heat Orchestration Template's '{network-role}' +**MUST** contain only alphanumeric characters and/or +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-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}’ +in all Resource IDs **MUST** be the same 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. + +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 +with a single external network, the Resource ID MUST contain the text +‘{network-role}’. + +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}’. + +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 +ID text **MUST** contain both the '{vm-type}' and the '{network-role}' + +- the '{vm-type}' **MUST** appear before the '{network-role}' and **MUST** + be separated by an underscore '_' + + - e.g., '{vm-type}_{network-role}', '{vm-type}_{index}_{network-role}' + +- note that an '{index}' value **MAY** separate the '{vm-type}' and the + '{network-role}' and when this occurs underscores **MUST** separate the + three values. + +R-82551 When a VNF's Heat Orchestration Template's resource is associated +with a single '{vm-type}' and a single internal network, the Resource ID +**MUST** contain both the '{vm-type}' and the 'int\_{network-role}' and + +- 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}') + +- 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-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}’ +**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-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 +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-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-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-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’, +the parameter name **MUST** follow the naming convention +‘{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’ +resources in the Heat Orchestration Template. + +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-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-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 +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-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 +Resource **MUST** contain the metadata map value parameter +‘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-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-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 +Resource **MUST** contain the metadata map value parameter +‘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-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-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 +Resource **SHOULD** contain the metadata map value parameter +‘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-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 +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’ +**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-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 +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 + + - 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. + +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-50816 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource **MAY** contain the metadata map value parameter +‘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-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-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-47061 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource **SHOULD** contain the metadata map value parameter +‘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-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-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 +Resource **SHOULD** contain the metadata map value parameter +‘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-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-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. + +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** + +- 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 + 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. + +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** + +- 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. + +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 +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-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 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 + +- ‘{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-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 + +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 +the parameter type is defined as a string, the parameter name **MUST** follow +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 +- 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-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 + +- ‘{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-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 + +- ‘{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-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 + +- ‘{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-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 + +- ‘{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-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 + +- ‘{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-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} +- {vm-type}_{network-role}\_ip\_v6\_{index} +- {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. + +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} +- {vm-type}\_int\_{network-role}\_ip\_v6\_{index} +- {vm-type}\_int\_{network-role}_ips +- {vm-type}\_int\_{network-role}_v6_ips + +**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-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 +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 +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 +Environment File. + +R-84123 When + +- 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 +- the internal network IPv4 subnet is to be specified using the + 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 +network role of the internal network + +- 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 +Environment File. + +R-76160 When + +- 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 +- the internal network IPv6 subnet is to be specified using the property + ‘fixed_ips’ map property ‘subnet’/’subnet_id’, + +the parameter **MUST** follow the naming convention +‘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 + 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 +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: + +- {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-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-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. + +R-67205 The VNF Heat Orchestration Template **MUST** have a corresponding +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-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-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. + +**ONAP Management Requirements** +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + +VNF On-boarding and package management +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +R-77707 The xNF provider **MUST** include a Manifest File that +contains a list of all the components in the xNF package. + +R-66070 The xNF Package **MUST** include xNF Identification Data to +uniquely identify the resource for a given xNF provider. The identification +data must include: an identifier for the xNF, the name of the xNF as was +given by the xNF provider, xNF description, xNF provider, and version. + +R-69565 The xNF Package **MUST** include documentation describing xNF +Management APIs, which must include information and tools for ONAP to +deploy and configure (initially and ongoing) the xNF application(s) +(e.g., NETCONF APIs) which includes a description of configurable +parameters for the xNF and whether the parameters can be configured +after xNF instantiation. + +R-00156 The xNF Package **MUST** include documentation describing xNF +Management APIs, which must include information and tools for ONAP +to monitor the health of the xNF (conditions that require healing +and/or scaling responses). + +R-00068 The xNF Package **MUST** include documentation which includes +a description of parameters that can be monitored for the xNF and +event records (status, fault, flow, session, call, control plane, +etc.) generated by the xNF after instantiation. + +R-12678 The xNF Package **MUST** include documentation which includes a +description of runtime lifecycle events and related actions (e.g., +control responses, tests) which can be performed for the xNF. + +R-84366 The xNF Package **MUST** include documentation describing +xNF Functional APIs that are utilized to build network and +application services. This document describes the externally exposed +functional inputs and outputs for the xNF, including interface +format and protocols supported. + +R-36280 The xNF provider **MUST** provide documentation describing +xNF Functional Capabilities that are utilized to operationalize the +xNF and compose complex services. + +R-98617 The xNF provider **MUST** provide information regarding any +dependency (e.g., affinity, anti-affinity) with other xNFs and resources. + +R-89571 The xNF **MUST** support and provide artifacts for configuration +management using at least one of the following technologies; +a) Netconf/YANG, b) Chef, or c) Ansible. + +R-30278 The xNF provider **MUST** provide a Resource/Device YANG model +as a foundation for creating the YANG model for configuration. This will +include xNF attributes/parameters and valid values/attributes configurable +by policy. + +R-13390 The xNF provider **MUST** provide cookbooks to be loaded +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. + +R-75608 The xNF provider **MUST** provide playbooks to be loaded +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. + +R-46567 The xNF Package **MUST** include configuration scripts +for boot sequence and configuration. + +R-16065 The xNF provider **MUST** provide configurable parameters +(if unable to conform to YANG model) including xNF attributes/parameters +and valid values, dynamic attributes and cross parameter dependencies +(e.g., customer provisioning data). + +R-22888 The xNF provider **MUST** provide documentation for the xNF +Policy Description to manage the xNF runtime lifecycle. The document +must include a description of how the policies (conditions and actions) +are implemented in the xNF. + +R-01556 The xNF Package **MUST** include documentation describing the +fault, performance, capacity events/alarms and other event records +that are made available by the xNF. + +R-16875 The xNF Package **MUST** include documentation which must include +a unique identification string for the specific xNF, a description of +the problem that caused the error, and steps or procedures to perform +Root Cause Analysis and resolve the issue. + +R-35960 The xNF Package **MUST** include documentation which must include +all events, severity level (e.g., informational, warning, error) and +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. + +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. + +R-01478 The xNF Package **MUST** include documentation describing all +parameters that are available to monitor the xNF after instantiation +(includes all counters, OIDs, PM data, KPIs, etc.) that must be +collected for reporting purposes. + +R-73560 The xNF Package **MUST** include documentation about monitoring +parameters/counters exposed for virtual resource management and xNF +application management. + +R-90632 The xNF Package **MUST** include documentation about KPIs and +metrics that need to be collected at each VM for capacity planning +and performance management purposes. + +R-86235 The xNF Package **MUST** include documentation about the monitoring +parameters that must include latencies, success rates, retry rates, load +and quality (e.g., DPM) for the key transactions/functions supported by +the xNF and those that must be exercised by the xNF in order to perform +its function. + +R-33904 The xNF Package **MUST** include documentation for each KPI, provide +lower and upper limits. + +R-53598 The xNF Package **MUST** include documentation to, when relevant, +provide a threshold crossing alert point for each KPI and describe the +significance of the threshold crossing. + +R-69877 The xNF Package **MUST** include documentation for each KPI, +identify the suggested actions that need to be performed when a +threshold crossing alert event is recorded. + +R-22680 The xNF Package **MUST** include documentation that describes +any requirements for the monitoring component of tools for Network +Cloud automation and management to provide these records to components +of the xNF. + +R-33694 The xNF Package **MUST** include documentation to when applicable, +provide calculators needed to convert raw data into appropriate reporting +artifacts. + +R-56815 The xNF Package **MUST** include documentation describing +supported xNF scaling capabilities and capacity limits (e.g., number +of users, bandwidth, throughput, concurrent calls). + +R-48596 The xNF Package **MUST** include documentation describing +the characteristics for the xNF reliability and high availability. + +R-74763 The xNF provider **MUST** provide an artifact per xNF that contains +all of the xNF Event Records supported. The artifact should include reference +to the specific release of the xNF Event Stream Common Event Data Model +document it is based on. (e.g., `VES Event Listener <https://github.com/att/evel-test-collector/tree/master/docs/att_interface_definition>`__) + +R-35851 The xNF Package **MUST** include xNF topology that describes +basic network and application connectivity internal and external to the +xNF including Link type, KPIs, Bandwidth, latency, jitter, QoS (if +applicable) for each interface. + +R-97102 The VNF Package **MUST** include VM requirements via a Heat +template that provides the necessary data for VM specifications +for all VNF components - for hypervisor, CPU, memory, storage. + +R-20204 The VNF Package **MUST** include VM requirements via a Heat +template that provides the necessary data for network connections, +interface connections, internal and external to VNF. + +R-44896 The VNF Package **MUST** include VM requirements via a Heat +template that provides the necessary data for high availability +redundancy model. + +R-55802 The VNF Package **MUST** include VM requirements via a Heat +template that provides the necessary data for scaling/growth VM +specifications. + +R-26881 The xNF provider **MUST** provide the binaries and images +needed to instantiate the xNF (xNF and VNFC images). + +R-96634 The xNF provider **MUST** describe scaling capabilities +to manage scaling characteristics of the xNF. + +R-43958 The xNF Package **MUST** include documentation describing +the tests that were conducted by the xNF providor and the test results. + +R-04298 The xNF provider **MUST** provide their testing scripts to +support testing. + +R-58775 The xNF provider **MUST** provide software components that +can be packaged with/near the xNF, if needed, to simulate any functions +or systems that connect to the xNF system under test. This component is +necessary only if the existing testing environment does not have the +necessary simulators. + +R-85653 The xNF **MUST** provide metrics (e.g., number of sessions, +number of subscribers, number of seats, etc.) to ONAP for tracking +every license. + +R-44125 The xNF provider **MUST** agree to the process that can +be met by Service Provider reporting infrastructure. The Contract +shall define the reporting process and the available reporting tools. + +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. + +R-44569 The xNF provider **MUST NOT** require additional +infrastructure such as a xNF provider license server for xNF provider +functions and metrics. + +R-13613 The VNF **MUST** provide clear measurements for licensing +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” +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 +instance) as the recommended solution. The xNF provider may provide +pools of Unique xNF License Keys, where there is a unique key for +each xNF instance as an alternate solution. Licensing issues should +be resolved without interrupting in-service xNFs. + +R-47849 The xNF provider **MUST** support the metadata about +licenses (and their applicable entitlements) as defined in this +document for xNF software, and any license keys required to authorize +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. + +Configuration Management +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +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-12706 The xNF **MUST** support ONAP Controller’s **QuiesceTraffic** +command. + +R-07251 The xNF **MUST** support ONAP Controller’s **ResumeTraffic** +command. + +R-83146 The xNF **MUST** support ONAP Controller’s **StopApplication** +command. + +R-82811 The xNF **MUST** support ONAP Controller’s **StartApplication** +command. + +R-19922 The xNF **MUST** support ONAP Controller’s **UpgradePrecheck** +command. + +R-49466 The xNF **MUST** support ONAP Controller’s **UpgradeSoftware** +command. + +R-45856 The xNF **MUST** support ONAP Controller’s **UpgradePostCheck** +command. + +R-97343 The xNF **MUST** support ONAP Controller’s **UpgradeBackup** +command. + +R-65641 The xNF **MUST** support ONAP Controller’s **UpgradeBackOut** +command. + +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 +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-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** +command. + +R-88026 The xNF **MUST** include a NETCONF server enabling +runtime configuration and lifecycle management capabilities. + +R-95950 The xNF **MUST** provide a NETCONF interface fully defined +by supplied YANG models for the embedded NETCONF server. + +R-73468 The xNF **MUST** allow the NETCONF server connection +parameters to be configurable during virtual machine instantiation +through Heat templates where SSH keys, usernames, passwords, SSH +service and SSH port numbers are Heat template parameters. + +R-90007 The xNF **MUST** implement the protocol operation: +**close-session()**- Gracefully close the current session. + +R-70496 The xNF **MUST** implement the protocol operation: +**commit(confirmed, confirm-timeout)** - Commit candidate +configuration datastore to the running configuration. + +R-18733 The xNF **MUST** implement the protocol operation: +**discard-changes()** - Revert the candidate configuration +datastore to the running configuration. + +R-44281 The xNF **MUST** implement the protocol operation: +**edit-config(target, default-operation, test-option, error-option, +config)** - Edit the target configuration datastore by merging, +replacing, creating, or deleting new config elements. + +R-60106 The xNF **MUST** implement the protocol operation: +**get(filter)** - Retrieve (a filtered subset of) the running +configuration and device state information. This should include +the list of xNF supported schemas. + +R-29488 The xNF **MUST** implement the protocol operation: +**get-config(source, filter)** - Retrieve a (filtered subset of +a) configuration from the configuration datastore source. + +R-11235 The xNF **MUST** implement the protocol operation: +**kill-session(session)** - Force the termination of **session**. + +R-02597 The xNF **MUST** implement the protocol operation: +**lock(target)** - Lock the configuration datastore target. + +R-96554 The xNF **MUST** implement the protocol operation: +**unlock(target)** - Unlock the configuration datastore target. + +R-29324 The xNF **SHOULD** implement the protocol operation: +**copy-config(target, source) -** Copy the content of the +configuration datastore source to the configuration datastore target. + +R-88031 The xNF **SHOULD** implement the protocol operation: +**delete-config(target) -** Delete the named configuration +datastore target. + +R-97529 The xNF **SHOULD** implement the protocol operation: +**get-schema(identifier, version, format) -** Retrieve the YANG schema. + +R-62468 The xNF **MUST** allow all configuration data to be +edited through a NETCONF <edit-config> operation. Proprietary +NETCONF RPCs that make configuration changes are not sufficient. + +R-01382 The xNF **MUST** allow the entire configuration of the +xNF to be retrieved via NETCONF's <get-config> and <edit-config>, +independently of whether it was configured via NETCONF or other +mechanisms. + +R-28756 The xNF **MUST** support **:partial-lock** and +**:partial-unlock** capabilities, defined in RFC 5717. This +allows multiple independent clients to each write to a different +part of the <running> configuration at the same time. + +R-83873 The xNF **MUST** support **:rollback-on-error** value for +the <error-option> parameter to the <edit-config> operation. If any +error occurs during the requested edit operation, then the target +database (usually the running configuration) will be left unaffected. +This provides an 'all-or-nothing' edit mode for a single <edit-config> +request. + +R-68990 The xNF **MUST** support the **:startup** capability. It +will allow the running configuration to be copied to this special +database. It can also be locked and unlocked. + +R-68200 The xNF **MUST** support the **:url** value to specify +protocol operation source and target parameters. The capability URI +for this feature will indicate which schemes (e.g., file, https, sftp) +that the server supports within a particular URL value. The 'file' +scheme allows for editable local configuration databases. The other +schemes allow for remote storage of configuration databases. + +R-20353 The xNF **MUST** implement both **:candidate** and +**:writable-running** capabilities. When both **:candidate** and +**:writable-running** are provided then two locks should be supported. + +R-11499 The xNF **MUST** fully support the XPath 1.0 specification +for filtered retrieval of configuration and other database contents. +The 'type' attribute within the <filter> parameter for <get> and +<get-config> operations may be set to 'xpath'. The 'select' attribute +(which contains the XPath expression) will also be supported by the +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-49145 The xNF **MUST** implement **:confirmed-commit** If +**:candidate** is supported. + +R-58358 The xNF **MUST** implement the **:with-defaults** capability +[RFC6243]. + +R-59610 The xNF **MUST** implement the data model discovery and +download as defined in [RFC6022]. + +R-93443 The xNF **MUST** define all data models in YANG [RFC6020], +and the mapping to NETCONF shall follow the rules defined in this RFC. + +R-26115 The xNF **MUST** follow the data model upgrade rules defined +in [RFC6020] section 10. All deviations from section 10 rules shall +be handled by a built-in automatic upgrade mechanism. + +R-10716 The xNF **MUST** support parallel and simultaneous +configuration of separate objects within itself. + +R-29495 The xNF **MUST** support locking if a common object is +being manipulated by two simultaneous NETCONF configuration operations +on the same xNF within the context of the same writable running data +store (e.g., if an interface parameter is being configured then it +should be locked out for configuration by a simultaneous configuration +operation on that same interface parameter). + +R-53015 The xNF **MUST** apply locking based on the sequence of +NETCONF operations, with the first configuration operation locking +out all others until completed. + +R-02616 The xNF **MUST** permit locking at the finest granularity +if a xNF needs to lock an object for configuration to avoid blocking +simultaneous configuration operations on unrelated objects (e.g., BGP +configuration should not be locked out if an interface is being +configured or entire Interface configuration should not be locked out +if a non-overlapping parameter on the interface is being configured). + +R-41829 The xNF **MUST** be able to specify the granularity of the +lock via a restricted or full XPath expression. + +R-66793 The xNF **MUST** guarantee the xNF configuration integrity +for all simultaneous configuration operations (e.g., if a change is +attempted to the BUM filter rate from multiple interfaces on the same +EVC, then they need to be sequenced in the xNF without locking either +configuration method out). + +R-54190 The xNF **MUST** release locks to prevent permanent lock-outs +when/if a session applying the lock is terminated (e.g., SSH session +is terminated). + +R-03465 The xNF **MUST** release locks to prevent permanent lock-outs +when the corresponding <partial-unlock> operation succeeds. + +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) + +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. + +R-88899 The xNF **MUST** support simultaneous <commit> operations +within the context of this locking requirements framework. + +R-07545 The xNF **MUST** support all operations, administration and +management (OAM) functions available from the supplier for xNFs using +the supplied YANG code and associated NETCONF servers. + +R-60656 The xNF **MUST** support sub tree filtering. + +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 [2]_ program using the following commands: + +R-63953 The xNF **MUST** have the echo command return a zero value +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, +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)” + +R-22700 The xNF **MUST** conform its YANG model to RFC 6470, +“NETCONF Base Notifications”. + +R-10353 The xNF **MUST** conform its YANG model to RFC 6244, +“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”. + +R-33955 The xNF **SHOULD** conform its YANG model to RFC 6991, +“Common YANG Data Types”. + +R-22946 The xNF **SHOULD** conform its YANG model to RFC 6536, +“NETCONF Access Control Model”. + +R-10129 The xNF **SHOULD** conform its YANG model to RFC 7223, +“A YANG Data Model for Interface Management”. + +R-12271 The xNF **SHOULD** conform its YANG model to RFC 7223, +“IANA Interface Type YANG Module”. + +R-49036 The xNF **SHOULD** conform its YANG model to RFC 7277, +“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”. + +R-24269 The xNF **SHOULD** conform its YANG model to RFC 7407, +“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”. + +R-04158 The xNF **MUST** conform to the NETCONF RFC 4742, +“Using the NETCONF Configuration Protocol over Secure Shell (SSH)”. + +R-13800 The xNF **MUST** conform to the NETCONF RFC 5277, +“NETCONF Event Notification”. + +R-01334 The xNF **MUST** conform to the NETCONF RFC 5717, +“Partial Lock Remote Procedure Call”. + +R-08134 The xNF **MUST** conform to the NETCONF RFC 6241, +“NETCONF Configuration Protocol”. + +R-78282 The xNF **MUST** conform to the NETCONF RFC 6242, +“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 +the entire xNF (e.g., if there are multiple VNFCs, then run a health check, +as appropriate, for all VNFCs). It returns a 200 OK if the test completes. +A JSON object is returned indicating state (healthy, unhealthy), scope +identifier, time-stamp and one or more blocks containing info and fault +information. If the xNF is unable to run the HealthCheck, return a +standard http error code and message. + +R-79224 The xNF **MUST** have the chef-client be preloaded with +validator keys and configuration to register with the designated +Chef Server as part of the installation process. + +R-72184 The xNF **MUST** have routable FQDNs for all the endpoints +(VMs) of a xNF that contain chef-clients which are used to register +with the Chef Server. As part of invoking xNF actions, ONAP will +trigger push jobs against FQDNs of endpoints for a xNF, if required. + +R-47068 The xNF **MAY** expose a single endpoint that is +responsible for all functionality. + +R-67114 The xNF **MUST** be installed with Chef-Client >= 12.0 and +Chef push jobs client >= 2.0. + +R-27310 The xNF Package **MUST** include all relevant Chef artifacts +(roles/cookbooks/recipes) required to execute xNF actions requested by +ONAP for loading on appropriate Chef Server. + +R-26567 The xNF Package **MUST** include a run list of +roles/cookbooks/recipes, for each supported xNF action, that will +perform the desired xNF action in its entirety as specified by ONAP +(see Section 7.c, ONAP Controller APIs and Behavior, for list of xNF +actions and requirements), when triggered by a chef-client run list +in JSON file. + +R-98911 The xNF **MUST NOT** use any instance specific parameters +for the xNF in roles/cookbooks/recipes invoked for a xNF action. + +R-37929 The xNF **MUST** accept all necessary instance specific +data from the environment or node object attributes for the xNF +in roles/cookbooks/recipes invoked for a xNF action. + +R-62170 The xNF **MUST** over-ride any default values for +configurable parameters that can be set by ONAP in the roles, +cookbooks and recipes. + +R-78116 The xNF **MUST** update status on the Chef Server +appropriately (e.g., via a fail or raise an exception) if the +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 +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 +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 +associated with a xNF action. + +R-15885 The xNF **MUST** Upon completion of the chef-client run, +POST back on the callback URL, a JSON object as described in Table +A2 if the chef-client run list includes a cookbook/recipe that is +callback capable. Failure to POST on the Callback Url should not be +considered a critical error. That is, if the chef-client successfully +completes the xNF action, it should reflect this status on the Chef +Server regardless of whether the Callback succeeded or not. + +R-32217 The xNF **MUST** have routable FQDNs that are reachable via +the Ansible Server for the endpoints (VMs) of a xNF on which playbooks +will be executed. ONAP will initiate requests to the Ansible Server +for invocation of playbooks against these end points [3]_. + +R-54373 The xNF **MUST** have Python >= 2.6 on the endpoint VM(s) +of a xNF on which an Ansible playbook will be executed. + +R-35401 The xNF **MUST** support SSH and allow SSH access by the +Ansible server for the endpoint VM(s) and comply with the Network +Cloud Service Provider guidelines for authentication and access. + +R-82018 The xNF **MUST** load the Ansible Server SSH public key onto xNF +VM(s) as part of instantiation. This will allow the Ansible Server +to authenticate to perform post-instantiation configuration without +manual intervention and without requiring specific xNF login IDs +and passwords. + +R-92866 The xNF **MUST** include as part of post-instantiation configuration +done by Ansible Playbooks the removal/update of the SSH public key from +/root/.ssh/authorized_keys, and update of SSH keys loaded through +instantiation to support Ansible. This may include download and install of +new SSH keys and new mechanized IDs. + +R-91745 The xNF **MUST** update the Ansible Server and other entities +storing and using the SSH keys for authentication when the SSH keys used +by Ansible are regenerated/updated. + +R-40293 The xNF **MUST** make available playbooks that conform +to the ONAP requirement. + +R-49396 The xNF **MUST** support each ONAP (APPC) xNF action by invocation +of **one** playbook [6]_. The playbook will be responsible +for executing all necessary tasks (as well as calling other playbooks) +to complete the request. + +R-33280 The xNF **MUST NOT** use any instance specific parameters +in a playbook. + +R-48698 The xNF **MUST** utilize information from key value pairs +that will be provided by the Ansible Server as "extra-vars" during +invocation to execute the desired xNF action. If the playbook requires +files, they must also be supplied using the methodology detailed in +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. +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). + +R-50252 The xNF **MUST** write to a specific one text files that +will be retrieved and made available by the Ansible Server if, as part +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 +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 +for actions that change state of the xNF (e.g., configure). + +R-58301 The xNF **SHOULD NOT** use playbooks that make requests to +Cloud resources e.g. Openstack (nova, neutron, glance, heat, etc.); +therefore, there is no use for Cloud specific variables like Openstack +UUIDs in Ansible Playbooks. + +R-02651 The xNF **SHOULD** use the Ansible backup feature to save a +copy of configuration files before implementing changes to support +operations such as backing out of software upgrades, configuration +changes or other work as this will help backing out of configuration +changes when needed. + +R-43353 The xNF **MUST** return control from Ansible Playbooks only +after tasks are fully complete, signaling that the playbook completed +all tasks. When starting services, return control only after all services +are up. This is critical for workflows where the next steps are dependent + +R-51910 The xNF **MUST** provide all telemetry (e.g., fault event +records, syslog records, performance records etc.) to ONAP using the +model, format and mechanisms described in this section. + +R-19624 The xNF **MUST** encode and serialize content delivered to +ONAP using JSON (RFC 7159) plain text format. High-volume data is to +be encoded and serialized using `Avro <http://avro.apache.org/>`_, +where the Avro [5]_ data format are described using JSON. + +Note: + +- JSON plain text format is preferred for moderate volume data sets + (option 1), as JSON has the advantage of having well-understood simple + processing and being human-readable without additional decoding. Examples + of moderate volume data sets include the fault alarms and performance + alerts, heartbeat messages, measurements used for xNF scaling and syslogs. +- Binary format using Avro is preferred for high volume data sets + (option 2) such as mobility flow measurements and other high-volume + streaming events (such as mobility signaling events or SIP signaling) + or bulk data, as this will significantly reduce the volume of data + to be transmitted. As of the date of this document, all events are + reported using plain text JSON and REST. +- Avro content is self-documented, using a JSON schema. The JSON schema is + delivered along with the data content + (http://avro.apache.org/docs/current/ ). This means the presence and + position of data fields can be recognized automatically, as well as the + data format, definition and other attributes. Avro content can be + serialized as JSON tagged text or as binary. In binary format, the + JSON schema is included as a separate data block, so the content is + not tagged, further compressing the volume. For streaming data, Avro + will read the schema when the stream is established and apply the + schema to the received content. + +R-98191 The xNF **MUST** vary the frequency that asynchronous data is +delivered based on the content and how data may be aggregated or grouped +together. + +Note: + +- For example, alarms and alerts are expected to be delivered as soon + as they appear. In contrast, other content, such as performance + measurements, KPIs or reported network signaling may have various ways + of packaging and delivering content. Some content should be streamed + immediately; or content may be monitored over a time interval, then packaged + as collection of records and delivered as block; or data may be collected + until a package of a certain size has been collected; 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, + 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 + size of delivered data sets, recommended delivery method, and how the + data will be interpreted by ONAP. These considerations should not + affect deserialization and decoding of the data, which will be guided + by the accompanying JSON schema or GPB definition files. + +R-88482 The xNF **SHOULD** use REST using HTTPS delivery of plain +text JSON for moderate sized asynchronous data sets, and for high +volume data sets when feasible. + +R-84879 The xNF **MUST** have the capability of maintaining a primary +and backup DNS name (URL) for connecting to ONAP collectors, with the +ability to switch between addresses based on conditions defined by policy +such as time-outs, and buffering to store messages until they can be +delivered. At its discretion, the service provider may choose to populate +only one collector address for a xNF. In this case, the network will +promptly resolve connectivity problems caused by a collector or network +failure transparently to the xNF. + +R-81777 The xNF **MUST** be configured with initial address(es) to use +at deployment time. Subsequently, address(es) may be changed through +ONAP-defined policies delivered from ONAP to the xNF using PUTs to a +RESTful API, in the same manner that other controls over data reporting +will be controlled by policy. + +R-08312 The xNF **MAY** use another option which is expected to include REST +delivery of binary encoded data sets. + +R-79412 The xNF **MAY** use another option which is expected to include TCP +for high volume streaming asynchronous data sets and for other high volume +data sets. TCP delivery can be used for either JSON or binary encoded data +sets. + +R-01033 The xNF **MAY** use another option which is expected to include SFTP +for asynchronous bulk files, such as bulk files that contain large volumes of +data collected over a long time interval or data collected across many xNFs. +(Preferred is to reorganize the data into more frequent or more focused data +sets, and deliver these by REST or TCP as appropriate.) + +R-63229 The xNF **MAY** use another option which is expected to include REST +for synchronous data, using RESTCONF (e.g., for xNF state polling). + +R-03070 The xNF **MUST**, by ONAP Policy, provide the ONAP addresses +as data destinations for each xNF, and may be changed by Policy while +the xNF is in operation. We expect the xNF to be capable of redirecting +traffic to changed destinations with no loss of data, for example from +one REST URL to another, or from one TCP host and port to another. + +R-06924 The xNF **MUST** deliver asynchronous data as data becomes +available, or according to the configured frequency. + +R-73285 The xNF **MUST** must encode, address and deliver the data +as described in the previous paragraphs. + +R-42140 The xNF **MUST** respond to data requests from ONAP as soon +as those requests are received, as a synchronous response. + +R-34660 The xNF **MUST** use the RESTCONF/NETCONF framework used by +the ONAP configuration subsystem for synchronous communication. + +R-86586 The xNF **MUST** use the YANG configuration models and RESTCONF +[RFC8040] (https://tools.ietf.org/html/rfc8040). + +R-11240 The xNF **MUST** respond with content encoded in JSON, as +described in the RESTCONF specification. This way the encoding of a +synchronous communication will be consistent with Avro. + +R-70266 The xNF **MUST** respond to an ONAP request to deliver the +current data for any of the record types defined in +Event Records - Data Structure Description by returning the requested +record, populated with the current field values. (Currently the defined +record types include fault fields, mobile flow fields, measurements for +xNF scaling fields, and syslog fields. Other record types will be added +in the future as they become standardized and are made available.) + +R-46290 The xNF **MUST** respond to an ONAP request to deliver granular +data on device or subsystem status or performance, referencing the YANG +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. + +R-42366 The xNF **MUST** support secure connections and transports such as +Transport Layer Security (TLS) protocol +[`RFC5246 <https://tools.ietf.org/html/rfc5246>`_] and should adhere to +the best current practices outlined in +`RFC7525 <https://tools.ietf.org/html/rfc7525>`_. + +R-44290 The xNF **MUST** control access to ONAP and to xNFs, and creation +of connections, through secure credentials, log-on and exchange mechanisms. + +R-47597 The xNF **MUST** carry data in motion only over secure connections. + +R-68165 The xNF **MUST** encrypt any content containing Sensitive Personal +Information (SPI) or certain proprietary data, in addition to applying the +regular procedures for securing access and delivery. + + +.. [1] + Not currently supported in ONAP release 1 + +.. [2] + https://github.com/mbj4668/pyang + +.. [3] + Upstream elements must provide the appropriate FQDN in the request to + ONAP for the desired action. + +.. [4] + Refer to NCSP’s Network Cloud specification + +.. [5] + This option is not currently supported in ONAP and it is currently + under consideration. + +.. [6] + Multiple ONAP actions may map to one playbook. + + diff --git a/docs/Chapter8/TOSCA-model.rst b/docs/Chapter8/TOSCA-model.rst new file mode 100644 index 0000000..6cdad72 --- /dev/null +++ b/docs/Chapter8/TOSCA-model.rst @@ -0,0 +1,111 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. Copyright 2017 AT&T Intellectual Property. All rights reserved. + +TOSCA model +----------- + +Table D1. ONAP Resource DM TOSCA/YAML constructs +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Standard TOSCA/YAML definitions agreed by VNF SDK Modeling team to be used by +VNF vendors to create a standard VNF descriptor. + +All definitions are summarized in the table below based on the agreed ONAP +Resource DM TOSCA/YAML constructs for Beijing. Their syntax is specified in +ETSI GS NFV-SOL001 stable draft for VNF-D. + ++------------+------------------------------+---------------------------------+ +| Requirement| Resource IM Info Elements | TOSCA Constructs as per SOL001 | +| Number | | | ++============+==============================+=================================+ +| R-02454 | VNFD.vnfSoftwareVersion | For VDU.Compute - | +| | | tosca.artifacts.nfv.SwImage | +| | | | +| | SwImageDesc.Version | For Virtual Storage - | +| | | tosca.artifacts.Deployment.Image| ++------------+------------------------------+---------------------------------+ +| R-03070 | vnfExtCpd's with virtual | tosca.nodes.nfv.VnfExtCp with a | +| | NetworkInterfaceRequirements | property tosca.datatypes.nfv.\ | +| | (vNIC) | VirtualNetworkInterface\ | +| | | Requirements | ++------------+------------------------------+---------------------------------+ +| R-09467 | VDU.Compute descriptor | tosca.nodes.nfv.Vdu.Compute | ++------------+------------------------------+---------------------------------+ +| R-16065 | VDU.Compute. Configurable | tosca.datatypes.nfv.Vnfc | +| | Properties | ConfigurableProperties | ++------------+------------------------------+---------------------------------+ +| R-30654 | VNFD.lifeCycleManagement | Interface construct tosca.\ | +| | Script - IFA011 LifeCycle\ | interfaces.nfv.vnf.lifecycle.Nfv| +| | ManagementScript | with a list of standard LCM | +| | | operations | ++------------+------------------------------+---------------------------------+ +| R-35851 | CPD: VduCp, VnfExtCp, | tosca.nodes.nfv.VduCp, tosca.\ | +| | VnfVirtualLinkDesc, QoS | nodes.nfv.VnfVirtualLink, | +| | Monitoring info element - | tosca.nodes.nfv.VnfExtCp | +| | TBD | | ++------------+------------------------------+---------------------------------+ +| R-41215 | VNFD/VDU Profile and scaling | tosca.datatypes.nfv.VduProfile | +| | aspect | and tosca.datatypes.nfv.\ | +| | | ScalingAspect | ++------------+------------------------------+---------------------------------+ +| R-66070 | VNFD meta data | tosca.datatypes.nfv. | +| | | VnfInfoModifiableAttributes - | +| | | metadata? | ++------------+------------------------------+---------------------------------+ +| R-96634 | VNFD.configurableProperties | tosca.datatypes.nfv.Vnf\ | +| | describing scaling | ConfigurableProperties, | +| | characteristics. VNFD.\ | tosca.datatypes.nfv.ScaleInfo | +| | autoscale defines the rules | | +| | for scaling based on specific| | +| | VNF indications | | ++------------+------------------------------+---------------------------------+ +| ? | VDU Virtual Storage | tosca.nodes.nfv.Vdu.\ | +| | | VirtualStorage | ++------------+------------------------------+---------------------------------+ +| R-01478 | Monitoring Info Element (TBD)| tosca.capabilities.nfv.Metric - | +| | - SOL001 per VNF/VDU/VLink | type for monitoring | +| R-01556 | memory-consumption, | | +| | CPU-utilization, | monitoring_parameter of above | +| | bandwidth-consumption, VNFC | type per VNF/VDU/VLink | +| | downtime, etc. | | ++------------+------------------------------+---------------------------------+ + + +Table D2. TOSCA CSAR structure +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This section defines the requirements around the CSAR structure. + +The table below describes the numbered requirements for CSAR structure as +agreed with SDC. The format of the CSAR is specified in SOL004. + ++------------+-------------------------------------+--------------------------+ +| Requirement| Description | CSAR artifact directory | +| Number | | | ++============+=====================================+==========================+ +| R-26881 | The VNF provider MUST provide the | ROOT\\Artifacts\ | +| | binaries and images needed to | \\VNF_Image.bin | +| | instantiate the VNF (VNF and VNFC | | +| | images). | | ++------------+-------------------------------------+--------------------------+ +| R-30654 | VNFD.lifeCycleManagementScript that | ROOT\\Artifacts\ | +| | includes a list of events and | \\Informational\ | +| | corresponding management scripts | \\Install.csh | +| | performed for the VNF - SOL001 | | ++------------+-------------------------------------+--------------------------+ +| R-35851 | All VNF topology related definitions| ROOT\\Definitions\ | +| | in yaml files VNFD/Main Service | \\VNFC.yaml | +| | template at the ROOT | | +| | | ROOT\ | +| | | \\MainService\ | +| | | \\Template.yaml | ++------------+-------------------------------------+--------------------------+ +| R-40827 | CSAR License directory - SOL004 | ROOT\\Licenses\ | +| | | \\License_term.txt | ++------------+-------------------------------------+--------------------------+ +| R-77707 | CSAR Manifest file - SOL004 | ROOT\ | +| | | \\MainServiceTemplate.mf | ++------------+-------------------------------------+--------------------------+ + + diff --git a/docs/Chapter8/VNF-License-Information-Guidelines.rst b/docs/Chapter8/VNF-License-Information-Guidelines.rst new file mode 100644 index 0000000..d571173 --- /dev/null +++ b/docs/Chapter8/VNF-License-Information-Guidelines.rst @@ -0,0 +1,493 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. Copyright 2017 AT&T Intellectual Property. All rights reserved. + +VNF License Information Guidelines +---------------------------------- + +This Appendix describes the metadata to be supplied for VNF licenses. + +1. General Information + +Table C1 defines the required and optional fields for licenses. + +Table C1. Required Fields for General Information +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + ++---------------+-----------------------------------+--------------+----------+ +| **Field Name**| **Description** | **Data Type**| **Type** | ++===============+===================================+==============+==========+ +| VNF Provider | The name of the VNF provider. | String | Mandatory| +| Name | | | | ++---------------+-----------------------------------+--------------+----------+ +| VNF Provider | The name of the product to which | String | Mandatory| +| Product | this agreement applies. | | | +| | | | | +| | Note: a contract/agreement may | | | +| | apply to more than one VNF | | | +| | provider product. In that case, | | | +| | provide the metadata for each | | | +| | product separately. | | | ++---------------+-----------------------------------+--------------+----------+ +| VNF Provider | A general description of VNF | String | Optional | +| Product | provider software product. | | | +| Description | | | | ++---------------+-----------------------------------+--------------+----------+ +| Export Control| ECCNs are 5-character | String | Mandatory| +| Classification| alpha-numeric designations used on| | | +| Number (ECCN) | the Commerce Control List (CCL) to| | | +| | identify dual-use items for export| | | +| | control purposes. An ECCN | | | +| | categorizes items based on the | | | +| | nature of the product, i.e. type | | | +| | of commodity, software, or | | | +| | technology and its respective | | | +| | technical parameters. | | | ++---------------+-----------------------------------+--------------+----------+ +| Reporting | A list of any reporting | List of | Optional | +| Requirements | requirements on the usage of the | strings | | +| | software product. | | | ++---------------+-----------------------------------+--------------+----------+ + +1. Entitlements + +Entitlements describe software license use rights. The use rights may be +quantified by various metrics: # users, # software instances, # units. +The use rights may be limited by various criteria: location (physical or +logical), type of customer, type of device, time, etc. + +One or more entitlements can be defined; each one consists of the +following fields: + +Table C2. Required Fields for Entitlements +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + ++---------------+-----------------------------------+-------------+-----------+ +| **Field Name**| **Description** |**Data Type**| **Type** | ++===============+===================================+=============+===========+ +| VNF Provider | Identifier for the entitlement as | String | Mandatory | +| Part Number / | described by the VNF provider in | | | +| Manufacture | their price list / catalog / | | | +| Reference | contract. | | | +| Number | | | | ++---------------+-----------------------------------+-------------+-----------+ +| Description | Verbiage that describes the | String | Optional | +| | entitlement | | | ++---------------+-----------------------------------+-------------+-----------+ +| Entitlement | Each entitlement defined must be | String | Mandatory | +| Identifier | identified by a unique value (e.g.| | | +| | numbered 1, 2, 3….) | | | ++---------------+-----------------------------------+-------------+-----------+ +| Minimum Order | The minimum number of entitlements| Number | Mandatory | +| Requirement | that need to be purchased. | | | +| | For example, the entitlements must| | | +| | be purchased in a block of 100. If| | | +| | no minimum is required, the value | | | +| | will be zero. | | | ++---------------+-----------------------------------+-------------+-----------+ +| Unique | A list of any reporting | List of | Optional | +| Reporting | requirements on the usage of the | Strings | | +| Requirements | software product. (e.g.: quarterly| | | +| | usage reports are required) | | | ++---------------+-----------------------------------+-------------+-----------+ +| License Type | Type of license applicable to the | String | Mandatory | +| | software product. (e.g.: | | | +| | fixed-term, perpetual, trial, | | | +| | subscription.) | | | ++---------------+-----------------------------------+-------------+-----------+ +| License | Valid values: | String |Conditional| +| Duration | | | | +| | **year**, **quarter**, **month**, | | | +| | **day**. | | | +| | | | | +| | Not applicable when license type | | | +| | is Perpetual. | | | ++---------------+-----------------------------------+-------------+-----------+ +| License | Number of years, quarters, months,| Number |Conditional| +| Duration | or days for which the license is | | | +| Quantification| valid. | | | +| | | | | +| | Not applicable when license type | | | +| | is Perpetual. | | | ++---------------+-----------------------------------+-------------+-----------+ +| Limits | see section C.4 for possible | List | Optional | +| | values | | | ++---------------+-----------------------------------+-------------+-----------+ + +1. License Keys + +This section defines information on any License Keys associated with the +Software Product. A license key is a data string (or a file) providing a +means to authorize the use of software. License key does not provide +entitlement information. + +License Keys are not required. Optionally, one or more license keys can +be defined; each one consists of the following fields: + +Table C3. Required Fields for License Keys +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + ++---------------+-----------------------------------+--------------+----------+ +| **Field Name**| **Description** | **Data Type**| **Type** | ++===============+===================================+==============+==========+ +| Description | Verbiage that describes the | String | Mandatory| +| | license key | | | ++---------------+-----------------------------------+--------------+----------+ +| License Key | Each license key defined must be | String | Mandatory| +| Identifier | identified by a unique value | | | +| | (e.g., numbered 1, 2, 3….) | | | ++---------------+-----------------------------------+--------------+----------+ +| Key Function | Lifecycle stage (e.g., | String | Optional | +| | Instantiation or Activation) at | | | +| | which the license key is applied | | | +| | to the software. | | | ++---------------+-----------------------------------+--------------+----------+ +| License Key | Valid values: | String | Mandatory| +| Type | | | | +| | **Universal, Unique** | | | +| | | | | +| | **Universal** - a single license | | | +| | key value that may be used with | | | +| | any number of instances of the | | | +| | software. | | | +| | | | | +| | **Unique**- a unique license key | | | +| | value is required for each | | | +| | instance of the software. | | | ++---------------+-----------------------------------+--------------+----------+ +| Limits | see section C.4 for possible | List | Optional | +| | values | | | ++---------------+-----------------------------------+--------------+----------+ + +1. Entitlement and License Key Limits + +Limitations on the use of software entitlements and license keys may be +based on factors such as: features enabled in the product, the allowed +capacity of the product, number of installations, etc... The limits may +generally be categorized as: + +- where (location) + +- when (time) + +- how (usages) + +- who/what (entity) + +- amount (how much) + +Multiple limits may be applicable for an entitlement or license key. +Each limit may further be described by limit behavior, duration, +quantification, aggregation, aggregation interval, start date, end date, +and threshold. + +When the limit is associated with a quantity, the quantity is relative +to an instance of the entitlement or license key. For example: + +- Each entitlement grants the right to 50 concurrent users. If 10 + entitlements are purchased, the total number of concurrent users + permitted would be 500. In this example, the limit category is + **amount**, the limit type is **users**, and the limit + **quantification** is **50.** + + Each license key may be installed on 3 devices. If 5 license keys are + acquired, the total number of devices allowed would be 15. In this + example, the limit category is **usages**, the limit type is + **device**, and the limit **quantification** is **3.** + +1. Location + +Locations may be logical or physical location (e.g., site, country). For +example: + +- use is allowed in Canada + +Table C4. Required Fields for Location +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + ++------------------+--------------------------------+--------------+----------+ +| **Field Name** | **Description** | **Data Type**| **Type** | ++==================+================================+==============+==========+ +| Limit Identifier | Each limit defined for an | String | Mandatory| +| | entitlement or license key must| | | +| | be identified by a unique value| | | +| | (e.g., numbered 1,2,3…) | | | ++------------------+--------------------------------+--------------+----------+ +| Limit Description| Verbiage describing the limit. | String | Mandatory| ++------------------+--------------------------------+--------------+----------+ +| Limit Behavior | Description of the actions | String | Mandatory| +| | taken when the limit boundaries| | | +| | are reached. | | | ++------------------+--------------------------------+--------------+----------+ +| Limit Category | Valid value: **location** | String | Mandatory| ++------------------+--------------------------------+--------------+----------+ +| Limit Type | Valid values: **city, county, | String | Mandatory| +| | state, country, region, MSA, | | | +| | BTA, CLLI** | | | ++------------------+--------------------------------+--------------+----------+ +| Limit List | List of locations where the VNF| List of | Mandatory| +| | provider Product can be used or| String | | +| | needs to be restricted from use| | | ++------------------+--------------------------------+--------------+----------+ +| Limit Set Type | Indicates if the list is an | String | Mandatory| +| | inclusion or exclusion. | | | +| | | | | +| | Valid Values: | | | +| | | | | +| | **Allowed** | | | +| | | | | +| | **Not allowed** | | | ++------------------+--------------------------------+--------------+----------+ +| Limit | The quantity (amount) the limit| Number | Optional | +| Quantification | expresses. | | | ++------------------+--------------------------------+--------------+----------+ + +1. Time + +Limit on the length of time the software may be used. For example: + +- license key valid for 1 year from activation + +- entitlement valid from 15 May 2018 thru 30 June 2020 + +Table C5. Required Fields for Time +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + ++------------------+-------------------------------+--------------+-----------+ +| **Field Name** | **Description** | **Data Type**| **Type** | ++==================+===============================+==============+===========+ +| Limit Identifier | Each limit defined for an | String | Mandatory | +| | entitlement or license key | | | +| | must be identified by a unique| | | +| | value (e.g., numbered) | | | ++------------------+-------------------------------+--------------+-----------+ +| Limit Description| Verbiage describing the limit.| String | Mandatory | ++------------------+-------------------------------+--------------+-----------+ +| Limit Behavior | Description of the actions | String | Mandatory | +| | taken when the limit | | | +| | boundaries are reached. | | | +| | | | | +| | The limit behavior may also | | | +| | describe when a time limit | | | +| | takes effect. (e.g., key is | | | +| | valid for 1 year from date of | | | +| | purchase). | | | ++------------------+-------------------------------+--------------+-----------+ +| Limit Category | Valid value: **time** | String | Mandatory | ++------------------+-------------------------------+--------------+-----------+ +| Limit Type | Valid values: | String | Mandatory | +| | **duration, date** | | | ++------------------+-------------------------------+--------------+-----------+ +| Limit List | List of times for which the | List of | Mandatory | +| | VNF Provider Product can be | String | | +| | used or needs to be restricted| | | +| | from use | | | ++------------------+-------------------------------+--------------+-----------+ +| Duration Units | Required when limit type is | String |Conditional| +| | duration. Valid values: | | | +| | **perpetual, year, quarter, | | | +| | month, day, minute, second, | | | +| | millisecond** | | | ++------------------+-------------------------------+--------------+-----------+ +| Limit | The quantity (amount) the | Number | Optional | +| Quantification | limit expresses. | | | ++------------------+-------------------------------+--------------+-----------+ +| Start Date | Required when limit type is | Date | Optional | +| | date. | | | ++------------------+-------------------------------+--------------+-----------+ +| End Date | May be used when limit type is| Date | Optional | +| | date. | | | ++------------------+-------------------------------+--------------+-----------+ + +1. Usage + +Limits based on how the software is used. For example: + +- use is limited to a specific sub-set of the features/capabilities the + software supports + +- use is limited to a certain environment (e.g., test, development, + production…) + +- use is limited by processor (vm, cpu, core) + +- use is limited by software release + +Table C6. Required Fields for Usage +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + ++------------------+-------------------------------+---------------+----------+ +| **Field Name** | **Description** | **Data Type** | **Type** | ++==================+===============================+===============+==========+ +| Limit Identifier | Each limit defined for an | String | Mandatory| +| | entitlement or license key | | | +| | must be identified by a unique| | | +| | value (e.g., numbered) | | | ++------------------+-------------------------------+---------------+----------+ +| Limit Description| Verbiage describing the limit.| String | Mandatory| ++------------------+-------------------------------+---------------+----------+ +| Limit Behavior | Description of the actions | String | Mandatory| +| | taken when the limit | | | +| | boundaries are reached. | | | ++------------------+-------------------------------+---------------+----------+ +| Limit Category | Valid value: **usages** | String | Mandatory| ++------------------+-------------------------------+---------------+----------+ +| Limit Type | Valid values: **feature, | String | Mandatory| +| | environment, processor, | | | +| | version** | | | ++------------------+-------------------------------+---------------+----------+ +| Limit List | List of usage limits (e.g., | List of String| Mandatory| +| | test, development, vm, core, | | | +| | R1.2.1, R1.3.5…) | | | ++------------------+-------------------------------+---------------+----------+ +| Limit Set Type | Indicates if the list is an | String | Mandatory| +| | inclusion or exclusion. | | | +| | | | | +| | Valid Values: | | | +| | | | | +| | **Allowed** | | | +| | | | | +| | **Not allowed** | | | ++------------------+-------------------------------+---------------+----------+ +| Limit | The quantity (amount) the | Number | Optional | +| Quantification | limit expresses. | | | ++------------------+-------------------------------+---------------+----------+ + +1. Entity + +Limit on the entity (product line, organization, customer) allowed to +make use of the software. For example: + +- allowed to be used in support of wireless products + +- allowed to be used only for government entities + +Table C7. Required Fields for Entity +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + ++------------------+--------------------------------+--------------+----------+ +| **Field Name** | **Description** |**Data Type** | **Type** | ++==================+================================+==============+==========+ +| Limit Identifier | Each limit defined for an | String | Mandatory| +| | entitlement or license key must| | | +| | be identified by a unique value| | | +| | (e.g., numbered) | | | ++------------------+--------------------------------+--------------+----------+ +| Limit Description| Verbiage describing the limit. | String | Mandatory| ++------------------+--------------------------------+--------------+----------+ +| Limit Behavior | Description of the actions | String | Mandatory| +| | taken when the limit boundaries| | | +| | are reached. | | | ++------------------+--------------------------------+--------------+----------+ +| Limit Category | Valid value: **entity** | String | Mandatory| ++------------------+--------------------------------+--------------+----------+ +| Limit Type | Valid values: **product line, | String | Mandatory| +| | organization, internal | | | +| | customer, external customer** | | | ++------------------+--------------------------------+--------------+----------+ +| Limit List | List of entities for which the |List of String| Mandatory| +| | VNF Provider Product can be | | | +| | used or needs to be restricted | | | +| | from use | | | ++------------------+--------------------------------+--------------+----------+ +| Limit Set Type | Indicates if the list is an | String | Mandatory| +| | inclusion or exclusion. | | | +| | | | | +| | Valid Values: | | | +| | | | | +| | **Allowed** | | | +| | | | | +| | **Not allowed** | | | ++------------------+--------------------------------+--------------+----------+ +| Limit | The quantity (amount) the limit| Number | Optional | +| Quantification | expresses. | | | ++------------------+--------------------------------+--------------+----------+ + +1. Amount + +These limits describe terms relative to utilization of the functions of +the software (for example, number of named users permitted, throughput, +or capacity). Limits of this type may also be relative to utilization of +other resources (for example, a limit for firewall software is not based +on use of the firewall software, but on the number of network +subscribers). + +The metadata describing this type of limit includes the unit of measure +(e.g., # users, # sessions, # MB, # TB, etc.), the quantity of units, +any aggregation function (e.g., peak or average users), and aggregation +interval (day, month, quarter, year, etc.). + +Table C8. Required Fields for Amount +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + ++------------------+---------------------------------+-------------+----------+ +| **Field Name** | **Description** |**Data Type**| **Type** | ++==================+=================================+=============+==========+ +| Limit Identifier | Each limit defined for an | String | Mandatory| +| | entitlement or license key must | | | +| | be identified by a unique value | | | +| | (e.g., numbered) | | | ++------------------+---------------------------------+-------------+----------+ +| Limit Description| Verbiage describing the limit. | String | Mandatory| ++------------------+---------------------------------+-------------+----------+ +| Limit Behavior | Description of the actions taken| String | Mandatory| +| | when the limit boundaries are | | | +| | reached. | | | ++------------------+---------------------------------+-------------+----------+ +| Limit Category | Valid value: **amount** | String | Mandatory| ++------------------+---------------------------------+-------------+----------+ +| Limit Type | Valid values: **trunk, user, | String | Mandatory| +| | subscriber, session, token, | | | +| | transactions, seats, KB, MB, TB,| | | +| | GB** | | | ++------------------+---------------------------------+-------------+----------+ +| Type of | Is the limit relative to | String | Mandatory| +| Utilization | utilization of the functions of | | | +| | the software or relative to | | | +| | utilization of other resources? | | | +| | | | | +| | Valid values: | | | +| | | | | +| | - **software functions** | | | +| | | | | +| | - **other resources** | | | ++------------------+---------------------------------+-------------+----------+ +| Limit | The quantity (amount) the limit | Number | Optional | +| Quantification | expresses. | | | ++------------------+---------------------------------+-------------+----------+ +| Aggregation | Valid values: **peak, average** | String | Optional | +| Function | | | | ++------------------+---------------------------------+-------------+----------+ +| Aggregation | Time period over which the | String | Optional | +| Interval | aggregation is done (e.g., | | | +| | average sessions per quarter). | | | +| | Required when an Aggregation | | | +| | Function is specified. | | | +| | | | | +| | Valid values: **day, month, | | | +| | quarter, year, minute, second, | | | +| | millisecond** | | | ++------------------+---------------------------------+-------------+----------+ +| Aggregation | Is the limit quantity applicable| String | Optional | +| Scope | to a single entitlement or | | | +| | license key (each separately)? | | | +| | Or may the limit quantity be | | | +| | combined with others of the same| | | +| | type (resulting in limit amount | | | +| | that is the sum of all the | | | +| | purchased entitlements or | | | +| | license keys)? | | | +| | | | | +| | Valid values: | | | +| | | | | +| | - **single** | | | +| | | | | +| | - **combined** | | | ++------------------+---------------------------------+-------------+----------+ +| Type of User | Describes the types of users of | String | Optional | +| | the functionality offered by the| | | +| | software (e.g., authorized, | | | +| | named). This field is included | | | +| | when Limit Type is user. | | | ++------------------+---------------------------------+-------------+----------+ + diff --git a/docs/Chapter8/index.rst b/docs/Chapter8/index.rst new file mode 100644 index 0000000..503dc8c --- /dev/null +++ b/docs/Chapter8/index.rst @@ -0,0 +1,17 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. Copyright 2017 AT&T Intellectual Property. All rights reserved. + + +Appendix +======== + +.. toctree:: + :maxdepth: 2 + + Chef-JSON-Key-Value-Description + Ansible-JSON-Key-Value-Description + VNF-License-Information-Guidelines + TOSCA-model + Requirement-List + Ansible-Playbook-Examples |