diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/Chapter2.rst | 6 | ||||
| -rw-r--r-- | docs/Chapter4.rst | 38 | ||||
| -rw-r--r-- | docs/Chapter5.rst | 184 | ||||
| -rw-r--r-- | docs/Chapter7.rst | 64 | ||||
| -rw-r--r-- | docs/Chapter8.rst | 19 | ||||
| -rw-r--r-- | docs/index.rst | 2 | ||||
| -rw-r--r-- | docs/release-notes.rst | 2 |
7 files changed, 157 insertions, 158 deletions
diff --git a/docs/Chapter2.rst b/docs/Chapter2.rst index 3a42ba6..0cbec53 100644 --- a/docs/Chapter2.rst +++ b/docs/Chapter2.rst @@ -16,7 +16,7 @@ References This section contains a list of normative and informative references along with information on acquiring the identified references. Normative references are required to be implemented by this document. Informative references are for informational purposes only. Normative References -^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^ +---------------+---------------------------------------------------------------------------------------------------------------+ | Reference | Description | +===============+===============================================================================================================+ @@ -24,7 +24,7 @@ Normative References +---------------+---------------------------------------------------------------------------------------------------------------+ Informative References -^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^ +---------------+---------------------------------------------------------------------------------------------------------------+ | Reference | Description | +===============+===============================================================================================================+ @@ -32,7 +32,7 @@ Informative References +---------------+---------------------------------------------------------------------------------------------------------------+ Reference Acquisition -^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^ IETF Specifications: - Internet Engineering Task Force (IETF) Secretariat, 48377 Fremont Blvd., Suite 117, Fremont, California 94538, USA; Phone: +1-510-492-4080, Fax: +1-510-492-4001. diff --git a/docs/Chapter4.rst b/docs/Chapter4.rst index 2c8c450..be89b41 100644 --- a/docs/Chapter4.rst +++ b/docs/Chapter4.rst @@ -69,7 +69,7 @@ the overall guidelines for designing VNFs to meet resiliency goals. Below are more detailed resiliency requirements for VNFs. All Layer Redundancy -^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^ Design the VNF to be resilient to the failures of the underlying virtualized infrastructure (Network Cloud). VNF design considerations @@ -89,7 +89,7 @@ All Layer Redundancy Requirements * R-36843 The VNF **MUST** support the ability of the VNFC to be deployable in multi-zoned cloud sites to allow for site support in the event of cloud zone failure or upgrades. Minimize Cross Data-Center Traffic -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Avoid performance-sapping data center-to-data center replication delay by applying techniques such as caching and persistent transaction paths @@ -103,7 +103,7 @@ Minimize Cross Data-Center Traffic Requirements * R-92935 The VNF **SHOULD** minimize the propagation of state information across multiple data centers to avoid cross data center traffic. Application Resilient Error Handling -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Ensure an application communicating with a downstream peer is equipped to intelligently handle all error conditions. Make sure code can handle @@ -124,7 +124,7 @@ Application Resilient Error Handling Requirements System Resource Optimization -^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Ensure an application is using appropriate system resources for the task at hand; for example, do not use network or IO operations inside @@ -149,7 +149,7 @@ System Resource Optimization Requirements Application Configuration Management -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Leverage configuration management audit capability to drive conformity to develop gold configurations for technologies like Java, Python, etc. @@ -162,7 +162,7 @@ Application Configuration Management Requirements Intelligent Transaction Distribution & Management -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Leverage Intelligent Load Balancing and redundant components (hardware and modules) for all transactions, such that at any point in the @@ -181,7 +181,7 @@ Intelligent Transaction Distribution & Management Requirements * R-27995 The VNF **SHOULD** include control loop mechanisms to notify the consumer of the VNF of their exceeding SLA thresholds so the consumer is able to control its load against the VNF. Deployment Optimization -^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^ Reduce opportunity for failure, by human or by machine, through smarter deployment practices and automation. This can include rolling code @@ -200,7 +200,7 @@ Deployment Optimization Requirements * R-16039 The VNF **SHOULD** test for adherence to the defined resiliency rating recommendation at each layer, during each delivery cycle so that the resiliency rating is measured and feedback is provided where software resiliency requirements are not met. Monitoring & Dashboard -^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^ Promote dashboarding as a tool to monitor and support the general operational health of a system. It is critical to the support of the @@ -256,7 +256,7 @@ following sections: requirements associated with data protection. VNF General Security Requirements -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This section provides details on the VNF general security requirements on various security areas such as user access control, network security, @@ -302,7 +302,7 @@ Integration and operation within a robust security environment is necessary and * R-23135 The VNF **MUST**, if not using the NCSP’s IDAM API, authenticate system to system communications where one system accesses the resources of another system, and must never conceal individual accountability. VNF Identity and Access Management Requirements -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The following security requirements for logging, identity, and access management need to be met by the solution in a virtual environment: @@ -349,7 +349,7 @@ Identity and Access Management Requirements VNF API Security Requirements -^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This section covers API security requirements when these are used by the VNFs. Key security areas covered in API security are Access Control, @@ -382,7 +382,7 @@ API Requirements VNF Security Analytics Requirements -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This section covers VNF security analytics requirements that are mostly applicable to security monitoring. The VNF Security Analytics cover the @@ -474,7 +474,7 @@ Security Analytics Requirements * R-84160 The VNF **MUST** have security logging for VNFs and their OSs be active from initialization. Audit logging includes automatic routines to maintain activity records and cleanup programs to ensure the integrity of the audit/logging systems. VNF Data Protection Requirements -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This section covers VNF data protection requirements that are mostly applicable to security monitoring. @@ -509,13 +509,13 @@ VNF Modularity --------------------------- ONAP Heat Orchestration Templates: Overview -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ONAP supports a modular Heat Orchestration Template design pattern, referred to as *VNF Modularity.* ONAP VNF Modularity Overview -^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ With VNF Modularity, a single VNF may be composed from one or more Heat Orchestration Templates, each of which represents a subset of the @@ -555,7 +555,7 @@ that will be introduced. ONAP VNF Modularity -^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^ ONAP supports a modular Heat Orchestration Template design pattern, referred to as *VNF Modularity.* With this approach, a single VNF may be @@ -619,7 +619,7 @@ template must correspond 1:1 with a base template or add-on module template. Suggested Patterns for Modular VNFs -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ There are numerous variations of VNF modularity. Below are two suggested usage patterns. @@ -662,7 +662,7 @@ which might be appropriate for smaller VNFs that do not have any scaling options. Modularity Rules -^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^ There are some rules to follow when building modular VNF templates: @@ -720,7 +720,7 @@ There are some rules to follow when building modular VNF templates: name in the add-on module VNF Modularity Examples -^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^ *Example: Base Module creates SecurityGroup* diff --git a/docs/Chapter5.rst b/docs/Chapter5.rst index 030925f..a71a313 100644 --- a/docs/Chapter5.rst +++ b/docs/Chapter5.rst @@ -11,7 +11,7 @@ TOSCA YAML Introduction -^^^^^^^^^^^ +^^^^^^^^^^^^^^ This reference document is the VNF TOSCA Template Requirements for ONAP, which provides recommendations and standards for building VNF @@ -27,7 +27,7 @@ Network Cloud. It has the following features: Threading, SRIOV， etc. Intended Audience -^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^ This document is intended for persons developing VNF TOSCA templates that will be orchestrated by ONAP. @@ -187,7 +187,7 @@ specification [TOSCA-Simple-Profile-NFV-v1.0] for NFV VNFD. +--------------------------------------------------------------------+ EPA Requirements -^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^ 1. SR-IOV Passthrought @@ -408,10 +408,10 @@ supports dpdk. Here is an example. +------------------------------------------------------+ NFV TOSCA Type Definition -^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^ tosca.capabilites.nfv.VirtualCompute -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +---------------------------+-----------------------------------------+ | **Shorthand Name** | VirtualCompute | @@ -424,7 +424,7 @@ tosca.capabilites.nfv.VirtualCompute +---------------------------+-----------------------------------------+ Properties -+++++++++ +++++++++++++ +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+ | Name | Required | Type | Constraints | Description | @@ -440,7 +440,7 @@ Properties +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+ Definition -+++++++++ +++++++++++++ +-----------------------------------------------------------+ | tosca.capabilities.nfv.VirtualCompute: | @@ -473,7 +473,7 @@ Definition +-----------------------------------------------------------+ tosca.nodes.nfv.VDU.Compute -~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The NFV Virtualization Deployment Unit (VDU) compute node type represents a VDU entity which it describes the deployment and @@ -493,13 +493,13 @@ NFV IFA011].** Attributes -+++++++++ ++++++++++++ None Capabilities -+++++++++++ +++++++++++++++ +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+ | Name | Type | Constraints | Description | @@ -516,7 +516,7 @@ Capabilities +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+ Definition -+++++++++++ ++++++++++++++ +-----------------------------------------------------------------------------------------------------+ | tosca.nodes.nfv.VDU.Compute: | @@ -671,7 +671,7 @@ Artifact tosca.nodes.nfv.Cpd -~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~ The TOSCA Cpd node represents network connectivity to a compute resource or a VL as defined by [ETSI GS NFV-IFA 011]. This is an abstract type @@ -687,7 +687,7 @@ used as parent for the various Cpd types. Attributes -+++++++++++ ++++++++++++++ +--------+------------+--------+---------------+---------------+ | Name | Required | Type | Constraints | Description | @@ -695,17 +695,17 @@ Attributes +--------+------------+--------+---------------+---------------+ Requirements -+++++++++++ ++++++++++++++ None Capabilities -+++++++++++ ++++++++++++++ None Definition -+++++++++++ +++++++++++++ +----------------------------------------------------------------------+ | tosca.nodes.nfv.Cpd: | @@ -757,7 +757,7 @@ Additional Requirement None. tosca.nodes.nfv.VduCpd -~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~ The TOSCA node VduCpd represents a type of TOSCA Cpd node and describes network connectivity between a VNFC instance (based on this VDU) and an @@ -772,7 +772,7 @@ internal VL as defined by [ETSI GS NFV-IFA 011]. +-----------------------+--------------------------+ Properties -++++++++++++ +++++++++++++++ +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+ @@ -790,7 +790,7 @@ Attributes None Requirements -++++++++++++ +++++++++++++++ +--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+ | Name | Required | Type | Constraints | Description | @@ -844,7 +844,7 @@ Definition +----------------------------------------------------------------+ tosca.nodes.nfv.VDU.VirtualStorage -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The NFV VirtualStorage node type represents a virtual storage entity which it describes the deployment and operational behavior of a virtual @@ -868,7 +868,7 @@ presentation. Slide 8. With specific rules of “valid\_target\_type” +---------------------------+--------------------------------------+ tosca.artifacts.nfv.SwImage -~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +---------------------------+------------------------------------+ | **Shorthand Name** | SwImage | @@ -910,7 +910,7 @@ Properties +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+ Definition -++++++++++++ +++++++++++++++ +-----------------------------------------------------+ | tosca.artifacts.nfv.SwImage: | @@ -995,10 +995,10 @@ Definition +-----------------------------------------------------+ vNAT Example -^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^ openovnf\_\_vOpenNAT.yaml -~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-------------------------------------------------------------+ | imports: | @@ -1297,7 +1297,7 @@ openovnf\_\_vOpenNAT.yaml +-------------------------------------------------------------+ openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +------------------------------------------------------------+ | imports: | @@ -1340,7 +1340,7 @@ openonfv\_\_tosca.nodes.nfv.VDU.VirtualStorage.yaml +------------------------------------------------------------+ openonfv\_\_tosca.nodes.nfv.VduCpd.yaml -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-----------------------------------------------------------------+ | data\_types: | @@ -1552,7 +1552,7 @@ Heat --------- General Guidelines -^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^ YAML Format ^^^^^^^^^^^^^^^^^ @@ -1562,7 +1562,7 @@ Markup Language) is a human friendly data serialization standard for all programming languages. See http://www.yaml.org/. Heat Orchestration Template Format -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Heat Orchestration templates must be defined in YAML. @@ -1576,7 +1576,7 @@ YAML rules include: (e.g., "ThIs", is not the same as "thiS") Heat Orchestration Template Structure -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Heat Orchestration template structure follows the following format, as defined by OpenStack at @@ -1624,7 +1624,7 @@ sections: - outputs: heat\_template\_version -++++++++++++++++++++++ ++++++++++++++++++++++++++ This section is ONAP mandatory. The heat\_template\_version must be set to a date that is supported by the OpenStack environment. @@ -1889,7 +1889,7 @@ section is specified, it will need to adhere to specific requirements. See `ONAP Parameter Classifications Overview`_ and `ONAP Output Parameter Names`_ for additional details. Environment File Format -^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^ The environment file is a yaml text file. (https://docs.openstack.org/developer/heat/template_guide/environment.html) @@ -1935,7 +1935,7 @@ the mandatory parameter section. programmatically enforce the use of an environment file.) SDC Treatment of Environment Files -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Parameter values enumerated in the environment file are used by SDC as the default value. However, the SDC user may use the SDC GUI to @@ -1951,7 +1951,7 @@ environment file and what parameter must not be enumerated in the environment file. See `ONAP Parameter Classifications Overview`_ and `ONAP Resource ID and Parameter Naming Convention`_ for more details. Nested Heat Orchestration Templates Overview -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ONAP supports nested Heat Orchestration Templates per OpenStack specifications. @@ -1975,7 +1975,7 @@ dynamically (via OS::Heat::ResourceGroup). See `Nested Heat Templates`_ for additional details. ONAP Heat Orchestration Template Filenames -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In order to enable ONAP to understand the relationship between Heat files, the following Heat file naming convention must be utilized. @@ -1985,7 +1985,7 @@ must not contain any special characters and must not contain the word “base”. Base Modules -~~~~~~~~~~~~ +~~~~~~~~~~~~~~ The file name for the base module must include “base” in the filename and must match one of the following options: @@ -2002,7 +2002,7 @@ The base module’s corresponding environment file must be named identical to the base module with “.y[a]ml” replaced with “.env”. Incremental Modules -~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~ There is no explicit naming convention for the incremental modules. As noted above, <text> represents any alphanumeric string that must not @@ -2023,7 +2023,7 @@ following naming options for modules: - module.y[a]ml Cinder Volume Modules -~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~ The file name for the Cinder volume module must be named the same as the corresponding module it is supporting (base module or incremental @@ -2069,7 +2069,7 @@ Broadly, ONAP categorizes parameters into four categories: 4. Output parameters. ONAP Metadata Parameters -~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~ There are both mandatory and optional ONAP metadata parameters associated with the resource OS::Nova::Server. @@ -2091,7 +2091,7 @@ categories: **ONAP Orchestration Parameters** and **VNF Orchestration Parameters** ONAP Orchestration Parameters -+++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++ ONAP Orchestration Parameters are per instance parameters where the value is assigned via ONAP automation. (Note that in some cases, @@ -2113,7 +2113,7 @@ prior to instantiation.) additional details. VNF Orchestration Parameters -+++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++ VNF Orchestration Parameters are per instance parameters where the values are assigned manually. They are not supported by ONAP automation. @@ -2134,7 +2134,7 @@ The per instance values are loaded into ONAP prior to VNF instantiation. additional details. Constant Parameters -~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~ The constant parameters are parameters that remain constant across many VNF instances (e.g., image, flavor). The constant parameters are @@ -2174,7 +2174,7 @@ VNF Constant Parameters additional details. Output Parameters -~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~ The output parameters are parameters defined in the output section of a Heat Orchestration Template. The ONAP output parameters are subdivided @@ -2187,7 +2187,7 @@ into three categories: 3. ONAP Predefined Output Parameters. ONAP Base Module Output Parameters -+++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ONAP Base Module Output Parameters are declared in the outputs: section of the base module Heat Orchestration Template. A Base Module Output @@ -2215,7 +2215,7 @@ Additional details on ONAP Base Module Output Parameters are provided in `ONAP Output Parameter Names`_ and ONAP VNF Modularity. ONAP Volume Module Output Parameters -++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++ The volume template output parameters are only available for the module (base or add on) that the volume is associated with. @@ -2244,14 +2244,14 @@ Additional details on ONAP Base Module Output Parameters are provided in `ONAP Output Parameter Names`_ and `Cinder Volume Templates`_. ONAP Predefined Output Parameters -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ONAP will look for a small set of pre-defined Heat output parameters to capture resource attributes for inventory in ONAP. These output parameters are optional and are specified in `OAM Management IP Addresses`_. Support of heat stack update -+++++++++++++++++++++++++++++ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ VNF Heat Orchestration Templates must not be designed to utilize the OpenStack heat stack-update command for scaling (growth/de-growth). ONAP @@ -2261,7 +2261,7 @@ It is important to note that ONAP only supports heat stack-update for image upgrades. Networking -+++++++++++++ +~~~~~~~~~~~~ ONAP defines two types of networks: External Networks and Internal Networks. @@ -2281,7 +2281,7 @@ only connects VMs in a single VNF. It must not connect to other VNFs or an external gateway or router. External Networks -+++++++++++++++++++ +~~~~~~~~~~~~~~~~~~ VNF Heat Orchestration Templates must not include any resources for external networks connected to the VNF. External networks must be @@ -2334,7 +2334,7 @@ VNF Heat Orchestration Templates must pass the appropriate external network IDs into nested VM templates when nested Heat is used. Internal Networks -+++++++++++++++++ +~~~~~~~~~~~~~~~~~~ The VNF Heat Orchestration Templates must include the resource(s) to create the internal network. The internal network must be either a @@ -2373,7 +2373,7 @@ parameters for internal network. However, a naming convention is provided that must be followed. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details. ONAP Resource ID and Parameter Naming Convention -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This section provides the ONAP naming requirements for @@ -2425,7 +2425,7 @@ There are two exceptions to the above rules: identifier. availability\_zone is described in `Property: availability_zone`_. {network-role} -^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^ The assignment of a {network-role} is discussed in `Networking`_. @@ -2460,7 +2460,7 @@ It is recommended that the {network-role} case in the parameter names matches the {network-role} case in the Resource IDs. Resource IDs -^^^^^^^^^^^ +^^^^^^^^^^^^^^ Heat Orchestration Template resources are described in `resources`_ @@ -2578,7 +2578,7 @@ only associated with one {vm-type} and/or one network. Table 2: Example Contrail Heat resource ID Resource: OS::Nova::Server - Parameters -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The resource OS::Nova::Server manages the running virtual machine (VM) instance within an OpenStack cloud. (See @@ -2620,7 +2620,7 @@ parameter for a given OS::Nova::Server resource. Table 3 Resource Property Parameter Names Property: image -~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~ The parameter associated with the property image is an ONAP Constant parameter. @@ -2647,7 +2647,7 @@ maximum clarity and flexibility. description: {vm-type} server image Property: flavor -~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~ The parameter associated with the property flavor is an ONAP Constant parameter. @@ -2674,7 +2674,7 @@ provides maximum clarity and flexibility. description: {vm-type} flavor Property: Name -~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~ The parameter associated with the property name is an ONAP Orchestration parameter. @@ -2767,7 +2767,7 @@ balancer. ... Contrail Issue with Values for OS::Nova::Server Property Name -+++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The Contrail GUI has a limitation displaying special characters. The issue is documented in @@ -2778,7 +2778,7 @@ characters must be used, the only special characters supported are: - “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_ Property: availability\_zone -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The parameter associated with the property availability\_zone is an ONAP Orchestration parameter. @@ -2795,7 +2795,7 @@ The parameter must be declared as type: string The parameter must not be declared as type: comma\_delimited\_list Example -~~~~~~~ +~~~~~~~~~ The example below depicts part of a Heat Orchestration Template that uses the four OS::Nova::Server properties discussed in this section. @@ -2875,7 +2875,7 @@ for dns and a string for oam. . . . Resource: OS::Nova::Server – Metadata Parameters -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The resource OS::Nova::Server has an OpenStack optional property metadata. The metadata property is mandatory for ONAP Heat Orchestration @@ -2924,7 +2924,7 @@ additional details. Table 4: ONAP Metadata vnf\_id -~~~~~~~ +~~~~~~~~~ The vnf\_id parameter is mandatory; it must be included in the Heat Orchestration Template. @@ -2949,7 +2949,7 @@ The parameter must not be enumerated in the Heat environment file. description: Unique ID for this VNF instance vf\_module\_id -~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~ The vf\_module\_id parameter is mandatory; it must be included in the Heat Orchestration Template. @@ -2974,7 +2974,7 @@ The parameter must not be enumerated in the Heat environment file. description: Unique ID for this VNF module instance vnf\_name -~~~~~~~~~ +~~~~~~~~~~~ The vnf\_name parameter is mandatory; it must be included in the Heat Orchestration Template. @@ -2999,7 +2999,7 @@ The parameter must not be enumerated in the Heat environment file. description: Unique name for this VNF instance vf\_module\_name -~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~ The vf\_module\_name parameter is optional; it may be included in the Heat Orchestration Template. @@ -3025,7 +3025,7 @@ The parameter must not be enumerated in the Heat environment file. description: Unique name for this VNF Module instance vm\_role -~~~~~~~~ +~~~~~~~~~ The vm\_role parameter is optional; it may be included in the Heat Orchestration Template. @@ -3085,7 +3085,7 @@ In this example, the {vm-role} is enumerated in the environment file. vm_role: { get_param: vm_role } Example -~~~~~~~ +~~~~~~~~ The example below depicts part of a Heat Orchestration Template that uses the five of the OS::Nova::Server metadata parameter discussed in @@ -3128,13 +3128,13 @@ this section. The {vm-type} has been defined as lb for load balancer. vm_role: lb Resource: OS::Neutron::Port - Parameters -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The resource OS::Neutron::Port is for managing Neutron ports (See https://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::Port.) Introduction -~~~~~~~~~~~~ +~~~~~~~~~~~~~~ Four properties of the resource OS::Neutron::Port that must follow the ONAP parameter naming convention. The four properties are: @@ -3152,7 +3152,7 @@ external network or internal network. External networks and internal networks are defined in `Networking`_. External Networks -++++++++++++++++ +++++++++++++++++++ When the parameter references an external network @@ -3198,7 +3198,7 @@ Table 5: OS::Neutron::Port Resource Property Parameters (External Networks) Internal Networks -++++++++++++++++ +++++++++++++++++++ When the parameter references an internal network @@ -3241,14 +3241,14 @@ When the parameter references an internal network Table 6: Port Resource Property Parameters (Internal Networks) Property: network -~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~ The property networks in the resource OS::Neutron::Port must be referenced by Neutron Network ID, a UUID value, or by the network name defined in OpenStack. External Networks -++++++++++++++++ +++++++++++++++++++ When the parameter associated with the property network is referencing an “external” network, the parameter must adhere to the following naming @@ -3295,7 +3295,7 @@ to assign IP addresses. network: { get_param: oam_net_id } Internal Networks -++++++++++++++++ +++++++++++++++++++ When the parameter associated with the property network is referencing an “internal” network, the parameter must adhere to the following naming @@ -3343,7 +3343,7 @@ Note that DHCP assignment of IP addresses is also referred to as cloud assigned IP addresses. Subnet of an External Networks -+++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++ When the parameter is referencing a subnet of an “external” network, the property fixed\_ips and Map Property subnet\_id parameter must adhere to @@ -3429,7 +3429,7 @@ balancer. - subnet_id: { get_param: oam_v6_subnet_id } Internal Networks -++++++++++++++++ ++++++++++++++++++++ When the parameter is referencing the subnet of an “internal” network, the property fixed\_ips and Map Property subnet\_id parameter must @@ -3483,7 +3483,7 @@ network, the parameter name must contain {vm-type} and int\_{network-role}. IP Address Assignments on External Networks -+++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++ When the property fixed\_ips and Map Property ip\_address is used to assign IP addresses to an external network, the parameter name is @@ -3622,7 +3622,7 @@ database. - “ip_address”: {get_param: db_oam_v6_ip_1}}] IP Address Assignment on Internal Networks -++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++ When the property fixed\_ips and Map Property ip\_address is used to assign IP addresses to an internal network, the parameter name is @@ -3803,7 +3803,7 @@ of public IPs to VMs is via OpenStack commands. ONAP does not support Neutron-style Floating IPs. External Networks -++++++++++++++++ ++++++++++++++++++++ When the parameter is referencing an “external” network, the property allowed\_address\_pairs and Map Property ip\_address parameter must @@ -3867,7 +3867,7 @@ an oam network and the {vm-type} has been defined as db for database. allowed_address_pairs: [ { “ip_address”: {get_param: db_oam_floating_ip}}] Internal Networks -++++++++++++++++ +++++++++++++++++++ When the parameter is referencing an “internal” network, the property allowed\_address\_pairs and Map Property ip\_address parameter must @@ -3896,7 +3896,7 @@ The parameter must be enumerated in the Heat environment file. description: VIP for {vm-type} VMs on the int_{network-role} network Multiple allowed\_address\_pairs for a {vm-type} / {network-role} combination -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The parameter {vm-type}\_{network-role}\_floating\_ip provides only one allowed address pair IPv4 address per {vm-type} and {network-role} pair. @@ -4003,7 +4003,7 @@ The VMs must be of the same {vm-type}. The VMs must be created in the same module (base or incremental). Resource Property “name” -^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The parameter naming convention of the property name for the resource OS::Nova::Server has been defined in `Resource: OS::Nova::Server – Metadata Parameters`_. @@ -4225,7 +4225,7 @@ oam\_management\_v4\_address value: {get_attr: [admin_server, networks, {get_param: oam_net_id}, 0] } Contrail Resource Parameters -^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ONAP requires the parameter names of certain Contrail Resources to follow specific naming conventions. This section provides these @@ -4238,7 +4238,7 @@ Contrail based resources may require references to a Contrail network using the network FQDN. External Networks -++++++++++++++++ ++++++++++++++++++++ When the parameter associated with the Contrail Network is referencing an “external” network, the parameter must adhere to the following naming @@ -4347,7 +4347,7 @@ The parameter must not be enumerated in the Heat environment file. - service_instance_refs_data_interface_type: { get_param: int_fw_interface_type } Parameter Names in Contrail Resources -++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++ Contrail Heat resource properties will use, when appropriate, the same naming convention as OpenStack Heat resources. For example, the resource @@ -4401,7 +4401,7 @@ represent an oam protected network and the {vm-type} has been defined as subnet_uuid: { get_param: oam_protected_subnet_id } Cinder Volume Templates -^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^ ONAP supports the independent deployment of a Cinder volume via separate Heat Orchestration Templates, the Cinder Volume module. This allows the @@ -4507,7 +4507,7 @@ incremental.yaml volume_id: { get_param: lb_volume_id_0 } ONAP Support of Environment Files -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The use of an environment file in OpenStack is optional. In ONAP, it is mandatory. A Heat Orchestration Template uploaded to ONAP must have a @@ -4544,7 +4544,7 @@ Orchestration Parameters). These parameters are supplied to the Heat by ONAP at orchestration time. SDC Treatment of Environment Files -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Parameter values enumerated in the environment file are used by SDC as the default value. However, the SDC user may use the SDC GUI to @@ -4558,7 +4558,7 @@ updates, the SDC generated environment file will contain the same values as the uploaded file. Use of Environment Files when using OpenStack “heat stack-create” CLI -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ When ONAP is instantiating the Heat Orchestration Template, certain parameter must not be enumerated in the environment file. This document @@ -4627,7 +4627,7 @@ Note that: get\_attribute targets against the “parent” resource. Nested Heat Template Example: Static -+++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++ incremental.yaml @@ -4767,7 +4767,7 @@ the VNF. index: index Availability Zone and ResourceGroups -+++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++ The resource OS::Heat::ResourceGroup and the property availability\_zone has been an “issue” with a few VNFs since ONAP only supports @@ -4818,7 +4818,7 @@ In the nested heat OS::Heat::ResourceGroup is created for each availability zone. External References -^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^ Heat templates *should not* reference any HTTP-based resource definitions, any HTTP-based nested configurations, or any HTTP-based @@ -5086,7 +5086,7 @@ availability zone IDs: availability zones as desired Post Orchestration & VNF Configuration -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Heat templates should contain a minimum amount of post-orchestration configuration data. For instance, *do not* embed complex user-data diff --git a/docs/Chapter7.rst b/docs/Chapter7.rst index dcb5afe..880be3e 100644 --- a/docs/Chapter7.rst +++ b/docs/Chapter7.rst @@ -171,7 +171,7 @@ and manage their runtime lifecycle. Additional details can be found in the `ONAP Application Controller (APPC) API Guide <http://onap.readthedocs.io/en/latest/submodules/appc.git/docs/APPC%20API%20Guide/APPC%20API%20Guide.html>`_, `ONAP VF-C project <http://onap.readthedocs.io/en/latest/submodules/vfc/nfvo/lcm.git/docs/index.html>`_ and the `ONAP SDNC project <http://onap.readthedocs.io/en/latest/submodules/sdnc/northbound.git/docs/index.html>`_. NETCONF Standards and Capabilities -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ONAP Controllers and their Adapters utilize device YANG model and NETCONF APIs to make the required changes in the VNF state and @@ -278,7 +278,7 @@ NETCONF RFCs. * R-78282 The xNF **MUST** conform to the NETCONF RFC 6242, “Using the Network Configuration Protocol over Secure Shell”. VNF REST APIs -^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^ Healthcheck is a command for which no NETCONF support exists. Therefore, this must be supported using a RESTful interface (defined in this section) or with a Chef cookbook/Ansible playbook (defined in sections `Chef Standards and Capabilities`_ and `Ansible Standards and Capabilities`_). @@ -328,7 +328,7 @@ Examples: Chef Standards and Capabilities -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ONAP will support configuration of VNFs via Chef subject to the requirements and guidelines defined in this section. @@ -347,10 +347,10 @@ Chef-Client and Push Jobs Client on the VNF (https://downloads.chef.io/). VNF Configuration via Chef Requirements -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chef Client Requirements -++++++++++++++++++++++ ++++++++++++++++++++++++++ * R-79224 The xNF **MUST** have the chef-client be preloaded with validator keys and configuration to register with the designated Chef Server as part of the installation process. * R-72184 The xNF **MUST** have routable FQDNs for all the endpoints (VMs) of a xNF that contain chef-clients which are used to register with the Chef Server. As part of invoking xNF actions, ONAP will trigger push jobs against FQDNs of endpoints for a xNF, if required. @@ -361,7 +361,7 @@ Chef Client Requirements - Chef push jobs client >= 2.0 Chef Roles/Requirements -++++++++++++++++++++++ +++++++++++++++++++++++++++ * R-27310 The xNF Package **MUST** include all relevant Chef artifacts (roles/cookbooks/recipes) required to execute xNF actions requested by ONAP for loading on appropriate Chef Server. * R-26567 The xNF Package **MUST** include a run list of roles/cookbooks/recipes, for each supported xNF action, that will perform the desired xNF action in its entirety as specified by ONAP (see Section 7.c, ONAP Controller APIs and Behavior, for list of xNF actions and requirements), when triggered by a chef-client run list in JSON file. @@ -435,7 +435,7 @@ action request against a Chef managed VNF. Object attribute node[‘PushJobOutput’]. Ansible Standards and Capabilities -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ONAP will support configuration of VNFs via Ansible subject to the requirements and guidelines defined in this section. @@ -447,10 +447,10 @@ data and execution capabilities to take the necessary action on one or more targ will host and run playbooks to manage VNFs that support Ansible. VNF Configuration via Ansible Requirements -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ansible Client Requirements -++++++++++++++++++++++++ ++++++++++++++++++++++++++++++ * R-32217 The xNF **MUST** have routable FQDNs that are reachable via the Ansible Server for the endpoints (VMs) of a xNF on which playbooks will be executed. ONAP will initiate requests to the Ansible Server for invocation of playbooks against these end points [3]_. * R-54373 The xNF **MUST** have Python >= 2.7 on the endpoint VM(s) of a xNF on which an Ansible playbook will be executed. @@ -463,7 +463,7 @@ Ansible Client Requirements * R-91745 The VNF **MUST** update the Ansible Server and other entities storing and using the SSH key for authentication when the SSH key used by Ansible is regenerated/updated. Ansible Playbook Requirements -++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++ An Ansible playbook is a collection of tasks that is executed on the Ansible server (local host) and/or the target VM (s) in order to complete the desired action. @@ -523,7 +523,7 @@ The Ansible Server will determine if a playbook invoked to execute a xNF action See `VNF REST APIs`_ for additional details on HealthCheck. ONAP Controller / Ansible API Usage -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This section outlines the workflow that ONAP Controller invokes when it receives an action request against an Ansible managed VNF. @@ -533,7 +533,7 @@ This section outlines the workflow that ONAP Controller invokes when it receives ONAP Controller APIs and Behavior -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ONAP Controllers such as APPC expose a northbound API to clients which offer a set of commands. The following commands are expected to be supported on all VNF’s if applicable, either directly (via the Netconf interface) or indirectly (via a Chef or Ansible server). There are additional commands @@ -667,7 +667,7 @@ in the network. The VNF providers must be able to provide the aforementioned set data directly to the ONAP collection layer using standardized interfaces. Data Model for Event Records -^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This section describes the data model for the collection of telemetry data from VNFs by Service Providers (SPs) to manage VNF health and runtime lifecycle. This data @@ -711,7 +711,7 @@ The Data Model consists of: Figure 1. Data Model for Event Records Event Records - Data Structure Description -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The data structure for event records consists of: @@ -735,14 +735,14 @@ the sender and other identifying characteristics related to timestamp, sequence number, etc. Technology Independent Records – Fault Fields -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Fault Record, describing a condition in the Fault domain, contains information about the fault such as the entity under fault, the severity, resulting status, etc. Technology Independent Records – Heartbeat Fields -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Heartbeat Record provides an optional structure for communicating information about heartbeat or watchdog signaling events. It can @@ -754,7 +754,7 @@ An optional heartbeat domain is available if required by the heartbeat implementation. Technology Independent Records – State Change Fields -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The State Change Record provides a structure for communicating information about data flow through the VNF. It can contain information about state @@ -762,14 +762,14 @@ change related to physical device that is reported by VNF. As an example, when cards or port name of the entity that has changed state. Technology Independent Records – Syslog Fields -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Syslog Record provides a structure for communicating any type of information that may be logged by the VNF. It can contain information about system internal events, status, errors, etc. Technology Independent Records – Threshold Crossing Alert Fields -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Threshold Crossing Alert (TCA) Record provides a structure for communicating information about threshold crossing alerts. It can @@ -777,7 +777,7 @@ contain alert definitions and types, actions, events, timestamps and physical or logical details. Technology Independent Records - VNF Scaling Fields -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The VNF Scaling\* (short for measurementForVfScalingFields – actual name used in JSON specification) Record contains information @@ -785,7 +785,7 @@ about VNF and VNF resource structure and its condition to help in the management of the resources for purposes of elastic scaling. Technology Independent Records – otherFields -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The otherFields Record defines fields for events belonging to the otherFields domain of the Technology Independent domain enumeration. @@ -796,7 +796,7 @@ or other proof-of-concept evaluations. Hence, use of this record type is discouraged and should be minimized. Technology Specific Records – Mobile Flow Fields -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Mobile Flow Record provides a structure for communicating information about data flow through the VNF. It can contain @@ -804,7 +804,7 @@ information about connectivity and data flows between serving elements for mobile service, such as between LTE reference points, etc. Technology Specific Records – Signaling Fields -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Signaling Record provides a structure for communicating information about signaling messages, parameters and signaling state. It can @@ -812,28 +812,28 @@ contain information about data flows for signaling and controlling multimedia communication sessions such as voice and video calls. Technology Specific Records – Voice Quality Fields -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Voice Quality Record provides a structure for communicating information about voice quality statistics including media connection information, such as transmitted octet and packet counts, packet loss, packet delay variation, round-trip delay, QoS parameters and codec selection. Technology Specific Records – Future Domains -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The futureDomains Record is a placeholder for additional technology specific areas of interest that will be defined and described in the future documents. Data Structure Specification of the Event Record -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ For additional information on the event record formats of the data structures mentioned above, please refer to `VES Event Listener <https://github.com/att/evel-test-collector/tree/master/docs/att_interface_definition>`__. Transports and Protocols Supporting Resource Interfaces -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Delivery of data from VNFs to ONAP must use the common transport mechanisms and protocols for all VNFs as defined in this document. Transport mechanisms and protocols have been @@ -955,12 +955,12 @@ Monitoring & Management Requirements ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ VNF telemetry via standardized interface -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * R-51910 The xNF **MUST** provide all telemetry (e.g., fault event records, syslog records, performance records etc.) to ONAP using the model, format and mechanisms described in this section. Encoding and Serialization -~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~ Content delivered from VNFs to ONAP is to be encoded and serialized using JSON: @@ -999,7 +999,7 @@ Telemetry data delivered using Google Protocol Buffers v3 (proto3) can be serial Reporting Frequency -~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~ * R-98191 The xNF **MUST** vary the frequency that asynchronous data is delivered based on the content and how data may be aggregated or grouped together. For example, alarms and alerts are expected to be delivered as soon as they appear. In contrast, other content, such as performance measurements, KPIs or reported network signaling may have various ways of packaging and delivering content. Some content should be streamed immediately; or content may be monitored over a time interval, then packaged as collection of records and delivered as block; or data may be collected until a package of a certain size has been collected; or content may be summarized statistically over a time interval, or computed as a KPI, with the summary or KPI being delivered. @@ -1024,7 +1024,7 @@ ONAP destinations can be addressed by URLs for RESTful data PUT. Future data set * R-03070 The xNF **MUST**, by ONAP Policy, provide the ONAP addresses as data destinations for each xNF, and may be changed by Policy while the xNF is in operation. We expect the xNF to be capable of redirecting traffic to changed destinations with no loss of data, for example from one REST URL to another, or from one TCP host and port to another. Asynchronous and Synchronous Data Delivery -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * R-06924 The xNF **MUST** deliver asynchronous data as data becomes available, or according to the configured frequency. * R-73285 The xNF **MUST** must encode, address and deliver the data as described in the previous paragraphs. @@ -1037,7 +1037,7 @@ Asynchronous and Synchronous Data Delivery * R-43327 The xNF **SHOULD** use `Modeling JSON text with YANG <https://tools.ietf.org/html/rfc7951>`_, If YANG models need to be translated to and from JSON{RFC7951]. YANG configuration and content can be represented via JSON, consistent with Avro, as described in “Encoding and Serialization” section. Security -~~~~~~~ +~~~~~~~~~~ * R-42366 The xNF **MUST** support secure connections and transports such as Transport Layer Security (TLS) protocol [`RFC5246 <https://tools.ietf.org/html/rfc5246>`_] and should adhere to the best current practices outlined in `RFC7525 <https://tools.ietf.org/html/rfc7525>`_. * R-44290 The xNF **MUST** control access to ONAP and to xNFs, and creation of connections, through secure credentials, log-on and exchange mechanisms. diff --git a/docs/Chapter8.rst b/docs/Chapter8.rst index f9f983f..0ab904d 100644 --- a/docs/Chapter8.rst +++ b/docs/Chapter8.rst @@ -7,13 +7,13 @@ =============== Chef JSON Key Value Description --------------------------------------------------------------- +------------------------------------- The following provides the key value pairs that must be contained in the JSON file supporting Chef action. Table A1. Chef JSON File key value description -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+-----------------------------------------------------------------------------------------------------------------------------------------+ | **Field Name** | **Description** | **Type** | **Comment** | @@ -90,7 +90,7 @@ b. If a VNF action involves multiple endpoints (VMs) of a VNF, ONAP will The following table describes the JSON dictionary to post in Callback. Table A2. JSON Dictionary to Post in Callback -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+-------------------------------------------------------------+ | **Key** | **Description** | **Type** | **Comment** | @@ -114,7 +114,6 @@ Table A2. JSON Dictionary to Post in Callback | PushJobOutput | Any output from the chef-client run that needs to be returned to ONAP. | Optional | Depends on VNF action. If empty, it must not be included. | +-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+-------------------------------------------------------------+ - Ansible JSON Key Value Description ------------------------------------------------------------- @@ -122,7 +121,7 @@ The following provides the key value pairs that must be contained in the JSON file supporting Ansible action. Table B1. Ansible JSON File key value description -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+---------------------------------------------------------------------+ | **Field Name** | **Description** | **Type** | **Comment** | @@ -181,7 +180,7 @@ This Appendix describes the metadata to be supplied for VNF licenses. Table C1 defines the required and optional fields for licenses. Table C1. Required Fields for General Information -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +---------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+-------------+ | **Field Name** | **Description** | **Data Type** | **Type** | @@ -210,7 +209,7 @@ One or more entitlements can be defined; each one consists of the following fields: Table C2. Required Fields for Entitlements -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +---------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------------+ | **Field Name** | **Description** | **Data Type** | **Type** | @@ -251,7 +250,7 @@ License Keys are not required. Optionally, one or more license keys can be defined; each one consists of the following fields: Table C3. Required Fields for License Keys -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +--------------------------+---------------------------------------------------------------------------------------------------------------+-----------------+-------------+ | **Field Name** | **Description** | **Data Type** | **Type** | @@ -1305,7 +1304,7 @@ The following sections contain examples of Ansible playbook contents which follow the guidelines. Guidelines for Playbooks to properly integrate with APPC -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ NOTE: To support concurrent requests to multiple VNF instances of same or different type, VNF hosts and other files with VNF specific default @@ -1496,7 +1495,7 @@ NOTE: Arguments passed by APPC to Ansible Server to run a playbook take precedence over any defaults stored in Ansible Server. Ansible Playbooks – Notes On Artifacts Required to Run Playbooks -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Inventory hosts file: should be VNF instance specific. diff --git a/docs/index.rst b/docs/index.rst index 2b6c372..2a5a3bc 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -2,7 +2,7 @@ VNF Requirements Documentation ------------------------------ .. toctree:: - :maxdepth: 2 + :maxdepth: 3 :numbered: Chapter1 diff --git a/docs/release-notes.rst b/docs/release-notes.rst index f61fd48..b02a937 100644 --- a/docs/release-notes.rst +++ b/docs/release-notes.rst @@ -4,7 +4,7 @@ VNF Requirements Release Notes -================== +================================ Version: 1.0.0 --------------- |