diff options
| -rw-r--r-- | docs/Chapter4.rst | 9 | ||||
| -rw-r--r-- | docs/Chapter5.rst | 1 | ||||
| -rw-r--r-- | docs/Chapter7.rst | 37 | ||||
| -rw-r--r-- | docs/Chapter8.rst | 58 |
4 files changed, 39 insertions, 66 deletions
diff --git a/docs/Chapter4.rst b/docs/Chapter4.rst index de5996c..340f967 100644 --- a/docs/Chapter4.rst +++ b/docs/Chapter4.rst @@ -862,15 +862,15 @@ the DevOps guidelines for VNFs. 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 @@ -903,7 +903,4 @@ Note: Refer to NCSP’s Network Cloud specification .. [2] - Refer to NCSP’s Network Cloud specification - -.. [3] Not currently supported in ONAP release 1 diff --git a/docs/Chapter5.rst b/docs/Chapter5.rst index 5e3e9b5..e98c89a 100644 --- a/docs/Chapter5.rst +++ b/docs/Chapter5.rst @@ -85,6 +85,7 @@ Node Template references a Node Type and adds usage constraints, such as how many times the component can occur. |image1| + Figure 1: Structural Elements of Service Template and their Relations TOSCA Modeling Principles & Data Model diff --git a/docs/Chapter7.rst b/docs/Chapter7.rst index 11ad167..5128978 100644 --- a/docs/Chapter7.rst +++ b/docs/Chapter7.rst @@ -208,7 +208,7 @@ industry standards. * 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 @@ -330,7 +330,7 @@ Chef-Client and Push Jobs Client on the VNF **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. @@ -390,7 +390,7 @@ action request against a Chef managed 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 @@ -448,7 +448,7 @@ manage VNFs that support Ansible. **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. @@ -461,7 +461,7 @@ All playbooks for the VNF will be hosted on a designated Ansible Server that mee **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. @@ -471,7 +471,7 @@ All playbooks for the VNF will be hosted on a designated Ansible Server that mee 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. @@ -658,7 +658,7 @@ Monitoring & Management Requirements **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. @@ -716,7 +716,7 @@ runtime lifecycle. This data model is referred to as the VNF Event 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 @@ -753,6 +753,7 @@ The Data Model consists of: depicted. |image0| + Figure 1. Data Model for Event Records Event Records - Data Structure Description @@ -885,10 +886,10 @@ For additional information on the event record formats of the data 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 @@ -896,35 +897,31 @@ Listener <https://github.com/att/evel-test-collector/tree/master/docs/att_interf 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 diff --git a/docs/Chapter8.rst b/docs/Chapter8.rst index b74f6cd..eeb2b0c 100644 --- a/docs/Chapter8.rst +++ b/docs/Chapter8.rst @@ -109,7 +109,7 @@ 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 [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. @@ -859,7 +859,7 @@ R-19768: The VNF **SHOULD** support L3 VPNs that enable segregation of traffic b 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. @@ -1017,7 +1017,7 @@ R-83790: The VNF **MUST** implement the **:validate** capability 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. @@ -1035,7 +1035,7 @@ R-02137: The VNF **MUST** implement all monitoring and logging as described in t 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. @@ -1057,7 +1057,7 @@ R-79107: The VNF **MUST**, if not using the NCSP’s IDAM API, enforce a configu 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. @@ -1145,7 +1145,7 @@ R-22367: The VNF **MUST** support detection of malformed packets due to software 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. @@ -1189,7 +1189,7 @@ R-35305: The VNF **MUST** meet the same guidelines as the Ansible Server hosted 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. @@ -1205,7 +1205,7 @@ R-70266: The VNF **MUST** respond to an ONAP request to deliver the current data 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. @@ -1433,7 +1433,7 @@ R-10716: The VNF **MUST** support parallel and simultaneous configuration of sep 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. @@ -1534,47 +1534,25 @@ R-20912: The VNF **MUST** support alternative monitoring capabilities when VNFs .. [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 |