DevOps Requirements
* R-46960 The VNF **MUST** utilize only the Guest OS versions that are supported by the NCSP’s Network Cloud. [1]_
-* R-23475 The VNF **SHOULD** utilize only NCSP provided Guest OS images. [2]_
-* R-09467 The VNF **MUST** utilize only NCSP standard compute flavors. [2]_
+* R-23475 The VNF **SHOULD** utilize only NCSP provided Guest OS images. [1]_
+* R-09467 The VNF **MUST** utilize only NCSP standard compute flavors. [1]_
* 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" [3]_ 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-14853 The VNF **MUST** respond to a "move traffic" [2]_ 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" [2]_ 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,
f. VNF Develop Steps
Refer to NCSP’s Network Cloud specification
.. [2]
- Refer to NCSP’s Network Cloud specification
-
-.. [3]
Not currently supported in ONAP release 1
how many times the component can occur.
|image1|
+
Figure 1: Structural Elements of Service Template and their Relations
TOSCA Modeling Principles & Data Model
* R-60656 The VNF **MUST** support sub tree filtering.
* R-80898 The VNF **MUST** support heartbeat via a <get> with null filter.
* R-06617 The VNF **MUST** support get-schema (ietf-netconf-monitoring) to pull YANG model over session.
-* R-25238 The VNF PACKAGE **MUST** validated YANG code using the open source pyang [2]_ program using the following commands:
+* R-25238 The VNF PACKAGE **MUST** validated YANG code using the open source pyang [1]_ program using the following commands:
.. code-block:: python
**Chef Server Requirements**
-ONAP will interact with the Chef Server designated to manage a target VNF. ONAP design allows for the VNF to register with the following types of Chef Server [3]_:
+ONAP will interact with the Chef Server designated to manage a target VNF. ONAP design allows for the VNF to register with the following types of Chef Server [2]_:
- **Chef Server hosted by ONAP**: ONAP will provide a Chef Server to manage a VNF.
3. Next, it creates a Node Object from the “Node” JSON dictionary for
all elements listed in the NodeList (using the FQDN to construct the
- endpoint) by replicating it [4]_. As part of this process, it will
+ endpoint) by replicating it [3]_. As part of this process, it will
set the name field in each Node Object to the corresponding FQDN.
These node objects are then posted on the Chef Server to
corresponding Node Object REST endpoints to update the corresponding
**Ansible Server Requirements**
ONAP will utilize an Ansible server in order to manage VNFs that support Ansible playbooks. We note that Ansible in general does not require the use of a server. However, this framework has been adopted to align with ONAP architecture, ease of management and scalability.
-All playbooks for the VNF will be hosted on a designated Ansible Server that meets ONAP Ansible API requirements. ONAP design allows for VNFs to be managed by an Ansible Server in any of the two following forms [5]_:
+All playbooks for the VNF will be hosted on a designated Ansible Server that meets ONAP Ansible API requirements. ONAP design allows for VNFs to be managed by an Ansible Server in any of the two following forms [4]_:
- **Ansible Server hosted by ONAP**: ONAP will provide an Ansible Server to manage a VNF.
**Ansible Client Requirements**
-* R-32217 The VNF **MUST** have routable FQDNs that are reachable via the Ansible Server for the endpoints (VMs) of a VNF on which playbooks will be executed. ONAP will initiate requests to the Ansible Server for invocation of playbooks against these end points [6]_.
+* R-32217 The VNF **MUST** have routable FQDNs that are reachable via the Ansible Server for the endpoints (VMs) of a VNF on which playbooks will be executed. ONAP will initiate requests to the Ansible Server for invocation of playbooks against these end points [5]_.
* R-98929 The VNF **MAY** have a single endpoint.
* R-54373 The VNF **MUST** have Python >= 2.7 on the endpoint VM(s) of a VNF on which an Ansible playbook will be executed.
* R-35401 The VNF **MUST** must support SSH and allow SSH access to the Ansible server for the endpoint VM(s) and comply with the Network Cloud Service Provider guidelines for authentication and access.
An Ansible playbook is a collection of tasks that is executed on the Ansible server (local host) and/or the target VM (s) in order to complete the desired action.
* R-40293 The VNF **MUST** make available (or load on VNF Ansible Server) playbooks that conform to the ONAP requirement.
-* R-49396 The VNF **MUST** support each VNF action by invocation of **one** playbook [7]_. The playbook will be responsible for executing all necessary tasks (as well as calling other playbooks) to complete the request.
+* R-49396 The VNF **MUST** support each VNF 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 VNF **MUST NOT** use any instance specific parameters in a playbook.
* R-48698 The VNF **MUST** utilize information from key value pairs that will be provided by the Ansible Server as extra-vars during invocation to execute the desired VNF action. If the playbook requires files, they must also be supplied using the methodology detailed in the Ansible Server API.
**Encoding and Serialization**
-* R-19624 The VNF **MUST** encode and serialize content delivered to ONAP using JSON (option 1). High-volume data is to be encoded and serialized using Avro, where Avro data format are described using JSON (option 2) [8]_.
+* R-19624 The VNF **MUST** encode and serialize content delivered to ONAP using JSON (option 1). High-volume data is to be encoded and serialized using Avro, where Avro data format are described using JSON (option 2) [7]_.
- 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 VNF 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.
Streaming (VES) specifications. While this document is focused on
specifying some of the records from the ONAP perspective, there may be
other external bodies using the same framework to specify additional
-records. For example, OPNFV has a VES project [9]_ that is looking to
+records. For example, OPNFV has a VES project [8]_ that is looking to
specify records for OpenStack’s internal telemetry to manage Application
(VNFs), physical and virtual infrastructure (compute, storage, network
devices), and virtual infrastructure managers (cloud controllers, SDN
depicted.
|image0|
+
Figure 1. Data Model for Event Records
Event Records - Data Structure Description
structures mentioned above, please refer to `VES Event
Listener <https://github.com/att/evel-test-collector/tree/master/docs/att_interface_definition>`__.
-.. [2]
+.. [1]
https://github.com/mbj4668/pyang
-.. [3]
+.. [2]
Decision on which Chef Server instance associates with a VNF will be
made on a case-by-case basis depending on VNF, access requirements,
etc. and are outside the scope of this document. The specific
access required by the VNF, security, VNF topology and proprietary
cookbooks.
-.. [4]
+.. [3]
Recall that the Node Object **is required** to be identical across
all VMs of a VNF invoked as part of the action except for the “name”.
-.. [5]
+.. [4]
Decision on which Ansible Server to use may happen on a case-by-case
basis depending on VNF, access requirements etc. and are outside the
scope of this document. The specific criteria for this could involve
considerations like connectivity and access required by the VNF,
security, VNF topology and proprietary playbooks.
-.. [6]
+.. [5]
Upstream elements must provide the appropriate FQDN in the request to
ONAP for the desired action.
-.. [7]
+.. [6]
Multiple ONAP actions may map to one playbook.
-.. [8]
+.. [7]
This option is not currently supported in ONAP and it is currently
under consideration.
-.. [9]
+.. [8]
https://wiki.opnfv.org/display/PROJ/VNF+Event+Stream
-.. [10]
- The “name” field is a mandatory field in a valid Chef Node Object
- JSON dictionary.
-
.. |image0| image:: Data_Model_For_Event_Records.png
:width: 7in
:height: 8in
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 [10]_. Hence, it
+ 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.
R-55478: The VNF **MUST** log logoffs.
-R-14853: The VNF **MUST** respond to a "move traffic" [3]_ 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-14853: The VNF **MUST** respond to a "move traffic" [2]_ 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-68165: The VNF **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.
R-83873: The VNF **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 affected. This provides an 'all-or-nothing' edit mode for a single <edit-config> request.
-R-25238: The VNF PACKAGE **MUST** validated YANG code using the open source pyang [2]_ program using the following commands:
+R-25238: The VNF PACKAGE **MUST** validated YANG code using the open source pyang [3]_ program using the following commands:
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-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-32217: The VNF **MUST** have routable FQDNs that are reachable via the Ansible Server for the endpoints (VMs) of a VNF on which playbooks will be executed. ONAP will initiate requests to the Ansible Server for invocation of playbooks against these end points [6]_.
+R-32217: The VNF **MUST** have routable FQDNs that are reachable via the Ansible Server for the endpoints (VMs) of a VNF on which playbooks will be executed. ONAP will initiate requests to the Ansible Server for invocation of playbooks against these end points [4]_.
R-47849: The VNF Vendor **MUST** support the metadata about licenses (and their applicable entitlements) as defined in this document for VNF software, and any license keys required to authorize use of the VNF software. This metadata will be used to facilitate onboarding the VNF 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 Appendix C. Note: License metadata support in ONAP is not currently available and planned for 1Q 2018.
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-46960: The VNF **MUST** utilize only the Guest OS versions that are supported by the NCSP’s Network Cloud. [1]_
+R-46960: The VNF **MUST** utilize only the Guest OS versions that are supported by the NCSP’s Network Cloud. [5]_
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-93860: The VNF **MUST** provide the capability to integrate with an external encryption service.
-R-09467: The VNF **MUST** utilize only NCSP standard compute flavors. [2]_
+R-09467: The VNF **MUST** utilize only NCSP standard compute flavors. [5]_
R-62170: The VNF **MUST** over-ride any default values for configurable parameters that can be set by ONAP in the roles, cookbooks and recipes.
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-23475: The VNF **SHOULD** utilize only NCSP provided Guest OS images. [2]_
+R-23475: The VNF **SHOULD** utilize only NCSP provided Guest OS images. [5]_
R-64503: The VNF **MUST** provide minimum privileges for initial and default settings for new user accounts.
R-70496: The VNF **MUST** implement the protocol operation: **commit(confirmed, confirm-timeout)** - Commit candidate configuration datastore to the running configuration.
-R-19624: The VNF **MUST** encode and serialize content delivered to ONAP using JSON (option 1). High-volume data is to be encoded and serialized using Avro, where Avro data format are described using JSON (option 2) [8]_.
+R-19624: The VNF **MUST** encode and serialize content delivered to ONAP using JSON (option 1). High-volume data is to be encoded and serialized using Avro, where Avro data format are described using JSON (option 2) [6]_.
R-25094: The VNF **MUST** perform data capture for security functions.
R-71842: The VNF **MUST** include the field “service or program used for access” in the Security alarms (where applicable and technically feasible).
-R-54430: The VNF **MUST** use the NCSP’s supported library and compute flavor that supports DPDK to optimize network efficiency if using DPDK. [1]_
+R-54430: The VNF **MUST** use the NCSP’s supported library and compute flavor that supports DPDK to optimize network efficiency if using DPDK. [5]_
R-03465: The VNF **MUST** release locks to prevent permanent lock-outs when the corresponding <partial-unlock> operation succeeds.
.. [1]
- ECOMP (Enhanced Control Orchestration, Management & Policy)
- Architecture White Paper
- (http://about.att.com/content/dam/snrdocs/ecomp.pdf)
+ The “name” field is a mandatory field in a valid Chef Node Object
+ JSON dictionary.
.. [2]
- https://github.com/mbj4668/pyang
+ Not currently supported in ONAP release 1
.. [3]
- Decision on which Chef Server instance associates with a VNF will be
- made on a case-by-case basis depending on VNF, access requirements,
- etc. and are outside the scope of this document. The specific
- criteria for this would involve considerations like connectivity and
- access required by the VNF, security, VNF topology and proprietary
- cookbooks.
+ https://github.com/mbj4668/pyang
.. [4]
- Recall that the Node Object **is required** to be identical across
- all VMs of a VNF invoked as part of the action except for the “name”.
-
-.. [5]
- Decision on which Ansible Server to use may happen on a case-by-case
- basis depending on VNF, access requirements etc. and are outside the
- scope of this document. The specific criteria for this could involve
- considerations like connectivity and access required by the VNF,
- security, VNF topology and proprietary playbooks.
-
-.. [6]
Upstream elements must provide the appropriate FQDN in the request to
ONAP for the desired action.
-.. [7]
- Multiple ONAP actions may map to one playbook.
+.. [5]
+ Refer to NCSP’s Network Cloud specification
-.. [8]
+.. [6]
This option is not currently supported in ONAP and it is currently
under consideration.
-.. [9]
- https://wiki.opnfv.org/display/PROJ/VNF+Event+Stream
-
-.. [10]
- The “name” field is a mandatory field in a valid Chef Node Object
- JSON dictionary.
-
+.. [7]
+ Multiple ONAP actions may map to one playbook.
\ No newline at end of file
Code Review / vnfrqts / requirements.git / commitdiff