diff options
| author |   Hagop Bozawglanian <hagop.bozawglanian@att.com> | 2019-04-17 04:30:50 +0000 |
|---|---|---|
| committer | Hagop Bozawglanian <hagop.bozawglanian@att.com> | 2019-04-17 04:30:50 +0000 |
| commit | a43ef5023419467adb704ea6c2f0b2b488fd0e38 (patch) | |
| tree | 1d560974abea26373294a1b1e19cd9c17054df06 | |
| parent | a0c6ca75f1ce52556a89ae21d8491c64107af636 (diff) | |
VNFRQTS - xNF to VNF or PNF
Change-Id: I4a6a445a6c713c4be53be8cd79e158a1a10bc975
Issue-ID: VNFRQTS-571
Signed-off-by: Hagop Bozawglanian <hagop.bozawglanian@att.com>
| -rw-r--r-- | docs/Chapter1/index.rst | 27 | ||||
| -rw-r--r-- | docs/Chapter2/index.rst | 11 | ||||
| -rw-r--r-- | docs/Chapter3/index.rst | 12 | ||||
| -rwxr-xr-x | docs/Chapter7/Configuration-Management.rst | 738 | ||||
| -rwxr-xr-x | docs/Chapter7/Monitoring-And-Management.rst | 214 | ||||
| -rwxr-xr-x | docs/Chapter7/VNF-On-boarding-and-package-management.rst | 214 | ||||
| -rwxr-xr-x | docs/Chapter7/index.rst | 2 | ||||
| -rw-r--r-- | docs/Chapter8/Ansible-JSON-Key-Value-Description.rst | 4 | ||||
| -rw-r--r-- | docs/Chapter8/Ansible-Playbook-Examples.rst | 2 | ||||
| -rw-r--r-- | docs/index.rst | 4 |
10 files changed, 615 insertions, 613 deletions
diff --git a/docs/Chapter1/index.rst b/docs/Chapter1/index.rst index a90f470..9b715dd 100644 --- a/docs/Chapter1/index.rst +++ b/docs/Chapter1/index.rst @@ -16,20 +16,21 @@ Purpose ======= -- The purpose of these requirements is to accelerate adoption of xNF best - practices which will increase innovation, minimize customization needed to - onboard xNFs as well as reduce implementation complexity, time and cost - for all impacted stakeholders. -- The consolidated requirements provide common xNF requirements across +- The purpose of these requirements is to accelerate adoption of VNF or PNF + best practices which will increase innovation, minimize customization needed + to onboard VNFs or PNFs as well as reduce implementation complexity, time and + cost for all impacted stakeholders. +- The consolidated requirements provide common VNF or PNF requirements across the industry in order to drive interoperability, simplify management, and - reduce cost to build, deploy and manage xNFs. + reduce cost to build, deploy and manage VNFs or PNFs. - These requirements serve multiple purposes: - - Primarily it provides a detailed list of requirements for xNF - providers to meet to be compatible with ONAP; xNF providers will use - the xNF requirements to build VNFs/PNFs that are compatible with ONAP + - Primarily it provides a detailed list of requirements for VNF or PNF + providers to meet to be compatible with ONAP; VNF or PNF providers will + use the VNF or PNF requirements to build VNFs/PNFs that are compatible + with ONAP. - It can also serve as a list of requirements that service providers can - use in RFPs for selecting VNFs/PNFs + use in RFPs for selecting VNFs/PNFs. - It will also be used as a basis for testing and certification of - xNFs for compliance with ONAP; ONAP projects such as the VNF - Validation Project will uses these xNFs requirements to build test - cases to validate xNFs for compliance with ONAP. + VNFs or PNFs for compliance with ONAP; ONAP projects such as the VNF + Validation Project will uses these VNFs or PNFs requirements to build + test cases to validate VNFs or PNFs for compliance with ONAP. diff --git a/docs/Chapter2/index.rst b/docs/Chapter2/index.rst index f8d490a..6e25788 100644 --- a/docs/Chapter2/index.rst +++ b/docs/Chapter2/index.rst @@ -16,18 +16,19 @@ Scope ===== -- The audience for this document are xNF providers, NCSPs and other +- The audience for this document are VNF or PNF providers, NCSPs and other interested 3rd parties who need to know the design, build and lifecycle - management requirements for xNFs to be compliant with ONAP. -- These requirements are strictly from a standpoint of what the xNF + management requirements for VNFs or PNFs to be compliant with ONAP. +- These requirements are strictly from a standpoint of what the VNF or PNF developer needs to know to operate and be compliant with ONAP. -- Requirements that are not applicable to xNF providers such as those +- Requirements that are not applicable to VNF or PNF providers such as those that applicable to service providers are not included in this document. - These requirements are applicable to the current release of ONAP. - Scope of the ONAP versions/release and future functionality - The VNF Requirements should include support for the functionality of the ONAP E-E use cases. -- These requirements apply to xNFs at both ONAP Design-Time and ONAP Run-Time. +- These requirements apply to VNFs or PNFs at both ONAP Design-Time and ONAP + Run-Time. - Network Service Descriptions are beyond the scope of these requirements. References diff --git a/docs/Chapter3/index.rst b/docs/Chapter3/index.rst index 12de543..cd0cef1 100644 --- a/docs/Chapter3/index.rst +++ b/docs/Chapter3/index.rst @@ -19,8 +19,8 @@ Introduction - Requirements are identified as either MUST, MUST NOT, SHOULD, SHOULD NOT, or MAY as defined in RFC 2119. - Requirements should be targeted to a restricted set of nouns related - to VNFs and within the control of the VNF provider. The current list - of VNF Requirement targets is: + to VNFs or PNFs and within the control of the VNF or PNF provider. The + current list of VNF or PNF Requirement targets is: +---------------------+-------------------------------------------------------+ | Target | When is it used | @@ -56,16 +56,16 @@ Introduction | | may be provided through the RFP/acquisition process. | +---------------------+-------------------------------------------------------+ -- Chapter 4 contains the xNF requirements involving the design and - development of xNFs. These requirements help VNFs/PNFs operate +- Chapter 4 contains the VNF or PNF requirements involving the design and + development of VNFs or PNF. These requirements help VNFs or PNFs operate efficiently within a cloud environment. Requirements cover design, resiliency, security, modularity and DevOps. -- Chapter 5 describes the different data models the xNF provider +- Chapter 5 describes the different data models the VNF or PNF provider needs to understand. There are currently 2 models described in this document: - The first model is the onboarding package data model. This is a TOSCA - model that will describe how all the elements passed from the VNF/PNF + model that will describe how all the elements passed from the VNF or PNF Provider to the Service provider should be formatted and packaged. - The second model is HEAT template used for orchestrating and instantiating virtual resources in an OpenStack environment. At this diff --git a/docs/Chapter7/Configuration-Management.rst b/docs/Chapter7/Configuration-Management.rst index 1e2ec72..e7e36bf 100755 --- a/docs/Chapter7/Configuration-Management.rst +++ b/docs/Chapter7/Configuration-Management.rst @@ -17,32 +17,32 @@ Configuration Management ------------------------ -Controller Interactions With xNF -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Controller Interactions With VNF or PNF +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ APPC/SDN-C expose a northbound API to clients (such as SO) in order for -the clients to initiate an activity (aka command) on a xNF. APPC/SDN-C -interact with xNFs through Network and Application Adapters to perform +the clients to initiate an activity (aka command) on a VNF or PNF. APPC/SDN-C +interact with VNFs or PNFs through Network and Application Adapters to perform configuration and other lifecycle management activities within NFV environment. The standardized models, protocols and mechanisms by which network functions are configured are equally applicable to VNFs and PNFs. This section describes the list of commands that should be supported -by the xNF. The following sections describe the standard protocols +by the VNF or PNF. The following sections describe the standard protocols that are supported (NETCONF, Chef, Ansible, and REST). -The commands below are expected to be supported on all xNF's, unless -The commands below are expected to be supported on all xNF's, unless +The commands below are expected to be supported on all VNF or PNF's, unless +The commands below are expected to be supported on all VNF or PNF's, unless noted otherwise, either directly (via the NETCONF or REST interface) or indirectly (via a Chef Cookbook or Ansible server). **Note that there are additional commands offered to northbound clients that are not shown below, as these commands either act internally on APPC/SDN-C itself or depend upon network cloud components for implementation (thus, these -actions do not put any special requirement on the xNF provider).** +actions do not put any special requirement on the VNF or PNF provider).** The commands allow for parametric data to be passed from APPC/SDN-C -to the xNF or Ansible/Chef server in the request. The format of the +to the VNF or PNF or Ansible/Chef server in the request. The format of the parameter data can be either xml (for NETCONF) or JSON (for Ansible, Chef, or REST). @@ -50,38 +50,38 @@ Configuration Commands ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ``Configure``: The APPC/SDN-C client is requesting that a post-instantiation -configuration be applied to the target xNF. After the Configure -action is completed, the xNF instance should be ready for service. +configuration be applied to the target VNF or PNF. After the Configure +action is completed, the VNF or PNF instance should be ready for service. Note that customer specific configurations may need to be applied using the ConfigModify action. This command requires exclusive access rights of -the xNF. +the VNF or PNF. ``ConfigModify``: The APPC client is requesting a configuration -update to a subset of the total configuration parameters of an xNF or to +update to a subset of the total configuration parameters of an VNF or PNF or to apply customer specific configurations. The configuration update is -typically done while the xNF is in service and should not disrupt traffic. -This command requires exclusive access rights of the xNF. +typically done while the VNF or PNF is in service and should not disrupt traffic. +This command requires exclusive access rights of the VNF or PNF. ``ConfigBackup``: The APPC client is requesting a backup of the -configuration parameters where the parameters are stored on the xNF. +configuration parameters where the parameters are stored on the VNF or PNF. This command is typically requested as part of an orchestration flow for scenarios such as a software upgrade. The ConfigBackup is typically -done while the xNF is not in service (i.e., in a maintenance state). -When the ConfigBackup command is executed, the current xNF configuration +done while the VNF or PNF is not in service (i.e., in a maintenance state). +When the ConfigBackup command is executed, the current VNF or PNF configuration parameters are saved in storage that is preserved (if there is an existing set of backed up parameters, they are overwritten). This command requires -exclusive access rights of the xNF. +exclusive access rights of the VNF or PNF. ``ConfigRestore``: The APPC client is requesting a restore action of -the configuration parameters to the xNF that were saved by ConfigBackup +the configuration parameters to the VNF or PNF that were saved by ConfigBackup command. This command is typically requested as part of an orchestration flow for scenarios such as a software upgrade where the software upgrade -may have failed and the xNF needs to be rolled back to the prior configuration. -When the ConfigRestore command is executed, the xNF configuration parameters -which were backed to persistent preserved storage are applied to the xNF +may have failed and the VNF or PNF needs to be rolled back to the prior configuration. +When the ConfigRestore command is executed, the VNF or PNF configuration parameters +which were backed to persistent preserved storage are applied to the VNF or PNF (replacing existing parameters). The ConfigRestore is typically done while -the xNF is not in service (i.e., in a maintenance state). This command -requires exclusive access rights of the xNF. +the VNF or PNF is not in service (i.e., in a maintenance state). This command +requires exclusive access rights of the VNF or PNF. ``ConfigScaleOut``: The APPC/SDN-C client is requesting that a configuration be applied after the VNF instance has been scaled out (i.e., one or more @@ -97,51 +97,51 @@ configuration update) is audited against the running configuration on the VNF .. req:: :id: R-20741 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** support APPC/SDN-C ``Configure`` command. + The VNF or PNF **MUST** support APPC/SDN-C ``Configure`` command. .. req:: :id: R-19366 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** support APPC ``ConfigModify`` command. + The VNF or PNF **MUST** support APPC ``ConfigModify`` command. .. req:: :id: R-32981 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** support APPC ``ConfigBackup`` command. + The VNF or PNF **MUST** support APPC ``ConfigBackup`` command. .. req:: :id: R-48247 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** support APPC ``ConfigRestore`` command. + The VNF or PNF **MUST** support APPC ``ConfigRestore`` command. .. req:: :id: R-94084 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** support APPC/SDN-C ``ConfigScaleOut`` command. + The VNF or PNF **MUST** support APPC/SDN-C ``ConfigScaleOut`` command. .. req:: :id: R-56385 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** support APPC ``Audit`` command. + The VNF or PNF **MUST** support APPC ``Audit`` command. Lifecycle Management Related Commands ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -164,147 +164,147 @@ command may need to follow traffic distribution changes (assigning weight 0 or very low weight to VNF instance). The VNF application remains in an active state. -``QuiesceTraffic`` The APPC/SDN-C client is requesting the xNF gracefully +``QuiesceTraffic`` The APPC/SDN-C client is requesting the VNF or PNF gracefully stop traffic (aka block and drain traffic). The method for quiescing traffic -is specific to the xNF architecture. The action is completed when all -(in-flight transactions) traffic has stopped. The xNF remains in an active -state where the xNF is able to process traffic (initiated using the +is specific to the VNF or PNF architecture. The action is completed when all +(in-flight transactions) traffic has stopped. The VNF or PNF remains in an active +state where the VNF or PNF is able to process traffic (initiated using the ResumeTraffic action). -``ResumeTraffic``: The APPC/SDN-C client is requesting the xNF resume -processing traffic. The method to resume traffic is specific to the xNF +``ResumeTraffic``: The APPC/SDN-C client is requesting the VNF or PNF resume +processing traffic. The method to resume traffic is specific to the VNF or PNF architecture. ``StopApplication``: The APPC client is requesting that the application -running on the xNF is stopped gracefully (i.e., without traffic loss). +running on the VNF or PNF is stopped gracefully (i.e., without traffic loss). This is equivalent to quiescing the traffic and then stopping the application processes. The processes can be restarted using the StartApplication command. ``StartApplication``: The APPC client is requesting that the application -running on the xNF is started. Get ready to process traffic. Traffic processing +running on the VNF or PNF is started. Get ready to process traffic. Traffic processing can be resumed using the ResumeTraffic command. **The following commands are needed to support software upgrades, in-place or -other type of software upgrade. The xNF instance may be removed from service +other type of software upgrade. The VNF or PNF instance may be removed from service for the upgrade.** ``UpgradePrecheck``: The APPC/SDN-C client is requesting a confirmation that -the xNF can (and needs to) be upgraded to a specific software version +the VNF or PNF can (and needs to) be upgraded to a specific software version (specified in the request). Checking software installed and running on -the xNF matches software version, intended to be upgraded, is one of the +the VNF or PNF matches software version, intended to be upgraded, is one of the recommended checks. ``UpgradeSoftware``: The APPC/SDN-C client is requesting that a (in-place) -software upgrade be performed on the xNF. The software to be applied is +software upgrade be performed on the VNF or PNF. The software to be applied is pre-loaded to a specified location. ``UpgradePostCheck``: The APPC/SDN-C client is requesting a confirmation that -the xNF software upgrade has been completed successfully (xNF upgraded to -the new software version). Checking software installed and running on the xNF +the VNF or PNF software upgrade has been completed successfully (VNF or PNF upgraded to +the new software version). Checking software installed and running on the VNF or PNF matches software version, of the newly upgraded software, is one of the recommended checks. -``UpgradeBackup``: The APPC/SDN-C client is requesting that the xNF is backed +``UpgradeBackup``: The APPC/SDN-C client is requesting that the VNF or PNF is backed up prior to the UpgradeSoftware. -``UpgradeBackOut``: The APPC/SDN-C client is requesting that the xNF upgrade +``UpgradeBackOut``: The APPC/SDN-C client is requesting that the VNF or PNF upgrade is backed out (in the event that the SoftwareUpgrade or UpgradePostCheck failed). .. req:: :id: R-328086 - :target: XNF + :target: VNF or PNF :keyword: MUST :introduced: casablanca - The xNF **MUST**, if serving as a distribution point or anchor point for + The VNF or PNF **MUST**, if serving as a distribution point or anchor point for steering point from source to destination, support the ONAP Controller's ``DistributeTraffic`` command. .. req:: :id: R-12706 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** support APPC/SDN-C ``QuiesceTraffic`` command. + The VNF or PNF **MUST** support APPC/SDN-C ``QuiesceTraffic`` command. .. req:: :id: R-07251 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** support APPC/SDN-C ``ResumeTraffic`` command. + The VNF or PNF **MUST** support APPC/SDN-C ``ResumeTraffic`` command. .. req:: :id: R-83146 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** support APPC ``StopApplication`` command. + The VNF or PNF **MUST** support APPC ``StopApplication`` command. .. req:: :id: R-82811 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** support APPC ``StartApplication`` command. + The VNF or PNF **MUST** support APPC ``StartApplication`` command. .. req:: :id: R-19922 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** support APPC/SDN-C ``UpgradePrecheck`` command. + The VNF or PNF **MUST** support APPC/SDN-C ``UpgradePrecheck`` command. .. req:: :id: R-49466 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** support APPC/SDN-C ``UpgradeSoftware`` command. + The VNF or PNF **MUST** support APPC/SDN-C ``UpgradeSoftware`` command. .. req:: :id: R-45856 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** support APPC/SDN-C ``UpgradePostCheck`` command. + The VNF or PNF **MUST** support APPC/SDN-C ``UpgradePostCheck`` command. .. req:: :id: R-97343 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** support APPC/SDN-C ``UpgradeBackup`` command. + The VNF or PNF **MUST** support APPC/SDN-C ``UpgradeBackup`` command. .. req:: :id: R-65641 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** support APPC/SDN-C ``UpgradeBackOut`` command. + The VNF or PNF **MUST** support APPC/SDN-C ``UpgradeBackOut`` command. HealthCheck and Failure Related Commands ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ``HealthCheck`` The APPC/SDN-C client is requesting a health check over the -entire scope of the xNF. The xNF must be 100% healthy, ready to take requests -and provide services, with all xNF required capabilities ready to provide +entire scope of the VNF or PNF. The VNF or PNF must be 100% healthy, ready to take requests +and provide services, with all VNF or PNF required capabilities ready to provide services and with all active and standby resources fully ready with no open MINOR, MAJOR or CRITICAL alarms. This is expected to be the default in the event that no parameter is passed to the Healthcheck playbook, cookbook, etc. -Some xNFs may support and desire to run partial healthchecks and receive a +Some VNFs or PNFs may support and desire to run partial healthchecks and receive a successful response when partial health check completes without errors. The parameter name used by HealthCheck playbook to request non-default partial health check is healthcheck_type. Example of health check types @@ -321,24 +321,24 @@ automated fashion. .. req:: :id: R-41430 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** support APPC/SDN-C ``HealthCheck`` command. + The VNF or PNF **MUST** support APPC/SDN-C ``HealthCheck`` command. Notes On Command Support Using APPC/SDN-C Southbound Protocols ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ APPC/SDN-C are designed to support a standard set of protocols in -order to communicate with the xNF instance. The supported protocols are +order to communicate with the VNF or PNF instance. The supported protocols are NETCONF, Ansible, Chef, and REST. -NETCONF and REST require the xNF to implement a server which supports the RPC +NETCONF and REST require the VNF or PNF to implement a server which supports the RPC or REST calls. Ansible and Chef require the use of a Ansible or Chef server which communicates -with the APPC/SDN-C (northbound) and the xNF VM's (southbound). +with the APPC/SDN-C (northbound) and the VNF or PNF VM's (southbound). The vendor must select which protocol to support for the commands listed above. Notes: @@ -360,12 +360,12 @@ NETCONF Standards and Capabilities ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ APPC/SDN-C and their Adapters utilize device YANG model and -NETCONF APIs to make the required changes in the xNF state and -configuration. The xNF providers must provide the Device YANG model and +NETCONF APIs to make the required changes in the VNF or PNF state and +configuration. The VNF or PNF providers must provide the Device YANG model and NETCONF server supporting NETCONF APIs to comply with target ONAP and industry standards. -xNF Configuration via NETCONF Requirements +VNF or PNF Configuration via NETCONF Requirements ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Configuration Management @@ -374,18 +374,18 @@ Configuration Management .. req:: :id: R-88026 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** include a NETCONF server enabling + The VNF or PNF **MUST** include a NETCONF server enabling runtime configuration and lifecycle management capabilities. .. req:: :id: R-95950 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** provide a NETCONF interface fully defined + The VNF or PNF **MUST** provide a NETCONF interface fully defined by supplied YANG models for the embedded NETCONF server. NETCONF Server Requirements @@ -394,163 +394,163 @@ NETCONF Server Requirements .. req:: :id: R-73468 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** allow the NETCONF server connection + The VNF or PNF **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. .. req:: :id: R-90007 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** implement the protocol operation: + The VNF or PNF **MUST** implement the protocol operation: ``close-session()`` - Gracefully close the current session. .. req:: :id: R-70496 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** implement the protocol operation: + The VNF or PNF **MUST** implement the protocol operation: ``commit(confirmed, confirm-timeout)`` - Commit candidate configuration data store to the running configuration. .. req:: :id: R-18733 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** implement the protocol operation: + The VNF or PNF **MUST** implement the protocol operation: ``discard-changes()`` - Revert the candidate configuration data store to the running configuration. .. req:: :id: R-44281 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** implement the protocol operation: + The VNF or PNF **MUST** implement the protocol operation: ``edit-config(target, default-operation, test-option, error-option, config)`` - Edit the target configuration data store by merging, replacing, creating, or deleting new config elements. .. req:: :id: R-60106 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** implement the protocol operation: + The VNF or PNF **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. + the list of VNF or PNF supported schemas. .. req:: :id: R-29488 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** implement the protocol operation: + The VNF or PNF **MUST** implement the protocol operation: ``get-config(source, filter`` - Retrieve a (filtered subset of a) configuration from the configuration data store source. .. req:: :id: R-11235 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** implement the protocol operation: + The VNF or PNF **MUST** implement the protocol operation: ``kill-session(session``- Force the termination of **session**. .. req:: :id: R-02597 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** implement the protocol operation: + The VNF or PNF **MUST** implement the protocol operation: ``lock(target)`` - Lock the configuration data store target. .. req:: :id: R-96554 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** implement the protocol operation: + The VNF or PNF **MUST** implement the protocol operation: ``unlock(target)`` - Unlock the configuration data store target. .. req:: :id: R-29324 - :target: XNF + :target: VNF or PNF :keyword: SHOULD :updated: casablanca - The xNF **SHOULD** implement the protocol operation: + The VNF or PNF **SHOULD** implement the protocol operation: ``copy-config(target, source)`` - Copy the content of the configuration data store source to the configuration data store target. .. req:: :id: R-88031 - :target: XNF + :target: VNF or PNF :keyword: SHOULD :updated: casablanca - The xNF **SHOULD** implement the protocol operation: + The VNF or PNF **SHOULD** implement the protocol operation: ``delete-config(target)`` - Delete the named configuration data store target. .. req:: :id: R-97529 - :target: XNF + :target: VNF or PNF :keyword: SHOULD - The xNF **SHOULD** implement the protocol operation: + The VNF or PNF **SHOULD** implement the protocol operation: ``get-schema(identifier, version, format)`` - Retrieve the YANG schema. .. req:: :id: R-62468 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** allow all configuration data to be + The VNF or PNF **MUST** allow all configuration data to be edited through a NETCONF <edit-config> operation. Proprietary NETCONF RPCs that make configuration changes are not sufficient. .. req:: :id: R-01382 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** allow the entire configuration of the xNF to be + The VNF or PNF **MUST** allow the entire configuration of the VNF or PNF to be retrieved via NETCONF's <get-config> and <edit-config>, independently of whether it was configured via NETCONF or other mechanisms. .. req:: :id: R-28756 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** support ``:partial-lock`` and + The VNF or PNF **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. .. req:: :id: R-83873 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** support ``:rollback-on-error`` value for + The VNF or PNF **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. @@ -559,19 +559,19 @@ NETCONF Server Requirements .. req:: :id: R-68990 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** support the ``:startup`` capability. It + The VNF or PNF **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. .. req:: :id: R-68200 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** support the ``:url`` value to specify + The VNF or PNF **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' @@ -580,19 +580,19 @@ NETCONF Server Requirements .. req:: :id: R-20353 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** implement both ``:candidate`` and + The VNF or PNF **MUST** implement both ``:candidate`` and ``:writable-running`` capabilities. When both ``:candidate`` and ``:writable-running`` are provided then two locks should be supported. .. req:: :id: R-11499 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** fully support the XPath 1.0 specification + The VNF or PNF **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 @@ -603,33 +603,33 @@ NETCONF Server Requirements .. req:: :id: R-83790 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** implement the ``:validate`` capability. + The VNF or PNF **MUST** implement the ``:validate`` capability. .. req:: :id: R-49145 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** implement ``:confirmed-commit`` If + The VNF or PNF **MUST** implement ``:confirmed-commit`` If ``:candidate`` is supported. .. req:: :id: R-58358 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** implement the ``:with-defaults`` capability + The VNF or PNF **MUST** implement the ``:with-defaults`` capability [RFC6243]. .. req:: :id: R-59610 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** implement the data model discovery and + The VNF or PNF **MUST** implement the data model discovery and download as defined in [RFC6022]. .. req:: @@ -654,40 +654,40 @@ NETCONF Server Requirements .. req:: :id: R-10716 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** support parallel and simultaneous + The VNF or PNF **MUST** support parallel and simultaneous configuration of separate objects within itself. .. req:: :id: R-29495 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** support locking if a common object is + The VNF or PNF **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 + on the same VNF or PNF 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). .. req:: :id: R-53015 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** apply locking based on the sequence of + The VNF or PNF **MUST** apply locking based on the sequence of NETCONF operations, with the first configuration operation locking out all others until completed. .. req:: :id: R-02616 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** permit locking at the finest granularity - if a xNF needs to lock an object for configuration to avoid blocking + The VNF or PNF **MUST** permit locking at the finest granularity + if a VNF or PNF 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 @@ -695,96 +695,96 @@ NETCONF Server Requirements .. req:: :id: R-41829 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** be able to specify the granularity of the + The VNF or PNF **MUST** be able to specify the granularity of the lock via a restricted or full XPath expression. .. req:: :id: R-66793 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** guarantee the xNF configuration integrity + The VNF or PNF **MUST** guarantee the VNF or PNF 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 + EVC, then they need to be sequenced in the VNF or PNF without locking either configuration method out). .. req:: :id: R-54190 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** release locks to prevent permanent lock-outs + The VNF or PNF **MUST** release locks to prevent permanent lock-outs when/if a session applying the lock is terminated (e.g., SSH session is terminated). .. req:: :id: R-03465 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** release locks to prevent permanent lock-outs + The VNF or PNF **MUST** release locks to prevent permanent lock-outs when the corresponding <partial-unlock> operation succeeds. .. req:: :id: R-63935 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** release locks to prevent permanent lock-outs + The VNF or PNF **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). .. req:: :id: R-10173 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** allow another NETCONF session to be able to + The VNF or PNF **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. .. req:: :id: R-88899 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** support simultaneous <commit> operations + The VNF or PNF **MUST** support simultaneous <commit> operations within the context of this locking requirements framework. .. req:: :id: R-07545 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** support all operations, administration and - management (OAM) functions available from the supplier for xNFs using + The VNF or PNF **MUST** support all operations, administration and + management (OAM) functions available from the supplier for VNFs or PNFs using the supplied YANG code and associated NETCONF servers. .. req:: :id: R-60656 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** support sub tree filtering. + The VNF or PNF **MUST** support sub tree filtering. .. req:: :id: R-80898 - :target: XNF + :target: VNF or PNF :keyword: MUST - TThe xNF **MUST** support heartbeat via a <get> with null filter. + TThe VNF or PNF **MUST** support heartbeat via a <get> with null filter. .. req:: :id: R-25238 :target: VNF :keyword: MUST - The xNF PACKAGE **MUST** validated YANG code using the open + The VNF or PNF PACKAGE **MUST** validated YANG code using the open source pyang [#7.3.1]_ program using the following commands: .. code-block:: text @@ -793,18 +793,18 @@ NETCONF Server Requirements .. req:: :id: R-63953 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** have the echo command return a zero value + The VNF or PNF **MUST** have the echo command return a zero value otherwise the validation has failed. .. req:: :id: R-26508 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** support a NETCONF server that can be mounted on + The VNF or PNF **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 @@ -816,82 +816,82 @@ conform, and those where applicable, that suppliers need to use. .. req:: :id: R-22700 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** conform its YANG model to RFC 6470, + The VNF or PNF **MUST** conform its YANG model to RFC 6470, "NETCONF Base Notifications". .. req:: :id: R-10353 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** conform its YANG model to RFC 6244, + The VNF or PNF **MUST** conform its YANG model to RFC 6244, "An Architecture for Network Management Using NETCONF and YANG". .. req:: :id: R-53317 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** conform its YANG model to RFC 6087, + The VNF or PNF **MUST** conform its YANG model to RFC 6087, "Guidelines for Authors and Reviewers of YANG Data Model specification". .. req:: :id: R-33955 - :target: XNF + :target: VNF or PNF :keyword: SHOULD - The xNF **SHOULD** conform its YANG model to RFC 6991, + The VNF or PNF **SHOULD** conform its YANG model to RFC 6991, "Common YANG Data Types". .. req:: :id: R-22946 - :target: XNF + :target: VNF or PNF :keyword: SHOULD - The xNF **SHOULD** conform its YANG model to RFC 6536, + The VNF or PNF **SHOULD** conform its YANG model to RFC 6536, "NETCONF Access Control Model". .. req:: :id: R-10129 - :target: XNF + :target: VNF or PNF :keyword: SHOULD - The xNF **SHOULD** conform its YANG model to RFC 7223, + The VNF or PNF **SHOULD** conform its YANG model to RFC 7223, "A YANG Data Model for Interface Management". .. req:: :id: R-12271 - :target: XNF + :target: VNF or PNF :keyword: SHOULD - The xNF **SHOULD** conform its YANG model to RFC 7223, + The VNF or PNF **SHOULD** conform its YANG model to RFC 7223, "IANA Interface Type YANG Module". .. req:: :id: R-49036 - :target: XNF + :target: VNF or PNF :keyword: SHOULD - The xNF **SHOULD** conform its YANG model to RFC 7277, + The VNF or PNF **SHOULD** conform its YANG model to RFC 7277, "A YANG Data Model for IP Management". .. req:: :id: R-87564 - :target: XNF + :target: VNF or PNF :keyword: SHOULD - The xNF **SHOULD** conform its YANG model to RFC 7317, + The VNF or PNF **SHOULD** conform its YANG model to RFC 7317, "A YANG Data Model for System Management". .. req:: :id: R-24269 - :target: XNF + :target: VNF or PNF :keyword: SHOULD - The xNF **SHOULD** conform its YANG model to RFC 7407, + The VNF or PNF **SHOULD** conform its YANG model to RFC 7407, "A YANG Data Model for SNMP Configuration", if Netconf used to configure SNMP engine. @@ -901,50 +901,50 @@ NETCONF RFCs. .. req:: :id: R-33946 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** conform to the NETCONF RFC 4741, + The VNF or PNF **MUST** conform to the NETCONF RFC 4741, "NETCONF Configuration Protocol". .. req:: :id: R-04158 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** conform to the NETCONF RFC 4742, + The VNF or PNF **MUST** conform to the NETCONF RFC 4742, "Using the NETCONF Configuration Protocol over Secure Shell (SSH)". .. req:: :id: R-13800 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** conform to the NETCONF RFC 5277, + The VNF or PNF **MUST** conform to the NETCONF RFC 5277, "NETCONF Event Notification". .. req:: :id: R-01334 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** conform to the NETCONF RFC 5717, + The VNF or PNF **MUST** conform to the NETCONF RFC 5717, "Partial Lock Remote Procedure Call". .. req:: :id: R-08134 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** conform to the NETCONF RFC 6241, + The VNF or PNF **MUST** conform to the NETCONF RFC 6241, "NETCONF Configuration Protocol". .. req:: :id: R-78282 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** conform to the NETCONF RFC 6242, + The VNF or PNF **MUST** conform to the NETCONF RFC 6242, "Using the Network Configuration Protocol over Secure Shell". .. req:: @@ -959,8 +959,8 @@ NETCONF RFCs. .. _xnf_rest_apis: -xNF REST APIs -^^^^^^^^^^^^^^^ +VNF or PNF REST APIs +^^^^^^^^^^^^^^^^^^^^ HealthCheck is a command for which no NETCONF support exists. Therefore, this must be supported using a RESTful interface @@ -971,27 +971,27 @@ Therefore, this must be supported using a RESTful interface See section 7.3.1.4 for the definition of Full Healthcheck and Partial Healthchecks. -The xNF must provide a REST formatted GET RPCs to support HealthCheck +The VNF or PNF must provide a REST formatted GET RPCs to support HealthCheck queries via the GET method over HTTP(s). The port number, url, and other authentication information is provided -by the xNF provider. +by the VNF or PNF provider. REST APIs ~~~~~~~~~ .. req:: :id: R-31809 - :target: XNF + :target: VNF or PNF :keyword: MUST - 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, + The VNF or PNF **MUST** support the HealthCheck RPC. The HealthCheck + RPC executes a VNF or PNF Provider-defined VNF or PNF HealthCheck over the scope of + the entire VNF or PNF (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 + information. If the VNF or PNF is unable to run the HealthCheck, return a standard http error code and message. Examples of responses when HealthCheck runs and is able to provide a healthy @@ -1023,23 +1023,23 @@ or unhealthy response: Chef Standards and Capabilities ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -ONAP will support configuration of xNFs via Chef subject to the +ONAP will support configuration of VNFs or PNFs via Chef subject to the requirements and guidelines defined in this section. The Chef configuration management mechanism follows a client-server -model. It requires the presence of a Chef-Client on the xNF that will be +model. It requires the presence of a Chef-Client on the VNF or PNF that will be directly managed by a Chef Server. The Chef-client will register with the appropriate Chef Server and are managed via 'cookbooks' and configuration attributes loaded on the Chef Server which contain all -necessary information to execute the appropriate actions on the xNF via +necessary information to execute the appropriate actions on the VNF or PNF via the Chef-client. ONAP will utilize the open source Chef Server, invoke the documented -Chef REST APIs to manage the xNF and requires the use of open source -Chef-Client and Push Jobs Client on the xNF +Chef REST APIs to manage the VNF or PNF and requires the use of open source +Chef-Client and Push Jobs Client on the VNF or PNF (https://downloads.chef.io/). -xNF Configuration via Chef Requirements +VNF or PNF Configuration via Chef Requirements ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chef Client Requirements @@ -1048,29 +1048,29 @@ Chef Client Requirements .. req:: :id: R-79224 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** have the chef-client be preloaded with + The VNF or PNF **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. .. req:: :id: R-72184 - :target: XNF + :target: VNF or PNF :keyword: MUST - 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. + The VNF or PNF **MUST** have routable FQDNs for all the endpoints + (VMs) of a VNF or PNF that contain chef-clients which are used to register + with the Chef Server. As part of invoking VNF or PNF actions, ONAP will + trigger push jobs against FQDNs of endpoints for a VNF or PNF, if required. .. req:: :id: R-47068 - :target: XNF + :target: VNF or PNF :keyword: MAY - The xNF **MAY** expose a single endpoint that is + The VNF or PNF **MAY** expose a single endpoint that is responsible for all functionality. .. req:: @@ -1078,7 +1078,7 @@ Chef Client Requirements :target: VNF :keyword: MUST - The xNF **MUST** be installed with Chef-Client >= 12.0 and Chef + The VNF or PNF **MUST** be installed with Chef-Client >= 12.0 and Chef push jobs client >= 2.0. Chef Roles/Requirements @@ -1086,89 +1086,89 @@ Chef Roles/Requirements .. req:: :id: R-27310 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF Package **MUST** include all relevant Chef artifacts - (roles/cookbooks/recipes) required to execute xNF actions requested by + The VNF or PNF Package **MUST** include all relevant Chef artifacts + (roles/cookbooks/recipes) required to execute VNF or PNF actions requested by ONAP for loading on appropriate Chef Server. .. req:: :id: R-26567 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - 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, APPC/SDN-C APIs and Behavior, for list of xNF + The VNF or PNF Package **MUST** include a run list of + roles/cookbooks/recipes, for each supported VNF or PNF action, that will + perform the desired VNF or PNF action in its entirety as specified by ONAP + (see Section 7.c, APPC/SDN-C APIs and Behavior, for list of VNF or PNF actions and requirements), when triggered by a chef-client run list in JSON file. .. req:: :id: R-98911 - :target: XNF + :target: VNF or PNF :keyword: MUST NOT - The xNF **MUST NOT** use any instance specific parameters - for the xNF in roles/cookbooks/recipes invoked for a xNF action. + The VNF or PNF **MUST NOT** use any instance specific parameters + for the VNF or PNF in roles/cookbooks/recipes invoked for a VNF or PNF action. .. req:: :id: R-37929 - :target: XNF + :target: VNF or PNF :keyword: MUST - 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. + The VNF or PNF **MUST** accept all necessary instance specific + data from the environment or node object attributes for the VNF or PNF + in roles/cookbooks/recipes invoked for a VNF or PNF action. .. req:: :id: R-62170 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** over-ride any default values for + The VNF or PNF **MUST** over-ride any default values for configurable parameters that can be set by ONAP in the roles, cookbooks and recipes. .. req:: :id: R-78116 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** update status on the Chef Server + The VNF or PNF **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. + executing a VNF or PNF action. .. req:: :id: R-44013 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** populate an attribute, defined as node + The VNF or PNF **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 + that execute chef-client run if the VNF or PNF action requires the output of a chef-client run be made available (e.g., get running configuration). .. req:: :id: R-30654 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF Package **MUST** have appropriate cookbooks that are + The VNF or PNF 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). + any errors for actions that change state of the VNF or PNF (e.g., configure). .. req:: :id: R-65755 - :target: XNF + :target: VNF or PNF :keyword: SHOULD - The xNF **SHOULD** support callback URLs to return information + The VNF or PNF **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. + associated with a VNF or PNF action. - As part of the push job, ONAP will provide two parameters in the environment of the push job JSON object: @@ -1181,26 +1181,26 @@ Chef Roles/Requirements .. req:: :id: R-15885 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** Upon completion of the chef-client run, + The VNF or PNF **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 + completes the VNF or PNF action, it should reflect this status on the Chef Server regardless of whether the Callback succeeded or not. ONAP Chef API Usage ~~~~~~~~~~~~~~~~~~~ This section outlines the workflow that ONAP invokes when it receives an -action request against a Chef managed xNF. +action request against a Chef managed VNF or PNF. -1. When ONAP receives a request for an action for a Chef Managed xNF, it +1. When ONAP receives a request for an action for a Chef Managed VNF or PNF, it retrieves the corresponding template (based on **action** and - **xNF**) from its database and sets necessary values in the + **VNF or PNF**) from its database and sets necessary values in the "Environment", "Node" and "NodeList" keys (if present) from either the payload of the received action or internal data. @@ -1251,18 +1251,18 @@ action request against a Chef managed xNF. Ansible Standards and Capabilities ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -ONAP will support configuration of xNFs via Ansible subject to the +ONAP will support configuration of VNFs or PNFs via Ansible subject to the requirements and guidelines defined in this section. -Ansible allows agentless management of xNFs/VMs/VNFCs via execution +Ansible allows agentless management of VNFs or PNFs/VMs/VNFCs via execution of 'playbooks' over ssh. The 'playbooks' are a structured set of tasks which contain all the necessary resources and execution capabilities to take the necessary action on one or more target VMs (and/or VNFCs) of the VNF. ONAP will utilize the framework of an Ansible Server that -will host all Ansible artifacts and run playbooks to manage xNFs that support +will host all Ansible artifacts and run playbooks to manage VNFs or PNFs that support Ansible. -xNF Configuration via Ansible Requirements +VNF or PNF Configuration via Ansible Requirements ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ansible Client Requirements @@ -1271,52 +1271,52 @@ Ansible Client Requirements .. req:: :id: R-32217 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** have routable management IP addresses or FQDNs that + The VNF or PNF **MUST** have routable management IP addresses or FQDNs that are reachable via the Ansible Server for the endpoints (VMs) of a - xNF that playbooks will target. ONAP will initiate requests to the + VNF or PNF that playbooks will target. ONAP will initiate requests to the Ansible Server for invocation of playbooks against these end points [#7.3.3]_. .. req:: :id: R-54373 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** have Python >= 2.6 on the endpoint VM(s) - of a xNF on which an Ansible playbook will be executed. + The VNF or PNF **MUST** have Python >= 2.6 on the endpoint VM(s) + of a VNF or PNF on which an Ansible playbook will be executed. .. req:: :id: R-35401 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** support SSH and allow SSH access by the + The VNF or PNF **MUST** support SSH and allow SSH access by the Ansible server to the endpoint VM(s) and comply with the Network Cloud Service Provider guidelines for authentication and access. .. req:: :id: R-82018 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** load the Ansible Server SSH public key onto xNF + The VNF or PNF **MUST** load the Ansible Server SSH public key onto VNF or PNF VM(s) /root/.ssh/authorized_keys as part of instantiation. Alternative, - is for Ansible Server SSH public key to be loaded onto xNF VM(s) under + is for Ansible Server SSH public key to be loaded onto VNF or PNF VM(s) under /home/<Mechanized user ID>/.ssh/authorized_keys as part of instantiation, when a Mechanized user ID is created during instantiation, and Configure and all playbooks are designed to use a mechanized user ID only for authentication (never using root authentication during Configure playbook run). 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. + requiring specific VNF or PNF login IDs and passwords. - *CAUTION*: For xNFs configured using Ansible, to eliminate the need + *CAUTION*: For VNFs or PNFs configured using Ansible, to eliminate the need for manual steps, post-instantiation and pre-configuration, to upload of SSH public keys, SSH public keys loaded during (heat) instantiation shall be preserved and not removed by (heat) embedded @@ -1324,11 +1324,11 @@ Ansible Client Requirements .. req:: :id: R-92866 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** include as part of post-instantiation configuration + The VNF or PNF **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 creating Mechanized user @@ -1337,87 +1337,87 @@ Ansible Client Requirements .. req:: :id: R-97345 - :target: XNF + :target: VNF or PNF :keyword: MUST :introduced: casablanca - The xNF **MUST** permit authentication, using root account, only right + The VNF or PNF **MUST** permit authentication, using root account, only right after instantiation and until post-instantiation configuration is completed. .. req:: :id: R-97451 - :target: XNF + :target: VNF or PNF :keyword: MUST :introduced: casablanca - The xNF **MUST** provide the ability to remove root access once + The VNF or PNF **MUST** provide the ability to remove root access once post-instantiation configuration (Configure) is completed. .. req:: :id: R-91745 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** update the Ansible Server and other entities + The VNF or PNF **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. **Note**: Ansible Server itself may be used to upload new SSH public - keys onto supported xNFs. + keys onto supported VNFs or PNFs. .. req:: :id: R-73459 - :target: XNF + :target: VNF or PNF :keyword: MUST :introduced: casablanca - The xNF **MUST** provide the ability to include a "from=" clause in SSH + The VNF or PNF **MUST** provide the ability to include a "from=" clause in SSH public keys associated with mechanized user IDs created for an Ansible - Server cluster to use for xNF VM authentication. + Server cluster to use for VNF or PNF VM authentication. .. req:: :id: R-45197 - :target: XNF + :target: VNF or PNF :keyword: MUST :introduced: casablanca - The xNF **MUST** define the "from=" clause to provide the list of IP + The VNF or PNF **MUST** define the "from=" clause to provide the list of IP addresses of the Ansible Servers in the Cluster, separated by coma, to restrict use of the SSH key pair to elements that are part of the Ansible Cluster owner of the issued and assigned mechanized user ID. .. req:: :id: R-94567 - :target: XNF + :target: VNF or PNF :keyword: MUST :introduced: casablanca - The xNF **MUST** provide Ansible playbooks that are designed to run using + The VNF or PNF **MUST** provide Ansible playbooks that are designed to run using an inventory hosts file in a supported format with only IP addresses or - IP addresses and VM/xNF names. + IP addresses and VM/VNF or PNF names. .. req:: :id: R-67124 - :target: XNF + :target: VNF or PNF :keyword: MUST :introduced: casablanca - The xNF **MUST** provide Ansible playbooks that are designed to run using + The VNF or PNF **MUST** provide Ansible playbooks that are designed to run using an inventory hosts file in a supported format; with group names matching VNFC 3-character string adding "vip" for groups with virtual IP addresses shared by multiple VMs as seen in examples provided in Appendix. .. req:: :id: R-24482 - :target: XNF + :target: VNF or PNF :keyword: MUST :introduced: casablanca - The xNF **MUST** provide Ansible playbooks that are designed to run using + The VNF or PNF **MUST** provide Ansible playbooks that are designed to run using an inventory hosts file in a supported format; with site group that shall - be used to add site specific configurations to the target xNF VM(s) as + be used to add site specific configurations to the target VNF or PNF VM(s) as needed. Ansible Playbook Requirements @@ -1429,49 +1429,49 @@ complete the desired action. .. req:: :id: R-49751 - :target: XNF + :target: VNF or PNF :keyword: MUST :introduced: casablanca - The xNF **MUST** support Ansible playbooks that are compatible with + The VNF or PNF **MUST** support Ansible playbooks that are compatible with Ansible version 2.6 or later. .. req:: :id: R-40293 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** make available playbooks that conform + The VNF or PNF **MUST** make available playbooks that conform to the ONAP requirement. .. req:: :id: R-49396 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** support each APPC/SDN-C xNF action + The VNF or PNF **MUST** support each APPC/SDN-C VNF or PNF action by invocation of **one** playbook [#7.3.4]_. The playbook will be responsible for executing all necessary tasks (as well as calling other playbooks) to complete the request. .. req:: :id: R-33280 - :target: XNF + :target: VNF or PNF :keyword: MUST NOT - The xNF **MUST NOT** use any instance specific parameters + The VNF or PNF **MUST NOT** use any instance specific parameters in a playbook. .. req:: :id: R-48698 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** utilize information from key value pairs that will be + The VNF or PNF **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. The "extra-vars" attribute-value pairs + execute the desired VNF or PNF action. The "extra-vars" attribute-value pairs are passed to the Ansible Server by an APPC/SDN-C as part of the Rest API request. If the playbook requires files, they must also be supplied using the methodology detailed in the Ansible Server API, unless @@ -1479,11 +1479,11 @@ complete the desired action. containing instance specific info (attribute-value pairs), not obtainable from any ONAP inventory databases or other sources, referenced and used an input by playbooks, shall be provisioned (and distributed) in advance of - use, e.g., xNF instantiation. Recommendation is to avoid these instance + use, e.g., VNF or PNF instantiation. Recommendation is to avoid these instance specific, manually created in advance of instantiation, files. The Ansible Server will determine if a playbook invoked to execute an -xNF action finished successfully or not using the "PLAY_RECAP" summary +VNF or PNF action finished successfully or not using the "PLAY_RECAP" summary in Ansible log. The playbook will be considered to successfully finish only if the "PLAY RECAP" section at the end of playbook execution output has no unreachable hosts and no failed tasks. Otherwise, the playbook @@ -1492,10 +1492,10 @@ will be considered to have failed. .. req:: :id: R-43253 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** use playbooks designed to allow Ansible + The VNF or PNF **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 @@ -1504,43 +1504,43 @@ will be considered to have failed. .. req:: :id: R-50252 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** write to a response file in JSON format 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 + The VNF or PNF **MUST** write to a response file in JSON format that will be + retrieved and made available by the Ansible Server if, as part of a VNF or PNF + action (e.g., audit), a playbook is required to return any VNF or PNF information/response. The text files must be written in the main playbook - home directory, in JSON format. The JSON file must be created for the xNF - with the name '<xNF name>_results.txt'. All playbook output results, for - all xNF VMs, to be provided as a response to the request, must be written + home directory, in JSON format. The JSON file must be created for the VNF or PNF + with the name '<VNF or PNF name>_results.txt'. All playbook output results, for + all VNF or PNF VMs, to be provided as a response to the request, must be written to this response file. .. req:: :id: R-51442 - :target: XNF + :target: VNF or PNF :keyword: SHOULD :updated: casablanca - The xNF **SHOULD** use playbooks that are designed to + The VNF or PNF **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). + for actions that change state of the VNF or PNF (e.g., configure). **Note**: In case rollback at the playbook level is not supported or - possible, the xNF provider shall provide alternative rollback - mechanism (e.g., for a small xNF the rollback mechanism may rely + possible, the VNF or PNF provider shall provide alternative rollback + mechanism (e.g., for a small VNF or PNF the rollback mechanism may rely on workflow to terminate and re-instantiate VNF VMs and then re-run playbook(s)). Backing up updated files is also recommended to support rollback when soft rollback is feasible. .. req:: :id: R-58301 - :target: XNF + :target: VNF or PNF :keyword: SHOULD NOT :updated: casablanca - The xNF **SHOULD NOT** use playbooks that make requests to + The VNF or PNF **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 Playbook related artifacts. @@ -1556,11 +1556,11 @@ will be considered to have failed. .. req:: :id: R-02651 - :target: XNF + :target: VNF or PNF :keyword: SHOULD :updated: casablanca - The xNF **SHOULD** use available backup capabilities to save a + The VNF or PNF **SHOULD** use available backup capabilities 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 @@ -1568,11 +1568,11 @@ will be considered to have failed. .. req:: :id: R-43353 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF **MUST** return control from Ansible Playbooks only after all + The VNF or PNF **MUST** return control from Ansible Playbooks only after all tasks performed by playbook 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 @@ -1581,11 +1581,11 @@ will be considered to have failed. Detailed examples: ``StopApplication Playbook`` – StopApplication Playbook shall return control -and a completion status response only after xNF application is fully stopped, +and a completion status response only after VNF or PNF application is fully stopped, all processes/services stopped. ``StartApplication Playbook`` – StartApplication Playbook shall return control -and a completion status only after all xNF application services are fully up, +and a completion status only after all VNF or PNF application services are fully up, all processes/services started and ready to provide services. **NOTE**: Start Playbook should not be declared complete/done after starting @@ -1594,18 +1594,18 @@ one or several processes that start the other processes. HealthCheck Playbook: SUCCESS – HealthCheck success shall be returned (return code 0) by a -Playbook or Cookbook only when xNF is 100% healthy, ready to take requests -and provide services, with all xNF required capabilities ready to provide +Playbook or Cookbook only when VNF or PNF is 100% healthy, ready to take requests +and provide services, with all VNF or PNF required capabilities ready to provide services and with all active and standby resources fully ready with no open MINOR, MAJOR or CRITICAL alarms. -NOTE: In some cases, a switch may need to be turned on, but a xNF +NOTE: In some cases, a switch may need to be turned on, but a VNF or PNF reported as healthy, should be ready to take service requests or be already processing service requests successfully. A successful execution of a health-check playbook shall create one response -file (per xNF) in JSON format, named after the xNF instance, followed by -"_results.txt" (<xNF instance name>_results.txt) to be provided as a response +file (per VNF or PNF) in JSON format, named after the VNF or PNF instance, followed by +"_results.txt" (<VNF or PNF instance name>_results.txt) to be provided as a response to the requestor, indicating health-check was executed and completed successfully, example: vfdb9904v_results.txt, with the following contents: @@ -1632,17 +1632,17 @@ Example: **NOTE**: See section 7.3.1.4 for comments on support of partial health checks. FAILURE – A health check playbook shall return a non-zero return code in -case xNF is not 100% healthy because one or more xNF application processes +case VNF or PNF is not 100% healthy because one or more VNF or PNF application processes are stopped or not ready to take service requests or because critical or non-critical resources are not ready or because there are open MINOR, MAJOR -or CRITICAL traps/alarms or because there are issues with the xNF that -need attention even if they do not impact services provided by the xNF. +or CRITICAL traps/alarms or because there are issues with the VNF or PNF that +need attention even if they do not impact services provided by the VNF or PNF. -A failed health-check playbook shall also create one file (per xNF), in -JSON format, named after the xNF instance name, followed by "_results.txt" +A failed health-check playbook shall also create one file (per VNF or PNF), in +JSON format, named after the VNF or PNF instance name, followed by "_results.txt" to indicate health-check was executed and found issues in the health of -the xNF. This is to differentiate from failure to run health-check playbook -or playbook tasks to verify the health of the xNF, +the VNF or PNF. This is to differentiate from failure to run health-check playbook +or playbook tasks to verify the health of the VNF or PNF, example: vfdb9904v_results.txt, with the following contents: .. code-block:: java @@ -1678,9 +1678,9 @@ Example: } -See `xNF REST APIs`_ for additional details on HealthCheck. +See `VNF or PNF REST APIs`_ for additional details on HealthCheck. -Some xNFs may support and desire to run partial health checks and receive +Some VNFs or PNFs may support and desire to run partial health checks and receive a successful response when partial health check completes without errors. The parameter name used by HealthCheck playbook to request non-default partial health check is healthcheck_type. Example of health check types @@ -1690,26 +1690,26 @@ attribute-value pair may be passed by Orchestrator or Workflow or other (northbound) APPC/SDN-C clients to APPC/SDN-C as part of the request. By default, when no argument/parameter is passed, healthcheck playbook -performs a full xNF health check. +performs a full VNF or PNF health check. .. req:: :id: R-24189 - :target: XNF + :target: VNF or PNF :keyword: SHOULD :introduced: casablanca - The xNF provider **MUST** deliver a new set of playbooks that includes + The VNF or PNF provider **MUST** deliver a new set of playbooks that includes all updated and unchanged playbooks for any new revision to an existing set of playbooks. .. req:: :id: R-49911 - :target: XNF + :target: VNF or PNF :keyword: SHOULD :updated: casablanca :introduced: casablanca - The xNF provider **MUST** assign a new point release to the updated + The VNF or PNF provider **MUST** assign a new point release to the updated playbook set. The functionality of a new playbook set must be tested before it is deployed to the production. @@ -1718,11 +1718,11 @@ Ansible API Usage ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This section outlines the workflow that APPC/SDN-C invokes when -it receives an action request against an Ansible managed xNF. +it receives an action request against an Ansible managed VNF or PNF. #. When APPC/SDN-C receives a request for an action for an - Ansible managed xNF, it retrieves the corresponding template (based - on **action** and **xNF Type**) from its database and sets necessary + Ansible managed VNF or PNF, it retrieves the corresponding template (based + on **action** and **VNF or PNF Type**) from its database and sets necessary values (such as an Id, NodeList, and EnvParameters) from either information either in the request or data obtained from other sources, inventory database, is an example of such sources. @@ -1750,14 +1750,14 @@ Table 8. APPC/SDN-C APIs and NETCONF Commands +-------------+--------------------+--------------------+--------------------+ |**Command** |**NETCONF Support** |**Chef Support** |**Ansible** | +=============+====================+====================+====================+ -|General |For each RPC, the |xNF Vendor must |VNF Vendor must | +|General |For each RPC, the |VNF or PNF Vendor must |VNF Vendor must | |Comments |appropriate RPC |provide any |provide an Ansible | | |operation is listed.|necessary roles, |playbook to retrieve| | | |cookbooks, recipes |the running | | | |to retrieve the |configuration from a| | | |running |VNF and place the | | | |configuration from |output on the | -| | |a xNF and place it |Ansible server in | +| | |a VNF or PNF and place it |Ansible server in | | | |in the respective |a manner aligned | | | |Node Objects |with playbook | | | |'PushJobOutput' |requirements listed | @@ -1768,7 +1768,7 @@ Table 8. APPC/SDN-C APIs and NETCONF Commands | | |run. |in the JSON file. | | | | | | | | |The JSON file for |NodeList must list | -| | |this xNF action is |IP addresses or DNS | +| | |this VNF or PNF action is |IP addresses or DNS | | | |required to set |supported FQDNs of | | | |"PushJobFlag" to |an example VNF | | | |"True" and |on which to | @@ -1802,7 +1802,7 @@ Table 8. APPC/SDN-C APIs and NETCONF Commands +-------------+--------------------+--------------------+--------------------+ |Configure, |The <edit-config> |Supported via a |Supported via a | |ModifyConfig |operation loads all |cookbook that |playbook that | -| |or part of a |updates the xNF |updates the VNF | +| |or part of a |updates the VNF or PNF |updates the VNF | | |specified data set |configuration. |configuration. | | |to the specified | | | | |target database. If | | | @@ -1840,7 +1840,7 @@ Table 8. APPC/SDN-C APIs and NETCONF Commands .. [#7.3.2] Recall that the Node Object **is required** to be identical across - all VMs of a xNF invoked as part of the action except for the "name". + all VMs of a VNF or PNF invoked as part of the action except for the "name". .. [#7.3.3] Upstream elements must provide the appropriate FQDN in the request to diff --git a/docs/Chapter7/Monitoring-And-Management.rst b/docs/Chapter7/Monitoring-And-Management.rst index a576a91..a0aa58e 100755 --- a/docs/Chapter7/Monitoring-And-Management.rst +++ b/docs/Chapter7/Monitoring-And-Management.rst @@ -62,7 +62,7 @@ While this document is focused on specifying some of the records from the ONAP perspective, there may be other external bodies using the same framework to specify additional records. For example, OPNFV has a VES project that is looking to specify records for OpenStack's internal telemetry to manage -application (xNFs), physical and virtual infrastructure (compute, storage, +application (VNFs or PNFs), physical and virtual infrastructure (compute, storage, network devices, etc.) and virtual infrastructure managers (cloud controllers, SDN controllers). It uses ONAP's VES Agent to generate VES events from the NF and Intel's collectD agent to generate infrastructure VES events. Note that @@ -143,7 +143,7 @@ sender and other identifying characteristics related to the domain and event. with the event * ``priority`` - the processing priority enumeration * ``reportingEntityName`` - name of the entity reporting the event or - detecting a problem in another xNF + detecting a problem in another VNF or PNF * ``sequence`` - the ordering of events communicated by an event source * ``sourceName`` - name of the entity experiencing the event issue, which may be detected and reported by a separate reporting entity @@ -310,13 +310,13 @@ Data Structure Specification of the Event Record .. req:: :id: R-520802 - :target: XNF PROVIDER + :target: VNF or PNF PROVIDER :keyword: MUST :introduced: casablanca :validation_mode: static :impacts: dcae - The xNF provider **MUST** provide a YAML file formatted in adherence with + The VNF or PNF provider **MUST** provide a YAML file formatted in adherence with the :doc:`VES Event Registration specification <../../../../vnfsdk/model.git/docs/files/VESEventRegistration_3_0>` that defines the following information for each event produced by the VNF: @@ -327,20 +327,20 @@ Data Structure Specification of the Event Record .. req:: :id: R-120182 - :target: XNF PROVIDER + :target: VNF or PNF PROVIDER :keyword: MUST :introduced: casablanca :validation_mode: static :impacts: dcae - The xNF provider **MUST** indicate specific conditions that may arise, and + The VNF or PNF provider **MUST** indicate specific conditions that may arise, and recommend actions that may be taken at specific thresholds, or if specific conditions repeat within a specified time interval, using the semantics and syntax described by the :doc:`VES Event Registration specification <../../../../vnfsdk/model.git/docs/files/VESEventRegistration_3_0>`. -**NOTE:** The Service Provider may override xNF provider Event +**NOTE:** The Service Provider may override VNF or PNF provider Event Registrations using the ONAP SDC Design Studio to finalizes Service -Provider engineering rules for the processing of the xNF events. +Provider engineering rules for the processing of the VNF or PNF events. These changes may modify any of the following: * Threshold levels @@ -349,26 +349,26 @@ These changes may modify any of the following: .. req:: :id: R-570134 - :target: XNF + :target: VNF or PNF :keyword: MUST :introduced: casablanca :validation_mode: in_service :impacts: dcae - The events produced by the xNF **MUST** must be compliant with the common + The events produced by the VNF or PNF **MUST** must be compliant with the common event format defined in the :doc:`VES Event Listener<../../../../vnfsdk/model.git/docs/files/VESEventListener_7_0_1>` specification. .. req:: :id: R-123044 - :target: XNF PROVIDER + :target: VNF or PNF PROVIDER :keyword: MUST :introduced: casablanca :validation_mode: in_service :impacts: dcae - The xNF Provider **MAY** require that specific events, identified by their + The VNF or PNF Provider **MAY** require that specific events, identified by their ``eventName``, require that certain fields, which are optional in the common event format, must be present when they are published. @@ -384,30 +384,30 @@ minimizing changes to data delivery. .. req:: :id: R-798933 - :target: XNF + :target: VNF or PNF :keyword: SHOULD :impacts: dcae :validation_mode: in_service :introduced: casablanca - The xNF **SHOULD** deliver event records that fall into the event domains + The VNF or PNF **SHOULD** deliver event records that fall into the event domains supported by VES. .. req:: :id: R-821839 - :target: XNF + :target: VNF or PNF :keyword: MUST :impacts: dcae :validation_mode: in_service :introduced: casablanca :updated: dublin - The xNF **MUST** deliver event records to ONAP using the common transport + The VNF or PNF **MUST** deliver event records to ONAP using the common transport mechanisms and protocols defined in this specification. The term 'Event Record' is used throughout this document to represent various -forms of telemetry or instrumentation made available by the xNFs -including, faults, status events, various other types of xNF measurements +forms of telemetry or instrumentation made available by the VNFs or PNFs +including, faults, status events, various other types of VNF or PNF measurements and logs. Common structures and delivery protocols for other types of data will be given @@ -415,21 +415,21 @@ in future versions of this document as we gain more insight into data volumes and required processing. In the following sections, we provide options for encoding, serialization and -data delivery. Agreements between Service Providers and xNF providers determine +data delivery. Agreements between Service Providers and VNF or PNF providers determine which encoding, serialization and delivery method to use for particular data sets. .. req:: :id: R-932071 - :target: XNF + :target: VNF or PNF :keyword: MUST :impacts: dcae :validation_mode: none :introduced: casablanca - The xNF provider **MUST** reach agreement with the Service Provider on + The VNF or PNF provider **MUST** reach agreement with the Service Provider on the selected methods for encoding, serialization and data delivery - prior to the on-boarding of the xNF into ONAP SDC Design Studio. + prior to the on-boarding of the VNF or PNF into ONAP SDC Design Studio. VNF or PNF Telemetry using VES/JSON Model @@ -437,13 +437,13 @@ VNF or PNF Telemetry using VES/JSON Model .. req:: :id: R-659655 - :target: XNF + :target: VNF or PNF :keyword: SHOULD :impacts: dcae :validation_mode: in_service :introduced: casablanca - The xNF **SHOULD** leverage the JSON-driven model, as depicted in Figure 2, + The VNF or PNF **SHOULD** leverage the JSON-driven model, as depicted in Figure 2, for data delivery unless there are specific performance or operational concerns agreed upon by the Service Provider that would warrant using an alternate model. @@ -457,13 +457,13 @@ VNF or PNF Telemetry using Google Protocol Buffers .. req:: :id: R-697654 - :target: XNF + :target: VNF or PNF :keyword: MAY :impacts: dcae :validation_mode: in_service :introduced: casablanca - The xNF **MAY** leverage the Google Protocol Buffers (GPB) delivery model + The VNF or PNF **MAY** leverage the Google Protocol Buffers (GPB) delivery model depicted in Figure 3 to support real-time performance management (PM) data. In this model the VES events are streamed as binary-encoded GBPs over via TCP sockets. @@ -473,7 +473,7 @@ VNF or PNF Telemetry using Google Protocol Buffers Figure 3. VNF or PNF Telemetry using Google Protocol Buffers -**NOTE:** For high-volume xNF telemetry, native (binary) Google Protocol +**NOTE:** For high-volume VNF or PNF telemetry, native (binary) Google Protocol Buffers (GPB) is the preferred serialization method. While supporting the GPB telemetry delivery approach described above, the default delivery method is the VES/REST JSON based model in DCAE. The purpose of the diagram above @@ -490,13 +490,13 @@ Bulk Telemetry Transmission .. req:: :id: R-908291 - :target: XNF + :target: VNF or PNF :keyword: MAY :introduced: casablanca :impacts: dcae, dmaap :validation_mode: in_service - The XNF **MAY** leverage bulk xNF telemetry transmission mechanism, as + The VNF or PNF **MAY** leverage bulk VNF or PNF telemetry transmission mechanism, as depicted in Figure 4, in instances where other transmission methods are not practical or advisable. @@ -519,13 +519,13 @@ VNF telemetry via standardized interface .. req:: :id: R-821473 - :target: XNF + :target: VNF or PNF :keyword: MUST :introduced: casablanca :impacts: dcae :validation_mode: in_service - The xNF MUST produce heartbeat indicators consisting of events containing + The VNF or PNF MUST produce heartbeat indicators consisting of events containing the common event header only per the VES Listener Specification. @@ -534,11 +534,11 @@ JSON .. req:: :id: R-19624 - :target: XNF + :target: VNF or PNF :keyword: MUST :updated: casablanca - The xNF, when leveraging JSON for events, **MUST** encode and serialize + The VNF or PNF, when leveraging JSON for events, **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 data @@ -584,32 +584,32 @@ Google Protocol Buffers (GPB) .. req:: :id: R-257367 - :target: XNF + :target: VNF or PNF :keyword: MUST :introduced: casablanca :validation_mode: in_service - The xNF, when leveraging Google Protocol Buffers for events, **MUST** + The VNF or PNF, when leveraging Google Protocol Buffers for events, **MUST** serialize the events using native Google Protocol Buffers (GPB) according to the following guidelines: * The keys are represented as integers pointing to the system resources - for the xNF being monitored + for the VNF or PNF being monitored * The values correspond to integers or strings that identify the operational state of the VNF resource, such a statistics counters and - the state of an xNF resource. + the state of an VNF or PNF resource. * The required Google Protocol Buffers (GPB) metadata is provided in the form of .proto files. .. req:: :id: R-978752 - :target: XNF PROVIDER + :target: VNF or PNF PROVIDER :keyword: MUST :introduced: casablanca :validation_mode: static - The xNF providers **MUST** provide the Service Provider the following - artifacts to support the delivery of high-volume xNF telemetry to + The VNF or PNF providers **MUST** provide the Service Provider the following + artifacts to support the delivery of high-volume VNF or PNF telemetry to DCAE via GPB over TLS/TCP: * A valid VES Event .proto definition file, to be used validate and @@ -624,20 +624,20 @@ Reporting Frequency .. req:: :id: R-146931 - :target: XNF + :target: VNF or PNF :keyword: MUST :introduced: casablanca :validation_mode: in_service - The xNF **MUST** report exactly one Measurement event per period + The VNF or PNF **MUST** report exactly one Measurement event per period per source name. .. req:: :id: R-98191 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** vary the frequency that asynchronous data + The VNF or PNF **MUST** vary the frequency that asynchronous data is delivered based on the content and how data may be aggregated or grouped together. @@ -674,83 +674,83 @@ of bulk files. .. req:: :id: R-88482 - :target: XNF + :target: VNF or PNF :keyword: SHOULD - The xNF **SHOULD** use REST using HTTPS delivery of plain + The VNF or PNF **SHOULD** use REST using HTTPS delivery of plain text JSON for moderate sized asynchronous data sets, and for high volume data sets when feasible. .. req:: :id: R-84879 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** have the capability of maintaining a primary + The VNF or PNF **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 + only one collector address for a VNF or PNF. In this case, the network will promptly resolve connectivity problems caused by a collector or network - failure transparently to the xNF. + failure transparently to the VNF or PNF. .. req:: :id: R-81777 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** be configured with initial address(es) to use + The VNF or PNF **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 + ONAP-defined policies delivered from ONAP to the VNF or PNF using PUTs to a RESTful API, in the same manner that other controls over data reporting will be controlled by policy. .. req:: :id: R-08312 - :target: XNF + :target: VNF or PNF :keyword: MAY - The xNF **MAY** use another option which is expected to include REST + The VNF or PNF **MAY** use another option which is expected to include REST delivery of binary encoded data sets. .. req:: :id: R-79412 - :target: XNF + :target: VNF or PNF :keyword: MAY - The xNF **MAY** use another option which is expected to include TCP + The VNF or PNF **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. .. req:: :id: R-01033 - :target: XNF + :target: VNF or PNF :keyword: MAY - The xNF **MAY** use another option which is expected to include SFTP + The VNF or PNF **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 + VNFs or PNFs. (Preferred is to reorganize the data into more frequent or more focused data sets, and deliver these by REST or TCP as appropriate.) .. req:: :id: R-63229 - :target: XNF + :target: VNF or PNF :keyword: MAY - The xNF **MAY** use another option which is expected to include REST - for synchronous data, using RESTCONF (e.g., for xNF state polling). + The VNF or PNF **MAY** use another option which is expected to include REST + for synchronous data, using RESTCONF (e.g., for VNF or PNF state polling). .. req:: :id: R-03070 - :target: XNF + :target: VNF or PNF :keyword: MUST - 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 + The VNF or PNF **MUST**, by ONAP Policy, provide the ONAP addresses + as data destinations for each VNF or PNF, and may be changed by Policy while + the VNF or PNF is in operation. We expect the VNF or PNF 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. @@ -759,92 +759,92 @@ Asynchronous and Synchronous Data Delivery .. req:: :id: R-06924 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** deliver asynchronous data as data becomes + The VNF or PNF **MUST** deliver asynchronous data as data becomes available, or according to the configured frequency. .. req:: :id: R-73285 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** must encode, address and deliver the data + The VNF or PNF **MUST** must encode, address and deliver the data as described in the previous paragraphs. .. req:: :id: R-42140 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** respond to data requests from ONAP as soon + The VNF or PNF **MUST** respond to data requests from ONAP as soon as those requests are received, as a synchronous response. .. req:: :id: R-34660 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** use the RESTCONF/NETCONF framework used by + The VNF or PNF **MUST** use the RESTCONF/NETCONF framework used by the ONAP configuration subsystem for synchronous communication. .. req:: :id: R-86586 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** use the YANG configuration models and RESTCONF + The VNF or PNF **MUST** use the YANG configuration models and RESTCONF [RFC8040] (https://tools.ietf.org/html/rfc8040). .. req:: :id: R-11240 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** respond with content encoded in JSON, as + The VNF or PNF **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. .. req:: :id: R-70266 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** respond to an ONAP request to deliver the + The VNF or PNF **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 + VNF or PNF scaling fields, and syslog fields. Other record types will be added in the future as they become standardized and are made available.) .. req:: :id: R-332680 - :target: XNF + :target: VNF or PNF :keyword: SHOULD :impacts: dcae :validation_mode: in_service :introduced: casablanca - The xNF **SHOULD** deliver all syslog messages to the VES Collector per the + The VNF or PNF **SHOULD** deliver all syslog messages to the VES Collector per the specifications in Monitoring and Management chapter. .. req:: :id: R-46290 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** respond to an ONAP request to deliver granular + The VNF or PNF **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. + configuration model for the VNF or PNF by returning the requested data elements. .. req:: :id: R-43327 - :target: XNF + :target: VNF or PNF :keyword: SHOULD - The xNF **SHOULD** use `Modeling JSON text with YANG + The VNF or PNF **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 @@ -855,10 +855,10 @@ Security .. req:: :id: R-42366 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** support secure connections and transports such as + The VNF or PNF **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 @@ -866,36 +866,36 @@ Security .. req:: :id: R-44290 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** control access to ONAP and to xNFs, and creation + The VNF or PNF **MUST** control access to ONAP and to VNFs or PNFs, and creation of connections, through secure credentials, log-on and exchange mechanisms. .. req:: :id: R-47597 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** carry data in motion only over secure connections. + The VNF or PNF **MUST** carry data in motion only over secure connections. .. req:: :id: R-68165 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** encrypt any content containing Sensitive Personal + The VNF or PNF **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. .. req:: :id: R-01427 - :target: XNF + :target: VNF or PNF :keyword: MUST :introduced: casablanca :updated: dublin - The xNF **MUST** support the provisioning of security and authentication + The VNF or PNF **MUST** support the provisioning of security and authentication parameters (HTTP username and password) in order to be able to authenticate with DCAE (in ONAP). @@ -907,12 +907,12 @@ Security .. req:: :id: R-894004 - :target: XNF + :target: VNF or PNF :keyword: MUST :introduced: casablanca :updated: dublin - When the xNF sets up a HTTP or HTTPS connection to the collector, it **MUST** + When the VNF or PNF sets up a HTTP or HTTPS connection to the collector, it **MUST** provide a username and password to the DCAE VES Collector for HTTP Basic Authentication. @@ -925,33 +925,33 @@ Bulk Performance Measurement .. req:: :id: R-841740 - :target: XNF + :target: VNF or PNF :keyword: SHOULD :introduced: casablanca :impacts: dcae, dmaap - The xNF **SHOULD** support FileReady VES event for event-driven bulk transfer + The VNF or PNF **SHOULD** support FileReady VES event for event-driven bulk transfer of monitoring data. .. req:: :id: R-440220 - :target: XNF + :target: VNF or PNF :keyword: SHOULD :introduced: casablanca :impacts: dcae, dmaap - The xNF **SHOULD** support File transferring protocol, such as FTPES or SFTP, + The VNF or PNF **SHOULD** support File transferring protocol, such as FTPES or SFTP, when supporting the event-driven bulk transfer of monitoring data. .. req:: :id: R-75943 - :target: XNF + :target: VNF or PNF :keyword: SHOULD :introduced: casablanca :impacts: dcae, dmaap - The xNF **SHOULD** support the data schema defined in 3GPP TS 32.435, when + The VNF or PNF **SHOULD** support the data schema defined in 3GPP TS 32.435, when supporting the event-driven bulk transfer of monitoring data. .. req:: diff --git a/docs/Chapter7/VNF-On-boarding-and-package-management.rst b/docs/Chapter7/VNF-On-boarding-and-package-management.rst index 7a79f50..662ff53 100755 --- a/docs/Chapter7/VNF-On-boarding-and-package-management.rst +++ b/docs/Chapter7/VNF-On-boarding-and-package-management.rst @@ -50,70 +50,70 @@ Resource Description .. req:: :id: R-69565 - :target: XNF DOCUMENTATION PACKAGE + :target: VNF or PNF DOCUMENTATION PACKAGE :keyword: MUST :updated: dublin - The xNF Documentation Package **MUST** describe the xNF + The VNF or PNF Documentation Package **MUST** describe the VNF or PNF Management APIs, which must include information and tools for ONAP to - deploy and configure (initially and ongoing) the xNF application(s) + deploy and configure (initially and ongoing) the VNF or PNF 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. + parameters for the VNF or PNF and whether the parameters can be configured + after VNF or PNF instantiation. .. req:: :id: R-00156 - :target: XNF DOCUMENTATION PACKAGE + :target: VNF or PNF DOCUMENTATION PACKAGE :keyword: MUST :updated: dublin - The xNF Documentation Package **MUST** describe the xNF + The VNF or PNF Documentation Package **MUST** describe the VNF or PNF Management APIs, which must include information and tools for - ONAP to monitor the health of the xNF (conditions that require + ONAP to monitor the health of the VNF or PNF (conditions that require healing and/or scaling responses). .. req:: :id: R-00068 - :target: XNF DOCUMENTATION PACKAGE + :target: VNF or PNF DOCUMENTATION PACKAGE :keyword: MUST :updated: dublin - The xNF Documentation Package **MUST** include - a description of parameters that can be monitored for the xNF + The VNF or PNF Documentation Package **MUST** include + a description of parameters that can be monitored for the VNF or PNF and event records (status, fault, flow, session, call, control - plane, etc.) generated by the xNF after instantiation. + plane, etc.) generated by the VNF or PNF after instantiation. .. req:: :id: R-12678 - :target: XNF DOCUMENTATION PACKAGE + :target: VNF or PNF DOCUMENTATION PACKAGE :keyword: MUST :updated: dublin - The xNF Documentation Package **MUST** include a + The VNF or PNF Documentation Package **MUST** include a description of runtime lifecycle events and related actions (e.g., - control responses, tests) which can be performed for the xNF. + control responses, tests) which can be performed for the VNF or PNF. .. req:: :id: R-84366 - :target: XNF DOCUMENTATION PACKAGE + :target: VNF or PNF DOCUMENTATION PACKAGE :keyword: MUST :updated: dublin - The xNF Documentation Package **MUST** describe the - xNF Functional APIs that are utilized to build network and + The VNF or PNF Documentation Package **MUST** describe the + VNF or PNF 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 + functional inputs and outputs for the VNF or PNF, including interface format and protocols supported. .. req:: :id: R-36280 - :target: XNF DOCUMENTATION PACKAGE + :target: VNF or PNF DOCUMENTATION PACKAGE :keyword: MUST :updated: dublin - The xNF Documentation Package **MUST** describe the - xNF Functional Capabilities that are utilized to operationalize the - xNF and compose complex services. + The VNF or PNF Documentation Package **MUST** describe the + VNF or PNF Functional Capabilities that are utilized to operationalize the + VNF or PNF and compose complex services. .. req:: :id: R-98617 @@ -179,16 +179,16 @@ Resource Configuration .. req:: :id: R-89571 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** support and provide artifacts for configuration + The VNF or PNF **MUST** support and provide artifacts for configuration management using at least one of the following technologies; a) Netconf/YANG, b) Chef, or c) Ansible. Note: The requirements for Netconf/YANG, Chef, and Ansible protocols are provided separately and must be supported only if the corresponding - protocol option is provided by the xNF providor. + protocol option is provided by the VNF or PNF providor. Configuration Management via NETCONF/YANG @@ -209,19 +209,19 @@ Configuration Management via Chef .. req:: :id: R-13390 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF provider **MUST** provide cookbooks to be loaded + The VNF or PNF provider **MUST** provide cookbooks to be loaded on the appropriate Chef Server. .. req:: :id: R-18525 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF provider **MUST** provide a JSON file for each - supported action for the xNF. The JSON file must contain key value + The VNF or PNF provider **MUST** provide a JSON file for each + supported action for the VNF or PNF. 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. @@ -235,38 +235,38 @@ Configuration Management via Ansible .. req:: :id: R-75608 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF provider **MUST** provide playbooks to be loaded + The VNF or PNF provider **MUST** provide playbooks to be loaded on the appropriate Ansible Server. .. req:: :id: R-16777 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF provider **MUST** provide a JSON file for each - supported action for the xNF. The JSON file must contain key value + The VNF or PNF provider **MUST** provide a JSON file for each + supported action for the VNF or PNF. 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. .. req:: :id: R-46567 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF Package **MUST** include configuration scripts + The VNF or PNF Package **MUST** include configuration scripts for boot sequence and configuration. .. req:: :id: R-16065 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF provider **MUST** provide configurable parameters - (if unable to conform to YANG model) including xNF attributes/parameters + The VNF or PNF provider **MUST** provide configurable parameters + (if unable to conform to YANG model) including VNF or PNF attributes/parameters and valid values, dynamic attributes and cross parameter dependencies (e.g., customer provisioning data). @@ -276,73 +276,73 @@ Resource Control Loop .. req:: :id: R-22888 - :target: XNF DOCUMENTATION PACKAGE + :target: VNF or PNF DOCUMENTATION PACKAGE :keyword: MUST :updated: dublin - The xNF Documentation Package **MUST** provide the xNF - Policy Description to manage the xNF runtime lifecycle. The document + The VNF or PNF Documentation Package **MUST** provide the VNF or PNF + Policy Description to manage the VNF or PNF runtime lifecycle. The document must include a description of how the policies (conditions and actions) - are implemented in the xNF. + are implemented in the VNF or PNF. .. req:: :id: R-01556 - :target: XNF DOCUMENTATION PACKAGE + :target: VNF or PNF DOCUMENTATION PACKAGE :keyword: MUST :updated: dublin - The xNF Documentation Package **MUST** describe the + The VNF or PNF Documentation Package **MUST** describe the fault, performance, capacity events/alarms and other event records - that are made available by the xNF. + that are made available by the VNF or PNF. .. req:: :id: R-16875 - :target: XNF DOCUMENTATION PACKAGE + :target: VNF or PNF DOCUMENTATION PACKAGE :keyword: MUST :updated: dublin - The xNF Documentation Package **MUST** include documentation which must - include a unique identification string for the specific xNF, a description + The VNF or PNF Documentation Package **MUST** include documentation which must + include a unique identification string for the specific VNF or PNF, a description of the problem that caused the error, and steps or procedures to perform Root Cause Analysis and resolve the issue. .. req:: :id: R-35960 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF Package **MUST** include documentation which must include + The VNF or PNF 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. .. req:: :id: R-42018 - :target: XNF + :target: VNF or PNF :keyword: MUST - 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 <https://onap.readthedocs.io/en/latest/submodules/vnfrqts/guidelines.git/docs/vnf_guidelines/vnf_guidelines.html>`__ ) and for the overall xNF. + The VNF or PNF Package **MUST** include documentation which must include + all events (fault, measurement for VNF or PNF Scaling, Syslogs, State Change + and Mobile Flow), that need to be collected at each VM, VNFC (defined in `VNF Guidelines <https://onap.readthedocs.io/en/latest/submodules/vnfrqts/guidelines.git/docs/vnf_guidelines/vnf_guidelines.html>`__ ) and for the overall VNF or PNF. .. req:: :id: R-01478 - :target: XNF DOCUMENTATION PACKAGE + :target: VNF or PNF DOCUMENTATION PACKAGE :keyword: MUST :updated: dublin - The xNF Documentation Package **MUST** describe all - parameters that are available to monitor the xNF after instantiation + The VNF or PNF Documentation Package **MUST** describe all + parameters that are available to monitor the VNF or PNF after instantiation (includes all counters, OIDs, PM data, KPIs, etc.) that must be collected for reporting purposes. .. req:: :id: R-73560 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF Package **MUST** include documentation about monitoring - parameters/counters exposed for virtual resource management and xNF + The VNF or PNF Package **MUST** include documentation about monitoring + parameters/counters exposed for virtual resource management and VNF or PNF application management. .. req:: @@ -356,80 +356,80 @@ Resource Control Loop .. req:: :id: R-86235 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF Package **MUST** include documentation about the monitoring + The VNF or PNF 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 + the VNF or PNF and those that must be exercised by the VNF or PNF in order to perform its function. .. req:: :id: R-33904 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF Package **MUST** include documentation for each KPI, provide + The VNF or PNF Package **MUST** include documentation for each KPI, provide lower and upper limits. .. req:: :id: R-53598 - :target: XNF DOCUMENTATION PACKAGE + :target: VNF or PNF DOCUMENTATION PACKAGE :keyword: MUST :updated: dublin - The xNF Documentation Package **MUST**, when relevant, + The VNF or PNF Documentation Package **MUST**, when relevant, provide a threshold crossing alert point for each KPI and describe the significance of the threshold crossing. .. req:: :id: R-69877 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF Package **MUST** include documentation for each KPI, + The VNF or PNF Package **MUST** include documentation for each KPI, identify the suggested actions that need to be performed when a threshold crossing alert event is recorded. .. req:: :id: R-22680 - :target: XNF DOCUMENTATION PACKAGE + :target: VNF or PNF DOCUMENTATION PACKAGE :keyword: MUST :updated: dublin - The xNF Documentation Package **MUST** describe + The VNF or PNF Documentation Package **MUST** describe any requirements for the monitoring component of tools for Network Cloud automation and management to provide these records to components - of the xNF. + of the VNF or PNF. .. req:: :id: R-33694 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF Package **MUST** include documentation to when applicable, + The VNF or PNF Package **MUST** include documentation to when applicable, provide calculators needed to convert raw data into appropriate reporting artifacts. .. req:: :id: R-56815 - :target: XNF DOCUMENTATION PACKAGE + :target: VNF or PNF DOCUMENTATION PACKAGE :keyword: MUST :updated: dublin - The xNF Documentation Package **MUST** describe - supported xNF scaling capabilities and capacity limits (e.g., number + The VNF or PNF Documentation Package **MUST** describe + supported VNF or PNF scaling capabilities and capacity limits (e.g., number of users, bandwidth, throughput, concurrent calls). .. req:: :id: R-48596 - :target: XNF DOCUMENTATION PACKAGE + :target: VNF or PNF DOCUMENTATION PACKAGE :keyword: MUST :updated: dublin - The xNF Documentation Package **MUST** describe - the characteristics for the xNF reliability and high availability. + The VNF or PNF Documentation Package **MUST** describe + the characteristics for the VNF or PNF reliability and high availability. @@ -542,45 +542,45 @@ Licensing Requirements .. req:: :id: R-85653 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF **MUST** provide metrics (e.g., number of sessions, + The VNF or PNF **MUST** provide metrics (e.g., number of sessions, number of subscribers, number of seats, etc.) to ONAP for tracking every license. .. req:: :id: R-44125 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF provider **MUST** agree to the process that can + The VNF or PNF 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. .. req:: :id: R-40827 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF provider **MUST** enumerate all of the open - source licenses their xNF(s) incorporate. + The VNF or PNF provider **MUST** enumerate all of the open + source licenses their VNF or PNF(s) incorporate. .. req:: :id: R-97293 - :target: XNF + :target: VNF or PNF :keyword: MUST NOT - The xNF provider **MUST NOT** require audits + The VNF or PNF provider **MUST NOT** require audits of Service Provider's business. .. req:: :id: R-44569 - :target: XNF + :target: VNF or PNF :keyword: MUST NOT - The xNF provider **MUST NOT** require additional - infrastructure such as a xNF provider license server for xNF provider + The VNF or PNF provider **MUST NOT** require additional + infrastructure such as a VNF or PNF provider license server for VNF or PNF provider functions and metrics. .. req:: @@ -603,26 +603,26 @@ Licensing Requirements .. req:: :id: R-85991 - :target: XNF + :target: VNF or PNF :keyword: MUST - 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. + The VNF or PNF provider **MUST** provide a universal license key + per VNF or PNF to be used as needed by services (i.e., not tied to a VM + instance) as the recommended solution. The VNF or PNF provider may provide + pools of Unique VNF or PNF License Keys, where there is a unique key for + each VNF or PNF instance as an alternate solution. Licensing issues should + be resolved without interrupting in-service VNFs or PNFs. .. req:: :id: R-47849 - :target: XNF + :target: VNF or PNF :keyword: MUST - The xNF provider **MUST** support the metadata about + The VNF or PNF provider **MUST** support the metadata about licenses (and their applicable entitlements) as defined in this - specification 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 + specification for VNF or PNF software, and any license keys required to authorize + use of the VNF or PNF software. This metadata will be used to facilitate + onboarding the VNF or PNF 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. diff --git a/docs/Chapter7/index.rst b/docs/Chapter7/index.rst index 77edf64..972722f 100755 --- a/docs/Chapter7/index.rst +++ b/docs/Chapter7/index.rst @@ -75,6 +75,6 @@ components and logic) or as a Grey Box (provides limited knowledge and access to its internal components). * Requirements that equally apply to both VNFs and PNFs are defined as - "The xNF MUST/SHOULD/..." + "The VNF or PNF MUST/SHOULD/..." * Requirements that only apply to VNFs are defined as "The VNF MUST/SHOULD/..." * Requirements that only apply to PNFs are defined as "The PNF MUST/SHOULD/..." diff --git a/docs/Chapter8/Ansible-JSON-Key-Value-Description.rst b/docs/Chapter8/Ansible-JSON-Key-Value-Description.rst index e6b48d2..5dc5f4c 100644 --- a/docs/Chapter8/Ansible-JSON-Key-Value-Description.rst +++ b/docs/Chapter8/Ansible-JSON-Key-Value-Description.rst @@ -78,7 +78,7 @@ In the above example, the Ansible Server Rest API code will: #. Process the "FileParameters" dictionary and generate a file named 'config.txt' with contents set to the value of the 'config.txt' key. -#. Execute the playbook named '<xNFCode>/<Version>/ansible/configure/site.yml' +#. Execute the playbook named '<VNFCode>/<Version>/ansible/configure/site.yml' on nodes with listed IP addresses (or FQDNs) respectively while providing the following key value pairs to the playbook: Retry=3, Wait=5, ConfigFile=config.txt @@ -87,7 +87,7 @@ In the above example, the Ansible Server Rest API code will: it will be terminated. #. Inventory hosts file to be build with only IP addresses (or FQDNs), IP - addresses and VM names, or IP addresses and xNFC names depending on + addresses and VM names, or IP addresses and VNFC names depending on InventoryNames setting in the template(s) passed to Ansible Server as part of the Rest API request. In a later section with Ansible examples, examples of supported inventory hosts file formats are shared. diff --git a/docs/Chapter8/Ansible-Playbook-Examples.rst b/docs/Chapter8/Ansible-Playbook-Examples.rst index 8367ed0..edeeb28 100644 --- a/docs/Chapter8/Ansible-Playbook-Examples.rst +++ b/docs/Chapter8/Ansible-Playbook-Examples.rst @@ -533,7 +533,7 @@ OR <VNF type>/<Version>/ansible/vars/<VNF instance name>.yml (INI format accepted/supported by Ansible) -**NOTE**: Requirement remains while manual actions to create or edit xNF +**NOTE**: Requirement remains while manual actions to create or edit VNF or PNF instance specific files are supported. All files manually created or edited should be placed in this one directory (``ansible/vars``). diff --git a/docs/index.rst b/docs/index.rst index 427667a..86c82e9 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -14,8 +14,8 @@ .. _vnf_requirements_documentation: -VNF Requirements Documentation ------------------------------- +VNF or PNF Requirements Documentation +------------------------------------- .. toctree:: :maxdepth: 2 |