diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/Chapter1.rst | 2 | ||||
| -rw-r--r-- | docs/Chapter2.rst | 12 | ||||
| -rw-r--r-- | docs/Chapter3.rst | 2 | ||||
| -rw-r--r-- | docs/Chapter4.rst | 64 | ||||
| -rw-r--r-- | docs/Chapter5.rst | 208 | ||||
| -rw-r--r-- | docs/Chapter6.rst | 2 | ||||
| -rw-r--r-- | docs/Chapter7.rst | 126 | ||||
| -rw-r--r-- | docs/Chapter8.rst | 48 | ||||
| -rw-r--r-- | docs/index.rst | 3 |
9 files changed, 246 insertions, 221 deletions
diff --git a/docs/Chapter1.rst b/docs/Chapter1.rst index 76a7a3d..2f5c94d 100644 --- a/docs/Chapter1.rst +++ b/docs/Chapter1.rst @@ -3,7 +3,7 @@ .. Copyright 2017 AT&T Intellectual Property. All rights reserved. -**1. Purpose** +**Purpose** ============== - The purpose of these requirements is to accelerate adoption of VNF/PNF best practices which will increase innovation, minimize customization needed to onboard VNFs/PNFs as well as reduce implementation complexity, time and cost for all impacted stakeholders. - This initial release consolidates the requirements from Open-O and OpenECOMP to provide common VNF/PNF requirements across the industry in order to drive interoperability, simplify management, and reduce cost to build, deploy and manage VNFs/PNFs. diff --git a/docs/Chapter2.rst b/docs/Chapter2.rst index 5527215..3a42ba6 100644 --- a/docs/Chapter2.rst +++ b/docs/Chapter2.rst @@ -3,7 +3,7 @@ .. Copyright 2017 AT&T Intellectual Property. All rights reserved. -**2. Scope** +**Scope** ============ - The audience for this document are VNF/PNF providers, NCSPs and other interested 3rd parties who need to know the design, build and lifecycle management requirements for VNFs/PNFs to be compliant with ONAP. - These requirements are strictly from a standpoint of what the VNF/PNF developer needs to know to operate and be compliant with ONAP. @@ -11,12 +11,12 @@ - These requirements are applicable to the Amsterdam release of ONAP. - Scope of the ONAP versions/release and future functionality -a. References -============= +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/Chapter3.rst b/docs/Chapter3.rst index c1eae6b..0faa84c 100644 --- a/docs/Chapter3.rst +++ b/docs/Chapter3.rst @@ -3,7 +3,7 @@ .. Copyright 2017 AT&T Intellectual Property. All rights reserved. -**3. Introduction** +**Introduction** ==================== - These requirements are specific to the Amsterdam release of ONAP. It is the initial release of requirements based on a merge of the Open-O and OpenECOMP requirements. - Requirements are identified as either MUST, MUST NOT, SHOULD, SHOULD NOT, or MAY as defined in RFC 2119. diff --git a/docs/Chapter4.rst b/docs/Chapter4.rst index ac65980..2c8c450 100644 --- a/docs/Chapter4.rst +++ b/docs/Chapter4.rst @@ -3,11 +3,11 @@ .. Copyright 2017 AT&T Intellectual Property. All rights reserved. -**4. VNF Development Requirements** +**VNF Development Requirements** ==================================== -a. VNF Design -============== +VNF Design +-------------------- Services are composed of VNFs and common components and are designed to be agnostic of the location to leverage capacity where it exists in the @@ -50,8 +50,8 @@ VNF Design Requirements * R-64768 The VNF **MUST** limit the size of application data packets to no larger than 9000 bytes for SDN network-based tunneling when guest data packets are transported between tunnel endpoints that support guest logical networks. * R-74481 The VNF **MUST** NOT require the use of a dynamic routing protocol unless necessary to meet functional requirements. -b. VNF Resiliency -================= +VNF Resiliency +------------------------- The VNF is responsible for meeting its resiliency goals and must factor in expected availability of the targeted virtualization environment. @@ -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 @@ -221,8 +221,8 @@ Monitoring & Dashboard Requirements * R-87352 The VNF **SHOULD** utilize Cloud health checks, when available from the Network Cloud, from inside the application through APIs to check the network connectivity, dropped packets rate, injection, and auto failover to alternate sites if needed. * R-16560 The VNF **SHOULD** conduct a resiliency impact assessment for all inter/intra-connectivity points in the VNF to provide an overall resiliency rating for the VNF to be incorporated into the software design and development of the VNF. -c. VNF Security -=============== +VNF Security +---------------------- The objective of this section is to provide the key security requirements that need to be met by VNFs. The security requirements are @@ -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. @@ -505,17 +505,17 @@ Data Protection Requirements * R-39604 The VNF **MUST** provide the capability of testing the validity of a digital certificate by checking the Certificate Revocation List (CRL) for the certificates of that type to ensure that the certificate has not been revoked. * R-75343 The VNF **MUST** provide the capability of testing the validity of a digital certificate by recognizing the identity represented by the certificate — the "distinguished name". -d. VNF Modularity -================= +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* @@ -848,8 +848,8 @@ incremental.yaml network_id: { get_param: int_oam_net_id } ... -e. VNF Devops -============= +VNF Devops +--------------------- This section includes guidelines for VNF providers to ensure that a Network Cloud Service Provider’s operations personnel have a common and @@ -880,8 +880,8 @@ DevOps Requirements * R-06327 The VNF **MUST** respond to a "drain VNFC" [2]_ command against a specific VNFC, preventing new session from reaching the targeted VNFC, with no disruption to active sessions on the impacted VNFC, if a VNF provides a load balancing function across multiple instances of its VNFCs. This is used to support scenarios such as proactive maintenance with no user impact. * R-64713 The VNF **SHOULD** support a software promotion methodology from dev/test -> pre-prod -> production in software, development & testing and operations. -f. VNF Develop Steps -======================= +VNF Develop Steps +-------------------------------- Aid to help the VNF provider to fasten the integration with the GVNFM, the ONAP provides the VNF SDK tools, and the documents. In this charter, diff --git a/docs/Chapter5.rst b/docs/Chapter5.rst index 55d49c7..030925f 100644 --- a/docs/Chapter5.rst +++ b/docs/Chapter5.rst @@ -1,19 +1,17 @@ -:tocdepth: 2 - .. This work is licensed under a Creative Commons Attribution 4.0 International License. .. http://creativecommons.org/licenses/by/4.0 .. Copyright 2017 AT&T Intellectual Property. All rights reserved. -**5. VNF Modeling Requirements** +**VNF Modeling Requirements** ===================================== -a. TOSCA YAML -============= +TOSCA YAML +---------------------- Introduction -------------- +^^^^^^^^^^^ This reference document is the VNF TOSCA Template Requirements for ONAP, which provides recommendations and standards for building VNF @@ -29,13 +27,13 @@ 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. Scope ------ +^^^^^^^^^^^^^^^^ ONAP implementations of Network Cloud supports TOSCA Templates, also referred to as TOSCA in this document. @@ -45,7 +43,7 @@ document provides the mandatory, recommended, and optional requirements associated with this format. Overview ---------- +^^^^^^^^^^^^^^^^ The document includes three charters to help the VNF providers to use the VNF model design tools and understand the VNF package structure and VNF @@ -64,13 +62,13 @@ supports multiple TOSCA template yaml files, and also supports self-defined node or other extensions. NFV TOSCA Template ------------------- +^^^^^^^^^^^^^^^^^^^^ TOSCA templates supported by ONAP must follow the requirements enumerated in this section. TOSCA Introduction ------------------- +^^^^^^^^^^^^^^^^^^^^ TOSCA defines a Meta model for defining IT services. This Meta model defines both the structure of a service as well as how to manage it. A @@ -95,14 +93,14 @@ how many times the component can occur. Figure 1: Structural Elements of Service Template and their Relations TOSCA Modeling Principles & Data Model --------------------------------------- +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This section describing TOSCA modeling principles and data model for NFV, which shall be based on [TOSCA-1.0] and [TOSCA-Simple-Profile-YAML V1.0], or new type based on ETSI NFV requirements, etc. VNF Descriptor Template ------------------------ +^^^^^^^^^^^^^^^^^^^^^^^^ The VNF Descriptor (VNFD) describes the topology of the VNF by means of ETSI NFV IFA011 [IFA011] terms such as VDUs, Connection Points, Virtual @@ -189,7 +187,7 @@ specification [TOSCA-Simple-Profile-NFV-v1.0] for NFV VNFD. +--------------------------------------------------------------------+ EPA Requirements ----------------- +^^^^^^^^^^^^^^^^ 1. SR-IOV Passthrought @@ -410,7 +408,7 @@ supports dpdk. Here is an example. +------------------------------------------------------+ NFV TOSCA Type Definition -------------------------- +^^^^^^^^^^^^^^^^^^^^^^^^ tosca.capabilites.nfv.VirtualCompute ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -426,7 +424,7 @@ tosca.capabilites.nfv.VirtualCompute +---------------------------+-----------------------------------------+ Properties -^^^^^^^^^^ ++++++++++ +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+ | Name | Required | Type | Constraints | Description | @@ -442,7 +440,7 @@ Properties +-------------------------------------+------------+-----------------------------------------------------+---------------+---------------------------------------------------------+ Definition -^^^^^^^^^^ ++++++++++ +-----------------------------------------------------------+ | tosca.capabilities.nfv.VirtualCompute: | @@ -495,13 +493,13 @@ NFV IFA011].** Attributes -^^^^^^^^^^ ++++++++++ None Capabilities -^^^^^^^^^^^^ ++++++++++++ +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+ | Name | Type | Constraints | Description | @@ -518,7 +516,7 @@ Capabilities +-------------------------+-------------------------------------------------+---------------+-----------------------------------------------------------------------------------------------------+ Definition -^^^^^^^^^^ ++++++++++++ +-----------------------------------------------------------------------------------------------------+ | tosca.nodes.nfv.VDU.Compute: | @@ -659,7 +657,7 @@ Definition +-----------------------------------------------------------------------------------------------------+ Artifact -^^^^^^^^ ++++++++++++ +-----------+------------+-------------------------------+---------------+------------------------------------------------+ | Name | Required | Type | Constraints | Description | +===========+============+===============================+===============+================================================+ @@ -689,7 +687,7 @@ used as parent for the various Cpd types. Attributes -^^^^^^^^^^ ++++++++++++ +--------+------------+--------+---------------+---------------+ | Name | Required | Type | Constraints | Description | @@ -697,17 +695,17 @@ Attributes +--------+------------+--------+---------------+---------------+ Requirements -^^^^^^^^^^^^ ++++++++++++ None Capabilities -^^^^^^^^^^^^ ++++++++++++ None Definition -^^^^^^^^^^ ++++++++++++ +----------------------------------------------------------------------+ | tosca.nodes.nfv.Cpd: | @@ -754,7 +752,7 @@ Definition +----------------------------------------------------------------------+ Additional Requirement -^^^^^^^^^^^^^^^^^^^^^^ +++++++++++++++++++++++++ None. @@ -774,7 +772,7 @@ internal VL as defined by [ETSI GS NFV-IFA 011]. +-----------------------+--------------------------+ Properties -^^^^^^^^^^ +++++++++++++ +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+ @@ -787,12 +785,12 @@ Properties +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+ Attributes -^^^^^^^^^^ +++++++++++++ None Requirements -^^^^^^^^^^^^ +++++++++++++ +--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+ | Name | Required | Type | Constraints | Description | @@ -803,7 +801,7 @@ Requirements +--------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+ Definition -^^^^^^^^^^ +++++++++++++ +----------------------------------------------------------------+ | tosca.nodes.nfv.VduCpd: | @@ -883,7 +881,7 @@ tosca.artifacts.nfv.SwImage +---------------------------+------------------------------------+ Properties -^^^^^^^^^^ +++++++++++++ +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+ | Name | Required | Type | Constraints | Description | @@ -912,7 +910,7 @@ Properties +------------------------------------------+------------+--------------------+---------------+----------------------------------------------------------------------------------------------------+ Definition -^^^^^^^^^^ +++++++++++++ +-----------------------------------------------------+ | tosca.artifacts.nfv.SwImage: | @@ -997,7 +995,7 @@ Definition +-----------------------------------------------------+ vNAT Example ------------- +^^^^^^^^^^^^^ openovnf\_\_vOpenNAT.yaml ~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1550,21 +1548,21 @@ openonfv\_\_tosca.nodes.nfv.VduCpd.yaml :height: 2.46042in -b. Heat -======= +Heat +--------- General Guidelines ------------------- +^^^^^^^^^^^^^^^^^ YAML Format ------------ +^^^^^^^^^^^^^^^^^ Heat Orchestration Templates must use valid YAML. YAML (YAML Ain't 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. @@ -1626,24 +1624,24 @@ 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. description -^^^^^^^^^^^ +++++++++++++++++++++++ This ONAP mandatory section allows for a description of the template. parameter\_groups -^^^^^^^^^^^^^^^^^ +++++++++++++++++++++++ This ONAP optional section allows for specifying how the input parameters should be grouped and the order to provide the parameters in. parameters -^^^^^^^^^^ +++++++++++++++++++++++ The parameter section is ONAP mandatory. This section allows for specifying input parameters that have to be provided when instantiating @@ -1789,7 +1787,7 @@ availability\_zone. - This attribute is optional and defaults to false. resources -^^^^^^^^^ ++++++++++++ This section is ONAP mandatory; it must be provided. This section contains the declaration of the single resources of the template. This @@ -1883,7 +1881,7 @@ with the following syntax. create the resource or not. This attribute is optional. outputs -^^^^^^^ ++++++++++ This ONAP optional section allows for specifying output parameters available to users once the template has been instantiated. If the @@ -1891,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) @@ -1953,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. @@ -1977,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. @@ -2054,7 +2052,7 @@ nested heat file must be passed in as properties in the resource definition defined in the parent heat template. ONAP Parameter Classifications Overview ---------------------------------------- +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In order for ONAP to support workflow automation, Heat Orchestration Template resource property parameters must adhere to specific naming @@ -2093,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, @@ -2115,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. @@ -2143,7 +2141,7 @@ VNF instances (e.g., image, flavor). The constant parameters are subdivided into two categories: **ONAP Constant Parameters** and **VNF Constant Parameters.** ONAP Constant Parameters -^^^^^^^^^^^^^^^^^^^^^^^^ ++++++++++++++++++++++++++++++ - ONAP Constant Parameters must be enumerated in the environment file. These parameter values are not assigned by ONAP. @@ -2159,7 +2157,7 @@ ONAP Constant Parameters parameter naming convention. `ONAP Resource ID and Parameter Naming Convention`_ provides additional details. VNF Constant Parameters -^^^^^^^^^^^^^^^^^^^^^^^ ++++++++++++++++++++++++++++++ - VNF Constant Parameters must be enumerated in the environment file. These parameter values are not assigned by ONAP. @@ -2189,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 @@ -2217,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. @@ -2253,7 +2251,7 @@ 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 @@ -2263,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. @@ -2283,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 @@ -2336,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 @@ -2375,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 @@ -2384,7 +2382,7 @@ This section provides the ONAP naming requirements for 2. Resource Property Parameters {vm-type} ---------- +^^^^^^^^^^^ The Heat Orchestration Templates for a VNF must assign a VNF unique {vm-type} for each Virtual Machine type (i.e., OS::Nova::Server) @@ -2427,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`_. @@ -2462,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`_ @@ -2580,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 @@ -2769,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 @@ -2877,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 @@ -3130,7 +3128,7 @@ 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.) @@ -3154,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 @@ -3200,7 +3198,7 @@ Table 5: OS::Neutron::Port Resource Property Parameters (External Networks) Internal Networks -^^^^^^^^^^^^^^^^^ +++++++++++++++++ When the parameter references an internal network @@ -3250,7 +3248,7 @@ 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 @@ -3297,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 @@ -3345,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 @@ -3431,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 @@ -3485,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 @@ -3624,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 @@ -3805,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 @@ -3869,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 @@ -3898,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. @@ -3994,7 +3992,7 @@ As a general rule, provide the fixed IPs for the VMs indexed first in the CDL and then the VIPs as shown in the examples above. ONAP SDN-C Assignment of allowed\_address\_pair IP Addresses -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The following items must be taken into consideration when designing Heat Orchestration Templates that expect ONAP’s SDN-C to assign @@ -4005,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`_. @@ -4090,7 +4088,7 @@ the only special characters supported are: - “ ! $ ‘ ( ) = ~ ^ \| @ \` { } [ ] > , . \_ ONAP Output Parameter Names ---------------------------- +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ONAP defines three types of Output Parameters as detailed in `Output Parameters`_. @@ -4114,7 +4112,7 @@ ONAP currently defines one predefined output parameter the OAM Management IP Addresses. OAM Management IP Addresses -^^^^^^^^^^^^^^^^^^^^^^^^^^^ ++++++++++++++++++++++++++++++ A VNF may have a management interface for application controllers to interact with and configure the VNF. Typically, this will be via a @@ -4227,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 @@ -4240,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 @@ -4349,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 @@ -4403,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 @@ -4509,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 @@ -4546,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 @@ -4560,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 @@ -4572,10 +4570,10 @@ stack-create”, all parameters must be enumerated in the environment file. Heat Template Constructs ------------------------- +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Nested Heat Templates ---------------------- +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ONAP supports nested Heat templates per the OpenStack specifications. Nested templates may be suitable for larger VNFs that contain many @@ -4629,7 +4627,7 @@ Note that: get\_attribute targets against the “parent” resource. Nested Heat Template Example: Static -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ++++++++++++++++++++++++++++++++++ incremental.yaml @@ -4749,7 +4747,7 @@ You can then reference within the nested template as: { get\_param: [names, {get\_param: index} ] } ResourceGroup Property count -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ++++++++++++++++++++++++++++++++++ ONAP requires that the OS::Heat::ResourceGroup property count be defined (even if the value is one) and that the value must be enumerated in the @@ -4769,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 @@ -4820,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 @@ -4837,7 +4835,7 @@ environment files. is accessing information with the VM private/internal network. Heat Files Support (get\_file) ------------------------------- +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Heat Templates may contain the inclusion of text files into Heat templates via the Heat get\_file directive. This may be used, for @@ -4865,7 +4863,7 @@ Support for Heat Files is subject to the following limitations: templates Key Pairs ---------- +^^^^^^^^^^^^^^^^^^ When Nova Servers are created via Heat templates, they may be passed a “keypair” which provides an ssh key to the ‘root’ login on the newly @@ -4930,7 +4928,7 @@ of lb (for load balancer)):* save_private_key: false Security Groups ---------------- +^^^^^^^^^^^^^^^^^^ OpenStack allows a tenant to create Security groups and define rules within the security groups. @@ -4945,7 +4943,7 @@ network or it can vary by VM (i.e., {vm-type}) and network type (i.e., {network-role}). Anti-Affinity and Affinity Rules --------------------------------- +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Anti-affinity or affinity rules are supported using normal OpenStack OS::Nova::ServerGroup resources. Separate ServerGroups are typically @@ -5006,7 +5004,7 @@ balancer and db for database. group: {get_resource: lb_server_group} Resource Data Synchronization ------------------------------ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ For cases where synchronization is required in the orchestration of Heat resources, two approaches are recommended: @@ -5076,7 +5074,7 @@ oam server. instance_uuid: {get_resource: oam_server_01} High Availability ------------------ +^^^^^^^^^^^^^^^^^^ VNF/VM parameters may include availability zone IDs for VNFs that require high availability. @@ -5088,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 @@ -5101,8 +5099,8 @@ to the Heat template. *Note:* It is important to follow this convention to the extent possible even in the short-term as of the long-term direction. -c. VNFM Driver Development Steps -================================ +VNFM Driver Development Steps +--------------------------------------------------------- Refer to the ONAP documentation for VNF Provider instructions on integrating vendor-specific VNFM adaptors with VF-C. The VNF driver development steps are @@ -5117,8 +5115,8 @@ is a microservice providing a translation interface from VF-C to the vendor-specific VNFM. The interface definitions of vendor-specific VNFM adaptors are supplied by the VNF Providers themselves. -d. Creating Vendor-Specific VNFM Adaptor Microservices -====================================================== +Creating Vendor-Specific VNFM Adaptor Microservices +------------------------------------------------------------------------------------------------------------------ VNFs can be managed by vendor-specific VNFMs. To add a vendor-specific VNFM to ONAP, a vendor-specific VNFM adaptor is added to ONAP implementing the interface of the vendor-specific VNFM. diff --git a/docs/Chapter6.rst b/docs/Chapter6.rst index aef6849..8bfd04c 100644 --- a/docs/Chapter6.rst +++ b/docs/Chapter6.rst @@ -3,7 +3,7 @@ .. Copyright 2017 AT&T Intellectual Property. All rights reserved. -**6. Infrastructure Requirements** +**Infrastructure Requirements** ===================================== This Amsterdam release of the requirements is targeted for those implementations that consist of Network Clouds: Vanilla OpenStack (based on Ocata_) and commercial Clouds for example: OpenStack (including `Titanium - Mitaka from Wind River`_ and `VIO - Ocata from VMware`_). Future versions of ONAP are envisioned to include other targeted cloud infrastructure implementations, for example, on-premise private cloud, public cloud, or hybrid cloud implementations, and related network backends, e.g. `Microsoft Azure`_ et al. diff --git a/docs/Chapter7.rst b/docs/Chapter7.rst index 8d88bab..dcb5afe 100644 --- a/docs/Chapter7.rst +++ b/docs/Chapter7.rst @@ -1,11 +1,9 @@ -:tocdepth: 2 - .. This work is licensed under a Creative Commons Attribution 4.0 International License. .. http://creativecommons.org/licenses/by/4.0 .. Copyright 2017 AT&T Intellectual Property. All rights reserved. -**7. ONAP Management Requirements** +**ONAP Management Requirements** ===================================== The ONAP platform is the part of the larger Network Function Virtualization/Software Defined Network (NFV/SDN) ecosystem that is responsible for the efficient control, operation and management of Virtual Network Function (VNF) capabilities and functions. It specifies standardized abstractions and interfaces that enable efficient interoperation of the NVF/SDN ecosystem components. It enables product/service independent capabilities for design, creation and runtime lifecycle management (includes all aspects of installation, change management, assurance, and retirement) of resources in NFV/SDN environment (see ECOMP white paper ). These capabilities are provided using two major architectural frameworks: (1) a Design Time Framework to design, define and program the platform (uniform onboarding), and (2) a Runtime Execution Framework to execute the logic programmed in the design environment (uniform delivery and runtime lifecycle management). The platform delivers an integrated information model based on the VNF package to express the characteristics and behavior of these resources in the Design Time Framework. The information model is utilized by Runtime Execution Framework to manage the runtime lifecycle of the VNFs. The management processes are orchestrated across various modules of ONAP to instantiate, configure, scale, monitor, and reconfigure the VNFs using a set of standard APIs provided by the VNF developers. @@ -19,15 +17,16 @@ Although the guidelines and requirements specified in this document were origina * Requirements that only apply to PNFs are defined as "The PNF MUST/SHOULD/..." -a. Service Design -================== +Service Design +------------------------------------ This section, Service Design, has been left intentionally blank. It is out-of-scope for the VNF Requirements project for the Amsterdam release and no numbered requirements are expected. Content may be added in future updates of this document. -b. VNF On-boarding and package management -========================================== +VNF On-boarding and package management +----------------------------------------------------------------------------- -**Design Definition** +Design Definition +^^^^^^^^^^^^^^^^^^ The ONAP Design Time Framework provides the ability to design NFV resources including VNFs, Services, and products. The VNF provider must @@ -44,7 +43,8 @@ Requirements contained in the ETSI Document: ETSI GS NFV-MAN 001 v1.1.1 and GS NFV IFA011 V0.3.0 (2015-10) - Network Functions Virtualization (NFV), Management and Orchestration, VNF Packaging Specification. -**Resource Description** +Resource Description +^^^^^^^^^^^^^^^^^^^^^^ * R-77707 The VNF provider **MUST** include a Manifest File that contains a list of all the components in the VNF package. * R-66070 The xNF Package **MUST** include xNF Identification Data to uniquely identify the resource for a given xNF provider. The identification data must include: an identifier for the xNF, the name of the xNF as was given by the xNF provider, xNF description, xNF provider, and version. @@ -60,7 +60,8 @@ and GS NFV IFA011 V0.3.0 (2015-10) - Network Functions Virtualization * R-36280 The xNF provider **MUST** provide documentation describing xNF Functional Capabilities that are utilized to operationalize the xNF and compose complex services. * R-98617 The xNF provider **MUST** provide information regarding any dependency (e.g., affinity, anti-affinity) with other xNFs and resources. -**Resource Configuration** +Resource Configuration +^^^^^^^^^^^^^^^^^^^^^^^ * R-89571 The xNF **MUST** support and provide artifacts for configuration management using at least one of the following technologies: @@ -70,18 +71,21 @@ and GS NFV IFA011 V0.3.0 (2015-10) - Network Functions Virtualization 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. - **Configuration Management via Netconf/YANG** +Configuration Management via Netconf/YANG +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * R-30278 The xNF provider **MUST** provide a Resource/Device YANG model as a foundation for creating the YANG model for configuration. This will include xNF attributes/parameters and valid values/attributes configurable by policy. - **Configuration Management via Chef** +Configuration Management via Chef +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * R-13390 The xNF provider **MUST** provide cookbooks to be loaded on the appropriate Chef Server. * R-18525 The xNF provider **MUST** provide a JSON file for each supported action for the xNF. The JSON file must contain key value pairs with all relevant values populated with sample data that illustrates its usage. The fields and their description are defined in Appendix A. Note: Chef support in ONAP is not currently available and planned for 4Q 2017. - **Configuration Management via Ansible** +Configuration Management via Ansible +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * R-75608 The xNF provider **MUST** provide playbooks to be loaded on the appropriate Ansible Server. * R-16777 The xNF provider **MUST** provide a JSON file for each supported action for the xNF. The JSON file must contain key value pairs with all relevant values populated with sample data that illustrates its usage. The fields and their description are defined in Appendix B. @@ -89,7 +93,8 @@ and GS NFV IFA011 V0.3.0 (2015-10) - Network Functions Virtualization * R-46567 The xNF Package **MUST** include configuration scripts for boot sequence and configuration. * R-16065 The xNF provider **MUST** provide configurable parameters (if unable to conform to YANG model) including xNF attributes/parameters and valid values, dynamic attributes and cross parameter dependencies (e.g., customer provisioning data). -**Resource Control Loop** +Resource Control Loop +^^^^^^^^^^^^^^^^^^^^^^^ * R-22888 The xNF provider **MUST** provide documentation for the xNF Policy Description to manage the xNF runtime lifecycle. The document must include a description of how the policies (conditions and actions) are implemented in the xNF. * R-01556 The xNF Package **MUST** include documentation describing the fault, performance, capacity events/alarms and other event records that are made available by the xNF. The document must include: @@ -114,7 +119,8 @@ and GS NFV IFA011 V0.3.0 (2015-10) - Network Functions Virtualization * R-48596 The xNF Package **MUST** include documentation describing the characteristics for the xNF reliability and high availability. * R-74763 The xNF provider **MUST** provide an artifact per xNF that contains all of the xNF Event Records supported. The artifact should include reference to the specific release of the xNF Event Stream Common Event Data Model document it is based on. (e.g., `VES Event Listener <https://github.com/att/evel-test-collector/tree/master/docs/att_interface_definition>`__) -**Compute, Network, and Storage Requirements** +Compute, Network, and Storage Requirements +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * R-35851 The xNF Package **MUST** include xNF topology that describes basic network and application connectivity internal and external to the xNF including Link type, KPIs, Bandwidth, latency, jitter, QoS (if applicable) for each interface. * R-97102 The VNF Package **MUST** include VM requirements via a Heat template that provides the necessary data for: @@ -130,13 +136,15 @@ and GS NFV IFA011 V0.3.0 (2015-10) - Network Functions Virtualization * R-96634 The VNF provider **MUST** describe scaling capabilities to manage scaling characteristics of the VNF. -**Testing** +Testing +^^^^^^^^^^ * R-43958 The xNF Package **MUST** include documentation describing the tests that were conducted by the xNF providor and the test results. * R-04298 The xNF provider **MUST** provide their testing scripts to support testing. * R-58775 The xNF provider **MUST** provide software components that can be packaged with/near the xNF, if needed, to simulate any functions or systems that connect to the xNF system under test. This component is necessary only if the existing testing environment does not have the necessary simulators. -**Licensing Requirements** +Licensing Requirements +^^^^^^^^^^^^^^^^^^^^^^^ * R-85653 The xNF **MUST** provide metrics (e.g., number of sessions, number of subscribers, number of seats, etc.) to ONAP for tracking every license. * R-44125 The xNF provider **MUST** agree to the process that can be met by Service Provider reporting infrastructure. The Contract shall define the reporting process and the available reporting tools. @@ -148,8 +156,8 @@ and GS NFV IFA011 V0.3.0 (2015-10) - Network Functions Virtualization * R-85991 The xNF provider **MUST** provide a universal license key per xNF to be used as needed by services (i.e., not tied to a VM instance) as the recommended solution. The xNF provider may provide pools of Unique xNF License Keys, where there is a unique key for each xNF instance as an alternate solution. Licensing issues should be resolved without interrupting in-service xNFs. * R-47849 The xNF provider **MUST** support the metadata about licenses (and their applicable entitlements) as defined in this document for xNF software, and any license keys required to authorize use of the xNF software. This metadata will be used to facilitate onboarding the xNF into the ONAP environment and automating processes for putting the licenses into use and managing the full lifecycle of the licenses. The details of this license model are described in Appendix C. Note: License metadata support in ONAP is not currently available and planned for 1Q 2018. -c. Configuration Management -=========================== +Configuration Management +--------------------------------------------------- ONAP interacts directly with VNFs through its Network and Application Adapters to perform configuration activities within NFV environment. @@ -163,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 @@ -171,14 +179,17 @@ configuration. The VNF providers must provide the Device YANG model and NETCONF server supporting NETCONF APIs to comply with target ONAP and industry standards. -**VNF Configuration via NETCONF Requirements** +VNF Configuration via NETCONF Requirements +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -**Configuration Management** +Configuration Management ++++++++++++++++++++++++++++ * R-88026 The xNF **MUST** include a NETCONF server enabling runtime configuration and lifecycle management capabilities. * R-95950 The xNF **MUST** provide a NETCONF interface fully defined by supplied YANG models for the embedded NETCONF server. -**NETCONF Server Requirements** +NETCONF Server Requirements +++++++++++++++++++++++++++++++ * R-73468 The xNF **MUST** allow the NETCONF server connection parameters to be configurable during virtual machine instantiation through Heat templates where SSH keys, usernames, passwords, SSH service and SSH port numbers are Heat template parameters. * R-90007 The xNF **MUST** implement the protocol operation: **close-session()**- Gracefully close the current session. @@ -267,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`_). @@ -284,7 +295,8 @@ over HTTP(s). The port number, url, and other authentication information is provided by the VNF provider. -**REST APIs** +REST APIs +~~~~~~~~~ * R-31809 The xNF **MUST** support the HealthCheck RPC. The HealthCheck RPC executes a xNF Provider-defined xNF Healthcheck over the scope of the entire xNF (e.g., if there are multiple VNFCs, then run a health check, as appropriate, for all VNFCs). It returns a 200 OK if the test completes. A JSON object is returned indicating state (healthy, unhealthy), scope identifier, time-stamp and one or more blocks containing info and fault information. If the xNF is unable to run the HealthCheck, return a standard http error code and message. @@ -316,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. @@ -334,9 +346,11 @@ Chef REST APIs to manage the VNF and requires the use of open source Chef-Client and Push Jobs Client on the VNF (https://downloads.chef.io/). -**VNF Configuration via Chef Requirements** +VNF Configuration via Chef Requirements +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -**Chef Client 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. @@ -346,7 +360,8 @@ Chef-Client and Push Jobs Client on the VNF - Chef-Client >= 12.0 - Chef push jobs client >= 2.0 -**Chef Roles/Requirements** +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. @@ -420,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. @@ -431,9 +446,11 @@ data and execution capabilities to take the necessary action on one or more targ (and/or VNFCs) of the VNF. ONAP will utilize the framework of an Ansible Server that will host and run playbooks to manage VNFs that support Ansible. -**VNF Configuration via Ansible Requirements** +VNF Configuration via Ansible Requirements +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -**Ansible Client 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. @@ -445,7 +462,8 @@ will host and run playbooks to manage VNFs that support Ansible. * R-92866 The VNF **MUST** include as part of post-instantiation configuration done by Ansible Playbooks the removal/update of SSH keys loaded through instantiation to support Ansible. This may include download and install of new SSH keys. * 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** +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. @@ -505,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. @@ -515,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 @@ -628,8 +646,8 @@ Table 10. Planned ONAP Controller Functions +------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -d. Monitoring & Management -=========================== +Monitoring & Management +-------------------------------------------------- This section addresses data collection and event processing functionality that is directly dependent on the interfaces provided by the VNFs’ APIs. These can be in the form of asynchronous @@ -649,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 @@ -693,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: @@ -808,14 +826,14 @@ 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 @@ -934,17 +952,20 @@ still leveraging the VES JSON based model in DCAE. The purpose of the diagram a is to illustrate the concept only and not to imply a specific implementation. Monitoring & Management Requirements -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -**VNF telemetry via standardized interface** +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** +Encoding and Serialization +~~~~~~~~~~~~~~~~~~~~~~ Content delivered from VNFs to ONAP is to be encoded and serialized using JSON: -**JSON** +JSON +~~~~~~~~~~~~~~~~~~ * R-19624 The xNF **MUST** encode and serialize content delivered to ONAP using JSON (RFC 7159) plain text format. High-volume data is to be encoded and serialized using `Avro <http://avro.apache.org/>`_, where the Avro [5]_ data format are described using JSON. @@ -955,7 +976,8 @@ Content delivered from VNFs to ONAP is to be encoded and serialized using JSON: In addition to the preferred method (JSON), content can be delivered from xNFs to ONAP can be encoded and serialized using Google Protocol Buffers (GPB). -**KV-GPB/GPB** +KV-GPB/GPB +~~~~~~~~~~~~~~~~~~ Telemetry data delivered using Google Protocol Buffers v3 (proto3) can be serialized in one of the following methods: @@ -976,14 +998,16 @@ Telemetry data delivered using Google Protocol Buffers v3 (proto3) can be serial * In the future, we may consider support for other types of encoding & serialization methods based on industry demand -**Reporting Frequency** +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. - We expect the reporting frequency to be configurable depending on the virtual network function’s needs for management. For example, Service Provider may choose to vary the frequency of collection between normal and trouble-shooting scenarios. - Decisions about the frequency of data reporting will affect the size of delivered data sets, recommended delivery method, and how the data will be interpreted by ONAP. These considerations should not affect deserialization and decoding of the data, which will be guided by the accompanying JSON schema or GPB definition files. -**Addressing and Delivery Protocol** +Addressing and Delivery Protocol +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ONAP destinations can be addressed by URLs for RESTful data PUT. Future data sets may also be addressed by host name and port number for TCP streaming, or by host name and landing zone directory for SFTP transfer of bulk files. @@ -999,7 +1023,8 @@ 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** +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. @@ -1011,7 +1036,8 @@ ONAP destinations can be addressed by URLs for RESTful data PUT. Future data set * R-46290 The xNF **MUST** respond to an ONAP request to deliver granular data on device or subsystem status or performance, referencing the YANG configuration model for the xNF by returning the requested data elements. * R-43327 The xNF **SHOULD** use `Modeling JSON text with YANG <https://tools.ietf.org/html/rfc7951>`_, If YANG models need to be translated to and from JSON{RFC7951]. YANG configuration and content can be represented via JSON, consistent with Avro, as described in “Encoding and Serialization” section. -**Security** +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 6c8b01d..f9f983f 100644 --- a/docs/Chapter8.rst +++ b/docs/Chapter8.rst @@ -3,17 +3,17 @@ .. Copyright 2017 AT&T Intellectual Property. All rights reserved. -**8. Appendix** +**Appendix** =============== -a. – Chef JSON Key Value Description -================================================= +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** | @@ -115,14 +115,14 @@ Table A2. JSON Dictionary to Post in Callback +-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+-------------------------------------------------------------+ -b. – Ansible JSON Key Value Description -=================================================== +Ansible JSON Key Value Description +------------------------------------------------------------- The following provides the key value pairs that must be contained in the JSON file supporting Ansible action. Table B1. Ansible JSON File key value description -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+---------------------------------------------------------------------+ | **Field Name** | **Description** | **Type** | **Comment** | @@ -171,8 +171,8 @@ b. Execute the playbook named ‘Ansible\_configure.yml’ on nodes with c. If execution time of the playbook exceeds 60 secs (across all hosts), it will be terminated. -c. – VNF License Information Guidelines -=================================================== +VNF License Information Guidelines +------------------------------------------------------------ This Appendix describes the metadata to be supplied for VNF licenses. @@ -181,7 +181,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 +210,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 +251,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** | @@ -317,7 +317,7 @@ example: - use is allowed in Canada Table C4. Required Fields for Location -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +------------------------+---------------------------------------------------------------------------------------------------------------------+------------------+-------------+ | **Field Name** | **Description** | **Data Type** | **Type** | @@ -354,7 +354,7 @@ Limit on the length of time the software may be used. For example: - entitlement valid from 15 May 2018 thru 30 June 2020 Table C5. Required Fields for Time -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +------------------------+-------------------------------------------------------------------------------------------------------------------------------+------------------+---------------+ | **Field Name** | **Description** | **Data Type** | **Type** | @@ -397,7 +397,7 @@ Limits based on how the software is used. For example: - use is limited by software release Table C6. Required Fields for Usage -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +------------------------+--------------------------------------------------------------------------------------------------------------+------------------+-------------+ | **Field Name** | **Description** | **Data Type** | **Type** | @@ -435,7 +435,7 @@ make use of the software. For example: - allowed to be used only for government entities Table C7. Required Fields for Entity -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +------------------------+--------------------------------------------------------------------------------------------------------------+------------------+-------------+ | **Field Name** | **Description** | **Data Type** | **Type** | @@ -478,7 +478,7 @@ any aggregation function (e.g., peak or average users), and aggregation interval (day, month, quarter, year, etc.). Table C8. Required Fields for Amount -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+-------------+ | **Field Name** | **Description** | **Data Type** | **Type** | @@ -520,8 +520,8 @@ Table C8. Required Fields for Amount | Type of User | Describes the types of users of the functionality offered by the software (e.g., authorized, named). This field is included when Limit Type is user. | String | Optional | +------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------+-------------+ -d. – Requirement List -================================== +Requirement List +-------------------------------- R-11200: The VNF **MUST** keep the scope of a Cinder volume module, when it exists, to be 1:1 with the VNF Base Module or Incremental Module. @@ -1298,14 +1298,14 @@ R-49945: The VNF **MUST** authorize VNF provider access through a client applica R-20912: The VNF **MUST** support alternative monitoring capabilities when VNFs do not expose data or control traffic or use proprietary and optimized protocols for inter VNF communication. -e. - Ansible Playbook Examples -============================== +Ansible Playbook Examples +----------------------------------------------- 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 +1496,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 77db178..2b6c372 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -2,7 +2,8 @@ VNF Requirements Documentation ------------------------------ .. toctree:: - :titlesonly: + :maxdepth: 2 + :numbered: Chapter1 Chapter2 |