VNFRQTS - Updating hierarchy of guidelinescasablanca

Changing the hierarchy to remove redundancy as well as add new
theme for local changes.

Issue-ID: VNFRQTS-462

Change-Id: Ifa54877fe48572ea24768b9e4b68f9f0ed5438ae
Signed-off-by: Bozawglanian, Hagop (hb755d) <hagop.bozawglanian@att.com>

1 files changed, 1224 insertions, 0 deletions

diff --git a/docs/vnf_guidelines.rst b/docs/vnf_guidelines.rst
new file mode 100644
index 0000000..f083dd1
--- /dev/null
+++ b/docs/vnf_guidelines.rst
@@ -0,0 +1,1224 @@
+.. Modifications Copyright © 2017-2018 AT&T Intellectual Property.
+
+.. Licensed under the Creative Commons License, Attribution 4.0 Intl.
+   (the "License"); you may not use this documentation except in compliance
+   with the License. You may obtain a copy of the License at
+
+.. https://creativecommons.org/licenses/by/4.0/
+
+.. Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.
+
+
+.. contents:: Table of Contents
+   :depth: 3
+   :backlinks: entry
+
+
+VNF/PNF Guidelines
+==================
+
+
+**Purpose**
+------------------------
+- This document focuses on setting and evolving VNF/PNF standards that
+  will facilitate industry discussion, participation, alignment and evolution
+  towards comprehensive and actionable VNF/PNF best practices and standard
+  interface.
+- The goal 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.
+- The intent is to drive harmonization of VNFs/PNFs across VNF/PNF providers,
+  Network Cloud Service providers (NCSPs) and the overall Network Function
+  Virtualization (NFV) ecosystem by providing both long term vision as well
+  as short tem focus and clarity.
+
+**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 guidelines describe VNF environment and provide an overview of
+  what the VNF developer needs to know to operate and be compliant with ONAP.
+- These guidelines contains high level expectations and references to
+  specific requirements documentation for VNFs/PNFs which are applicable
+  to the current release of ONAP.
+- Part of the guidelines also contains visionary recommendations for
+  future functionality that could be desirable for ONAP future releases.
+- Conformance requirements are in the `VNF/PNF Requirements
+  document <http://onap.readthedocs.io/en/latest/submodules/vnfrqts/requirements.git/docs/index.html>`_.
+
+**Introduction**
+-------------------------------
+
+Motivation
+^^^^^^^^^^^^^^^^^^^^
+
+The requirements and guidelines defined herein are intended to
+facilitate industry discussion, participation alignment and evolution
+toward comprehensive and actionable VNF/PNF best practices. Integration
+costs are a significant impediment to the development and deployment of
+new services. We envision developing open source industry processes and
+best practices leading eventually to VNF/PNF standards supporting commercial
+acquisition of VNFs/PNFs with minimal integration costs. Traditional PNFs
+have all been unique like snowflakes and required expensive custom
+integration, whereas VNF products and services should be designed for
+easier integration just like Lego\ :sup:`TM` blocks. For example, by
+standardizing on common actions and related APIs supported by VNFs, plug
+and play integration is assured, jumpstarting automation with management
+frameworks. Onboarding VNFs would no longer require complex and
+protracted integration or development activities thus maximizing
+automation and minimizing integration cost. Creating VNF open source
+environments, best practices and standards provides additional benefits
+to the NFV ecosystems such as:
+
+-  Larger market for VNF providers
+
+-  Rapid introduction and integration of new capabilities into the
+   services providers environment
+
+-  Reduced development times and costs for VNF providers
+
+-  Better availability of new capabilities to NCSPs
+
+-  Better distribution of new capabilities to end-user consumers
+
+-  Reduced integration cost (capex) for NCSPs
+
+-  Usage based software licensing for end-user consumers and NCSPs
+
+Audience
+^^^^^^^^^^^^
+
+The industry transformation associated with softwarization [1]_ results
+in a number of changes in traditional approaches for industry
+collaboration. Changes from hardware to software, from waterfall to
+agile processes and the emergence of industry supported open source
+communities imply corresponding changes in processes at many industry
+collaboration bodies. With limited operational experience and much more
+dynamic requirements, open source communities are expected to evolve
+these VNF/PNF guidelines further before final documentation of those aspects
+necessary for standardization. This document and accompanying refer documents
+provides VNF/PNF providers, NCSPs and other interested 3rd parties a set of
+guidelines and requirements for the design, build and overall lifecycle
+management of VNFs.
+
+**VNF/PNF Providers**
+
+PNF suppliers and those transitioning from providing physical network functions
+to providing VNFs as well as new market entrants should find
+these VNF/PNF requirements and guidelines a useful introduction to the
+requirements to be able to develop VNFs/PNFs for deployment into a Network
+Cloud. VNF/PNF Providers may also be interested to test their VNFs/PNFs in the
+context of an open source implementation of the environment.
+
+**Network Cloud Service Providers (NCSPs)**
+
+A NCSP provides services based on Network Cloud infrastructure as well
+as services above the infrastructure layer, e.g., platform service,
+end-to-end services.
+
+Common approaches to packaging of VNFs enable economies of scale in
+their development. As suitable infrastructure becomes deployed, NCSPs
+have a common interest in guidelines that support the ease of deployment
+of VNFs in each other's Network Cloud. After reading these VNF
+guidelines, NCSPs should be motivated to join ONAP in evolving these
+guidelines to meet the industry's collective needs.
+
+**Other interested parties**
+
+Other parties such as solution providers, open source community,
+industry standard bodies, students and researchers of network
+technologies, as well as enterprise customers may also be interested in
+the VNF/PNF Guidelines. Solution Providers focused on specific industry
+verticals may find these VNF/PNF guidelines useful in the development of
+specialized VNFs/PNFs that can better address the needs of their industry
+through deployment of these VNFs/PNFs in NCSP infrastructure. Open Source
+developers can use these VNF/PNF guidelines to facilitate the automation of
+VNF ingestion and deployment. The emergence of a market for VNFs enables
+NCSPs to more rapidly deliver increased functionality, for execution on
+white box hardware on customer's premises – such functionality may be of
+particular interest to enterprises supporting similar infrastructure.
+
+Program and Document Structure
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This document is part of a hierarchy of documents that describes the
+overall Requirements and Guidelines for ONAP. The diagram below
+identifies where this document fits in the hierarchy.
+
++-------------------------------------------------------------------------+
+| ONAP Requirements and Guidelines                                        |
++=======================+=================================================+
+| VNF/PNF Guidelines    | Future ONAP Subject Documents                   |
++-----------------------+-------------------------+-----------------------+
+| VNF/PNF Requirements  | Future VNF/PNF          | Future Requirements   |
+|                       | Requirements Documents  | Documents             |
++-----------------------+-------------------------+-----------------------+
+
+Document summary:
+
+**VNF/PNF Guidelines**
+
+-  Describes VNF/PNF environment and overview of requirements
+
+*VNF Requirements*
+
+-  VNF development readiness requirements (Design, Resiliency, Security,
+   and DevOps)
+
+-  Requirements for how VNFs interact and utilize ONAP
+
+-  Provides recommendations and standards for building Heat templates
+   compatible with ONAP.
+
+-  Provides recommendations and standards for building TOSCA templates
+   compatible with ONAP.
+
+
+Acronyms and Definitions
+^^^^^^^^^^^^^^^^^^^^^^^^^
+Refer to Appendix A - Glossary
+
+
+**VNF Context**
+----------------------------------------
+
+A technology trend towards softwarization is impacting the
+communications industry as it has already impacted a number of other
+industries. This trend is expected to have some significant impacts on
+the products and processes of this industry. The transformation from
+products primarily based on hardware to products primarily based on
+software has a number of impacts. The completeness of the software
+packages to ease integration, usage based licensing to reflect scaling
+properties, independence from hardware and location and software
+resilience in the presence of underlying hardware failure all gain in
+importance compared to prior solutions. The processes supporting
+software products and services are also expected to transform from
+traditional waterfall methodologies to agile methods. In agile
+processes, characteristics such as versioned APIs, rolling upgrades,
+automated testing and deployment support with incremental release
+schedules become important for these software products and services.
+Industry process related to software products and services also change
+with the rise of industrially supported open source communities.
+Engagement with these open source communities enables sharing of best
+practices and collaborative development of open source testing and
+integration regimes, open source APIs and open source code bases.
+
+The term VNF is inspired by the work [2]_ of the ETSI [3]_ Network
+Functions Virtualization (NFV) Industry Specification Group (ISG).
+ETSI's VNF definition includes both historically network functions, such
+as Virtual Provider Edge (VPE), Virtual Customer Edge (VCE), and Session
+Border Controller (SBC), as well as historically non-network functions
+when used to support network services, such as network-supporting web
+servers and databases. The VNF discussion in these guidelines applies to
+all types of virtualized workloads, not just network appliance
+workloads. Having a consistent approach to virtualizing any workload
+provides more industry value than just virtualizing some workloads. [4]_
+
+VNFs are functions that are implemented in Network Clouds. Network
+Clouds must support end-to-end high-bandwidth low latency network flows
+through VNFs running in virtualization environments. For example, a
+Network Cloud is able to provide a firewall service to be created such
+that all Internet traffic to a customer premise passes through a virtual
+firewall running in the Network Cloud.
+
+A data center may be the most common target for a virtualization
+environment, but it is not the only target. Virtualization environments
+are also supported by more constrained resources e.g., Enterprise
+Customer Premise Equipment (CPE). Virtualization environments are also
+expected to be available at more distributed network locations by
+architecting central offices as data centers, or virtualizing functions
+located at the edge of the operator infrastructure (e.g., virtualized
+Optical Line Termination (vOLT) or xRAN [5]_) and in constrained
+resource Access Nodes. Expect detailed requirements to evolve with these
+additional virtualization environments. Some VNFs may scale across all
+these environments, but all VNFs should onboard through the same process
+before deployment to the targeted virtualization environment.
+
+Business Process Impacts
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Business process changes need to occur in order to realize full benefits
+of VNF characteristics: efficiency via automation, open source reliance,
+and improved cycle time through careful design.
+
+**Efficiency via Automation**
+
+reliant on human labor for critical operational tasks don't scale. By
+aggressively automating all VNF operational procedures, VNFs have lower
+operational cost, are more rapidly deployed at scale and are more
+consistent in their operation. ONAP provides the automation
+framework which VNFs can take advantage of simply by implementing
+ONAP compatible interfaces and lifecycle models. This enables
+automation which drives operational efficiencies and delivers the
+corresponding benefits.
+
+**Open Source**
+
+VNFs are expected to run on infrastructure largely enabled by open
+source software. For example, OpenStack [6]_ is often used to provide
+the virtualized compute, network, and storage capabilities used to host
+VNFs. OpenDaylight (ODL) [7]_ can provide the network control plane. The
+OPNFV community [8]_ provides a reference platform through integration
+of ODL, OpenStack and other relevant open source projects. VNFs also run
+in open source operating systems like Linux. VNFs might also utilize
+open source software libraries to take advantage of required common but
+critical software capabilities where community support is available.
+Automation becomes easier, overall costs go down and time to market can
+decrease when VNFs can be developed and tested in an open source
+reference platform environment prior to on-boarding by the NCSP. All of
+these points contribute to a lower cost structure for both VNF providers
+and NCSPs.
+
+**Improved Cycle Time through Careful Design**
+
+Today's fast paced world requires businesses to evolve rapidly in order
+to stay relevant and competitive. To a large degree VNFs, when used with
+the same control, orchestration, management and policy framework (e.g.,
+ONAP), will improve service development and composition. VNFs
+should enable NCSPs to exploit recursive nesting of VNFs to acquire VNFs
+at the smallest appropriate granularity so that new VNFs and network
+services can be composed. The ETSI NFV Framework [9]_ envisages such
+recursive assembly of VNFs, but many current implementations fail to
+support such features. Designing for VNF reuse often requires that
+traditional appliance based PNFs be refactored into multiple individual
+VNFs where each does one thing particularly well. While the original
+appliance based PNF can be replicated virtually by the right combination
+and organization of lower level VNFs, the real advantage comes in
+creating new services composed of different combinations of lower level
+VNFs (possibly from many providers) organized in new ways. Easier and
+faster service creation often generates real value for businesses. As
+softwarization trends progress towards more agile processes, VNFs,
+ONAP and Network Clouds are all expected to evolve towards
+continuous integration, testing and deployment of small incremental
+changes to de-risk the upgrade process.
+
+ETSI Network Function Virtualization (NFV) comparison
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+ETSI defines a VNF as an implementation of a network function that can
+be deployed on a Network Function Virtualization Infrastructure (NFVI).
+Service instances may be composed of an assembly of VNFs. In turn, a VNF
+may also be assembled from VNF components (VNFCs) that each provide a
+reusable set of functionality. VNFs are expected to take advantage of
+platform provided common services.
+
+VNF management and control under ONAP is different but remain compatible
+with the management and control exposed in the ETSI MANO model. With ONAP,
+there are two ways to manage and control VNF. One is asking all VNF providers
+to take advantage of and interoperate with common control software, as
+loop indicates by the black arrows in figure 1. At the same time a
+management and control architectural option exists for preserving legacy
+systems, e.g., ETSI MANO compatible VNFs can be controlled by third-party or
+specific VNF Managers(VNFMs) and Element Management Systems (EMSs) provided
+outside ONAP,as the loop indicates by the red arrows in figure 1.
+The ONAP is being made available as an open source project to reduce
+friction for VNF providers and enable new network functions to get to
+market faster and with lower costs.
+
+
+**Figure 1** shows a simplified ONAP and Infrastructure view to
+highlight how individual Virtual Network Functions plug into the
+ONAP control loops.
+
+|image0|
+
+\ **Figure 1. Control Loop**
+
+In the control loop view in **Figure 1**, the VNF provides an event
+data stream via an API to Data Collection, Analytics and Events (DCAE).
+DCAE analyzes and aggregates the data stream and when particular
+conditions are detected, uses policy to enable what, if any, action
+should be triggered. Some of the triggered actions may require a
+controller to make changes to the VNF through a VNF provided API.
+
+For a detailed comparison between ETSI NFV and ONAP, refer to
+Appendix C - Comparison between VNF Guidelines and ETSI GS NFV-SWA 001.
+
+
+Evolving towards VNFs
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In order to deploy VNFs, a target virtualization environment must
+already be in place. The NCSPs scale necessitates a phased rollout of
+virtualization infrastructure and then of VNFs upon that infrastructure.
+Some VNF use cases may require greenfield infrastructure deployments,
+others may start brownfield deployments in centralized data centers and
+then scale deployment more widely as infrastructure becomes available.
+Some service providers have been very public and proactive in setting
+transformation targets associated with VNFs.
+
+Because of the complexity of migration and integration issues, the
+requirements for VNFs in the short term may need to be contextualized to
+the specific service and transition planning.
+
+Much of the existing VNF work has been based on corresponding network
+function definitions and requirements developed for PNFs. Many of the
+assumptions about PNFs do not apply to VNFs and the modularity of the
+functionality is expected to be significantly different. In addition,
+the increased service velocity objectives of NFV are based on new types
+of VNFs being developed to support new services being deployed in
+virtualized environments. Much of the functionality associated with 5G
+(e.g., IoT, augmented reality/virtual reality) is thus expected to be
+deployed as VNFs in targeted virtualization infrastructure towards the
+edge of the network.
+
+**VNF Characteristics**
+-------------------------------------------------------
+
+VNFs need to be constructed using a distributed systems architecture
+that we will call "Network Cloud Ready". They need to interact with the
+orchestration and control platform provided by ONAP and address the
+new security challenges that come in this environment.
+
+The main goal of a Network Cloud Ready VNF is to run 'well' on any
+Network Cloud (public or private) over any network (carrier or
+enterprise). In addition, for optimal performance and efficiency, VNFs
+will be designed to take advantage of Network Clouds. This requires
+careful engineering in both VNFs and candidate Network Cloud computing
+frameworks.
+
+To ensure Network Cloud capabilities are leveraged and VNF resource
+consumption meets engineering and economic targets, VNF performance and
+efficiency will be benchmarked in a controlled lab environment. In line
+with the principles and practices laid out in ETSI GS NFV-PER 001,
+efficiency testing will consist of benchmarking VNF performance with a
+reference workload and associated performance metrics on a reference
+Network Cloud (or, when appropriate, additional benchmarking on a bare
+metal reference platform).
+
+Network Cloud Ready VNF characteristics and design consideration can be
+grouped into three areas:
+
+-  VNF Development
+
+-  ONAP Ready
+
+-  Virtualization Environment Ready
+
+Detailed requirements are contained in the reference documents that are
+listed in Appendix B - References.
+
+VNF Development
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+VNFs should be designed to operate within a cloud environment from the
+first stages of the development. The VNF provider should think clearly
+about how the VNF should be decomposed into various modules. Resiliency
+within a cloud environment is very different than in a physical
+environment and the developer should give early thought as to how the
+Network Cloud Service Provider will ensure the level of resiliency
+required by the VNF and then provide the capabilities needed within that
+VNF. Scaling and Security should also be well thought out at design time
+so that the VNF runs well in a virtualized environment. Finally, the VNF
+Provider also needs to think about how they will integrate and deploy
+new versions of the VNF. Since the cloud environment is very dynamic,
+the developer should utilize DevOps practices to deploy new software.
+
+Detailed requirements for VNF Development can be found in the
+*VNF Requirements* document.
+
+VNF Design
+~~~~~~~~~~
+
+A VNF may be a large construct and therefore when designing it, it is
+important to think about the components from which it will be composed.
+The ETSI SWA 001 document gives a good overview of the architecture of a
+VNF in Chapter 4 as well as some good examples of how to compose a VNF
+in its Annex B. When laying out the components of the VNF it is
+important to keep in mind the following principles: Single Capability,
+Independence, State and the APIs.
+
+Many Network Clouds will use Heat and TOSCA to describe orchestration
+templates for instantiating VNFs and VNFCs. Heat and TOSCA has a useful
+abstraction called a "module" that can contain one or more VNFCs. A
+module can be thought of as a deployment unit. In general the goal should
+be for each module to contain a single VNFC.
+
+Single Capability
++++++++++++++++++++
+
+VNFs should be carefully decomposed into loosely coupled, granular,
+re-usable VNFCs that can be distributed and scaled on a Network Cloud.
+VNFCs should be responsible for a single capability.
+
+The Network Cloud will define several flavors of VMs for a VNF designer
+to choose from for instantiating a VNFC. The best practice is to keep
+the VNFCs as lightweight as possible while still fulfilling the business
+requirements for the "single capability", however the VNFC should not be
+so small that the overhead of constructing, maintaining, and operating
+the service outweighs its utility.
+
+Independence
++++++++++++++++
+
+VNFCs should be independently deployed, configured, upgraded, scaled,
+monitored, and administered (by ONAP). The VNFC must be a
+standalone executable process.
+
+API versioning is one of the biggest enablers of independence. To be
+able to independently evolve a component, versioning must ensure
+existing clients of the component are not forced to flash-cut with each
+interface change. API versioning enables smoother evolution while
+preserving backward compatibility.
+
+Scaling
++++++++++++
+
+Each VNFC within a VNF must support independent horizontal scaling, by
+adding/removing instances, in response to demand loads on that VNFC. The
+Network Cloud is not expected to support adding/removing resources
+(compute, memory, storage) to an existing instance of a VNFC (vertical
+scaling). A VNF should be designed such that its components can scale
+independently of each other. Scaling one component should not require
+another component to be scaled at the same time. All scaling will be
+controlled by ONAP.
+
+Managing State
+++++++++++++++++++++++++
+
+VNFCs and their interfaces should isolate and manage state to allow for
+high-reliability, scalability, and performance in a Network Cloud
+environment. The use of state should be minimized as much as possible to
+facilitate the movement of traffic from one instance of a VNFC to
+another. Where state is required it should be maintained in a
+geographically redundant data store that may in fact be its own VNFC.
+
+This concept of decoupling state data can be extended to all persistent
+data. Persistent data should be held in a loosely coupled database.
+These decoupled databases need to be engineered and placed correctly to
+still meet all the performance and resiliency requirements of the
+service.
+
+Lightweight and Open APIs
+++++++++++++++++++++++++++++++++++++++++++++++++
+
+Key functions are accessible via open APIs, which align to Industry API
+Standards and supported by an open and extensible information/data
+model.
+
+Reusability
+++++++++++++++++++++++++
+
+Properly (de)composing a VNF requires thinking about "reusability".
+Components should be designed to be reusable within the VNF as well as
+by other VNFs. The "single capability" principle aids in this
+requirement. If a VNFC could be reusable by other VNFs then it should be
+designed as its own single component VNF that may then be chained with
+other VNFs. Likewise, a VNF provider should make use of other common
+platform VNFs such as firewalls and load balancers, instead of building
+their own.
+
+Resiliency
+~~~~~~~~~~
+
+The VNF is responsible for meeting its resiliency goals and must factor
+in expected availability of the targeted virtualization environment.
+This is likely to be much lower than found in a traditional data center.
+The VNF developer should design the function in such a way that if there
+is a platform problem the VNF will continue working as needed and meet
+the SLAs of that function. VNFs should be designed to survive single
+failure platform problems including: hypervisor, server, datacenter
+outages, etc. There will also be significant planned downtime for the
+Network Cloud as the infrastructure goes through hardware and software
+upgrades. The VNF should support tools for gracefully meeting the
+service needs such as methods for migrating traffic between instances
+and draining traffic from an instance. The VNF needs to rapidly respond
+to the changing conditions of the underlying infrastructure.
+
+VNF resiliency can typically be met through redundancy often supported
+by distributed systems architectures. This is another reason for
+favoring smaller VNFCs. By having more instances of smaller VNFCs it is
+possible to spread the instance out across servers, racks, datacenters,
+and geographic regions. This level of redundancy can mitigate most
+failure scenarios and has the potential to provide a service with even
+greater availability than the old model. Careful consideration of VNFC
+modularity also minimizes the impact of failures when an instance does
+fail.
+
+Security
+~~~~~~~~
+
+Security must be integral to the VNF through its design, development,
+instantiation, operation, and retirement phases. VNF architectures
+deliver new security capabilities that make it easier to maximize
+responsiveness during a cyber-attack and minimize service interruption
+to the customers. SDN enables the environment to expand and adapt for
+additional traffic and incorporation of security solutions. Further,
+additional requirements will exist to support new security capabilities
+as well as provide checks during the development and production stages
+to assure the expected advantages are present and compensating controls
+exist to mitigate new risks.
+
+New security requirements will evolve along with the new architecture.
+Initially, these requirements will fall into the following categories:
+
+-  VNF General Security Requirements
+
+-  VNF Identity and Access Management Requirements
+
+-  VNF API Security Requirements
+
+-  VNF Security Analytics Requirements
+
+-  VNF Data Protection Requirements
+
+DevOps
+~~~~~~
+
+The ONAP software development and deployment methodology is
+evolving toward a DevOps model. VNF development and deployment should
+evolve in the same direction, enabling agile delivering of end-to-end
+services.
+
+Testing
+++++++++++++++++++++++++
+
+VNF packages should provide comprehensive automated regression,
+performance and reliability testing with VNFs based on open industry
+standard testing tools and methodologies. VNF packages should provide
+acceptance and diagnostic tests and in-service instrumentation to be
+used in production to validate VNF operation.
+
+Build and Deployment Processes
+++++++++++++++++++++++++++++++++++++++++++++++++
+
+VNF packages should include continuous integration and continuous
+deployment (CI/CD) software artifacts that utilize automated open
+industry standard system and container build tools. The VNF package
+should include parameterized configuration variables to enable automated
+build customization. Don't create unique (snowflake) VNFs requiring any
+manual work or human attention to deploy. Do create standardized (Lego™)
+VNFs that can be deployed in a fully automated way.
+
+ONAP will orchestrate updates and upgrades of VNFs. One method for updates
+and upgrades is to onboard and validate the new version, then build a new
+instance with the new version of software,transfer traffic to that instance
+and kill the old instance. There should be no need for the VNF or its
+components to provide an update/upgrade mechanism.
+
+Automation
+++++++++++++++++++++++++
+
+Increased automation is enabled by VNFs and VNF design and composition.
+VNF and VNFCs should provide the following automation capabilities, as
+triggered or managed via ONAP:
+
+-  Events and alarms
+
+-  Lifecycle events
+
+-  Zero-Touch rolling upgrades and downgrades
+
+-  Configuration
+
+ONAP Ready
+^^^^^^^^^^^^^^^^^^^^^^
+
+ONAP is the "brain" providing the lifecycle management and control
+of software-centric network resources, infrastructure and services.
+ONAP is critical in achieving the objectives to increase the value
+of the Network Cloud to customers by rapidly on-boarding new services,
+enabling the creation of a new ecosystem of consumer and enterprise
+services, reducing capital and operational expenditures, and providing
+operations efficiencies. It delivers enhanced customer experience by
+allowing them in near real-time to reconfigure their network, services,
+and capacity.
+
+One of the main ONAP responsibilities is to rapidly onboard and
+enrich VNFs to be cataloged as resources to allow composition and
+deployment of services in a multi-vendor plug and play environment. It
+is also extremely important to be able to automatically manage the VNF
+run-time lifecycle to fully realize benefits of NFV. The VNF run-time
+lifecycle includes aspects such as instantiation, configuration, elastic
+scaling, automatic recovery from resource failures, and resource
+allocation. It is therefore imperative to provide VNFs that are equipped
+with well-defined capabilities that comply with ONAP standards to
+allow rapid onboarding and automatic lifecycle management of these
+resources when deploying services as depicted in **Figure 2**.
+
+|image1|
+
+\ **Figure 2. VNF Complete Lifecycle Stages**
+
+In order to realize these capabilities within the ONAP platform, it
+is important to adhere to a set of key principles (listed below) for
+VNFs to integrate into ONAP.
+
+Requirements for ONAP Ready can be found in the *VNF Requirements* document.
+
+Design Definition
+~~~~~~~~~~~~~~~~~
+
+Onboarding automation will be facilitated by applying standards-based
+approaches to VNF packaging to describe the VNF's infrastructure
+resource requirements, topology, licensing model, design constraints,
+and other dependencies to enable successful VNF deployment and
+management of VNF configuration and operational behavior.
+
+The current VNF Package Requirement is based on a subset of the
+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.
+
+Configuration Management
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+ONAP must be able to orchestrate and manage the VNF configuration
+to provide fully automated environment for rapid service provisioning
+and modification. VNF configuration/reconfiguration could be allowed
+directly through standardized APIs or through EMS and VF-C.
+
+Monitoring and Management
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The end-to-end service reliability and availability in a virtualized
+environment will greatly depend on the ability to monitor and manage the
+behavior of Virtual Network Functions in real-time. ONAP platform
+must be able to monitor the health of the network and VNFs through
+collection of event and performance data directly from network resources
+utilizing standardized APIs or through EMS. The VNF provider must provide
+visibility into VNF performance and fault at the VNFC level (VNFC is the
+smallest granularity of functionality in our architecture) to allow ONAP
+to proactively monitor, test, diagnose and trouble shoot the health and
+behavior of VNFs at their source.
+
+Virtualization Environment Ready
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Every Network Cloud Service Provider will have a different set of
+resources and capabilities for their Network Cloud, but there are some
+common resources and capabilities that nearly every NCSP will offer.
+
+Network Cloud
+~~~~~~~~~~~~~
+
+VNFCs should be agnostic to the details of the Network Cloud (such as
+hardware, host OS, Hypervisor or container technology) and must run on
+the Network Cloud with acknowledgement to the paradigm that the Network
+Cloud will continue to rapidly evolve and the underlying components of
+the platform will change regularly. VNFs should be prepared to move
+VNFCs across VMs, hosts, locations or datacenters, or Network Clouds.
+
+Overlay Network
+~~~~~~~~~~~~~~~
+
+VNFs should be compliant with the Network Cloud network virtualization
+platform including the specific set of characteristics and features.
+
+The Network Cloud is expected to be tuned to support VNF performance
+requirements. Initially, specifics may differ per Network Cloud
+implementation and are expected to evolve over time, especially as the
+technology matures.
+
+Guest Operating Systems
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+All components in ONAP should be virtualized, preferably with support for
+both virtual machines and containers. All components should be software-based
+with no requirement on a specific hardware platform.
+
+To enable the compliance with security, audit, regulatory and
+other needs, NCSPs may operate a limited set of  guest OS and
+CPU architectures and families, virtual machines, etc.
+
+VNFCs should be agnostic to the details of the Network Cloud (such as
+hardware, host OS, Hypervisor or container technology) and must run on
+the Network Cloud with acknowledgement to the paradigm that the Network
+Cloud will continue to rapidly evolve and the underlying
+components of the platform will change regularly.
+
+
+Compute Flavors
+~~~~~~~~~~~~~~~
+
+VNFs should take advantage of the standard Network Cloud capabilities in
+terms of VM characteristics (often referred to as VM Flavors), VM sizes
+and cloud acceleration capabilities aimed at VNFs such as Linux Foundation
+project Data Plane Development Kit (DPDK).
+
+**PNF Characteristics**
+----------------------------------------
+
+Physical Network Functions (PNF) are a vendor-provided Network Function(s)
+implemented using a set of software modules deployed on a dedicated
+hardware element while VNFs utilize cloud resources to provide Network
+Functions through virtualized software modules.
+
+PNFs can be supplied by a vendor as a Black Box (provides no knowledge
+of its internal characteristics, logic, and software design/architecture)
+or as a White Box (provides detailed knowledge and access of its internal
+components and logic) or as a Grey Box (provides limited knowledge and
+access to its internal components).  Also note that the PNF hardware and
+the software running on it could come from the same vendor or different
+vendors.
+
+PNFs need to be chained with VNFs to design and deploy more complex end
+to end services that span across Network Clouds. PNF should have the
+following characteristics.
+
+Cloud Integration
+^^^^^^^^^^^^^^^^^^^
+
+Although the goal is to virtualize network functions within a service
+chain, there will be certain network functions in the near term or even
+in the end state that would remain physical (e.g., 5G radio functions,
+ROADM, vOLT, AR/CR appliances etc.). PNFs must be designed to allow
+their seamless integration with Network Clouds and complement end to
+end service requirements for resiliency, scalability, upgrades, and
+security.
+
+
+PNF Design
+^^^^^^^^^^^^^^^^^^^
+
+A PNF provides one or more network functions on a dedicated hardware
+box. PNFs are expected to evolve to Virtualized Network Functions and
+their current design should facilitate their future virtualization.
+The software modules and corresponding hardware should be packaged
+together to provide the desired Network Functions. However, it is not
+required for the software modules and hardware to be provided by a
+single vendor. PNFs are deployed through Service Provider's installation
+and commission procedure. Virtualized instantiation processes flows
+such as OpenStack HHEAT are not utilized and PNFs are instantiated
+when they are powered up and connected to ONAP. PNFs must provide
+access to its software modules and management functions through
+open APIs.
+
+
+Scaling
+^^^^^^^^^^^
+
+Horizontal scaling for PNFs would not be the logical approach and they
+need to be scaled up vertically by increasing computing hardware
+resources (e.g. cpu, memory). Vertical scaling of PNFs will need to
+follow Service Provider's hardware upgrade processes and procedures.
+
+Managing State
+^^^^^^^^^^^^^^^^^
+
+Software modules and their interfaces should be able to monitor and
+manage their state to allow high-reliability, performance, and
+high-availability (active-active or stand by) as needed by overriding
+services. At this time, PNF data store should be replicated in the back
+up hardware to allow fail overs for both active-active and stand by
+high-availability methods.
+
+Resiliency
+^^^^^^^^^^^^^
+
+The PNF is responsible for meeting its resiliency goals with the use
+of redundant physical infrastructure.  The PNF developer should design
+the function in such a way that if there is a physical platform problem
+the PNF will continue working as needed and meet the SLAs of that
+function. PNFs should be designed to survive single failure platform
+problems including: processor, memory, NIC, datacenter outages, etc.
+The PNF should support tools for gracefully meeting the service needs
+such as methods for migrating traffic between PNF's and draining
+traffic from a PNF.
+
+DevOps
+^^^^^^^^
+
+The ONAP software development and deployment methodology is evolving
+toward a DevOps model. PNF development and deployment should evolve in the
+same direction, enabling agile delivering of end-to-end services.
+
+Testing
+^^^^^^^^^^^
+
+PNF packages should provide comprehensive automated regression, performance
+and reliability testing with PNFs based on open industry standard testing
+tools and methodologies. PNF packages should provide acceptance and diagnostic
+tests and in-service instrumentation to be used in production to validate
+PNF operation.
+
+Build and Deployment Processes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+PNF packages should include continuous integration and continuous deployment
+(CI/CD) software artifacts that utilize automated open industry standard
+system and container build tools. The PNF package should include
+parameterized configuration variables to enable automated build
+customization. Don't create unique (snowflake) PNFs requiring any
+manual work or human attention to deploy. Do create standardized
+(Lego™) PNFs that can be deployed in a fully automated way.
+ONAP will orchestrate updates and upgrades of PNFs. One method
+for updates and upgrades is to onboard and validate the new version,
+then build a new instance with the new version of software, transfer
+traffic to that instance and kill the old instance. There should be
+no need for the PNF or its components to provide an update/upgrade
+mechanism.
+
+Automation
+^^^^^^^^^^^^^^^^^^^
+
+Increased automation is enabled by PNFs and PNF design and composition.
+PNF should provide the following automation capabilities, as triggered
+or managed via ONAP:
+
+- Events and alarms
+- Lifecycle events
+- Zero-Touch rolling upgrades and downgrades
+- Configuration
+
+ONAP Ready
+^^^^^^^^^^^^^^^^^^^
+
+PNF and VNF lifecycles are fundamentally managed the same way utilizing
+ONAP onboarding, configuration, and monitoring capabilities. The main
+difference is related to the processes and methods used for deployment
+and instantiation of these resources. PNFs are first installed in the
+target location utilizing Service Provider's installation and commission
+procedures that includes manual activities. Next, any additional software
+module will be downloaded to the physical hardware and started utilizing
+the required APIs. On the other had VNF deployment and instantiation are
+orchestrated by ONAP utilizing the underlying Network Cloud orchestration
+and APIs.
+
+Design Definition
+^^^^^^^^^^^^^^^^^^^
+
+It is intended to onboard PNF packages into ONAP using the same processes
+and tools as VNFs to reduce the need for customization based on the Network
+Function underlying infrastructure. The main difference is associated with
+the content of the Package that describes the required information for
+lifecycle management of the Network Function. For instance, PNF packages
+will not include any information related to the Network Cloud infrastructure
+such as HEAT templates.
+
+Configuration Management
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The configuration for both PNFs and VNFs are managed utilizing common
+orchestration capabilities and standardized resource interfaces supported
+by ONAP. PNFs must allow direct configuration management interfaces to
+ONAP without any needs for an EMS support.
+
+Monitoring and Management
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+PNFs must allow ONAP to directly collect event and performance data without
+the aid of any EMSs to monitor PNF health and behavior. ONAP requires common
+standardized models and interfaces to support collection of events and data
+streams for both VNFs and PNFs and the vendors must be able to support these
+requirements.
+
+Computing Environment
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Network functions implemented over dedicated physical hardware will
+eventually be virtualized over Network Cloud infrastructure. However,
+this transition will take place over time and there is a need to support
+this integrated network functions in various forms until complete
+virtualization is achieved. The integrated solution may come in the
+form of a tightly bundled package from a single provider referred to
+as black box in this document. In this configuration, the software
+modules will not be directly managed by an external management
+system and the bundled package is managed utilizing standardized open
+APIs provided by the vendor.
+
+In an alternative configuration, the internal software modules are
+not tightly coupled with physical hardware and can be directly
+accessed, extended, and managed by an external management system
+through standardized interfaces. Each software module can be provided
+by different vendors and loaded onto the underlying hardware. This
+configuration is referred to as a white box in this document.
+
+A gray box configuration provides direct access and manageability
+only to a subset of software modules that are loaded on top of a
+basic bundled package.
+
+
+**Summary**
+---------------------------------------
+
+The intent of these guidelines and requirements is to provide long term
+vision as well as short term focus and clarity where no current open
+source implementation exists today. The goal is to accelerate the
+adoption of VNFs which will increase innovation, minimize customization
+to onboard VNFs, reduce implementation time and complexity as well as
+lower overall costs for all stakeholders. It is critical for the
+Industry to align on a set of standards and interfaces to quickly
+realize the benefits of NFV.
+
+This VNF guidelines document provides a general overview and points to
+more detailed requirements documents. The subtending documents provide
+more detailed requirements and are listed in Appendix B - References.
+All documents are expected to evolve.
+
+Some of these VNF/PNF guidelines may be more broadly applicable in the
+industry, e.g., in other open source communities or standards bodies.
+The art of VNF architecture and development is expected to mature
+rapidly with practical deployment and operations experience from a
+broader ecosystem of types of VNFs and different VNF providers.
+Individual operators may also choose to provide their own extensions and
+enhancements to support their particular operational processes, but
+these guidelines are expected to remain broadly applicable across a
+number of service providers interested in acquiring VNFs.
+
+We invite feedback on these VNF/PNF Guidelines in the context of the
+ONAP Project. We anticipate an ongoing project within the ONAP community
+to maintain similar guidance for VNF developers to ONAP.Comments on these
+guidelines should be discussed there.
+
+**Appendix**
+-----------------------------------
+
+Glossary
+^^^^^^^^^^^^^^^^^^
+
++--------------------+-------------------------------------------------------+
+| Heat               | Heat is a service to orchestrate composite cloud      |
+|                    | applications using a declarative template format      |
+|                    | through an OpenStack-native REST API.                 |
++--------------------+-------------------------------------------------------+
+| HPA                | Hardware Platform Awareness (HPA) is the means by     |
+|                    | which the underlying NFV-I hardware platform          |
+|                    | capabilities are exposed to the network service       |
+|                    | orchestration and management functionality, for the   |
+|                    | purpose of fulfilling VNF instantiation-time hardware |
+|                    | platform                                              |
++--------------------+-------------------------------------------------------+
+| NC                 | Network Cloud (NC) are built on a framework containing|
+|                    | these essential elements: refactoring hardware        |
+|                    | elements into software functions running on commodity |
+|                    | cloud computing infrastructure; aligning access, core,|
+|                    | and edge networks with the traffic patterns created by|
+|                    | IP based services; integrating the network and cloud  |
+|                    | technologies on a software platform that enables      |
+|                    | rapid, highly automated, deployment and management of |
+|                    | services, and software defined control so that both   |
+|                    | infrastructure and functions can be optimized across  |
+|                    | change in service demand and infrastructure           |
+|                    | availability; and increasing competencies in software |
+|                    | integration and a DevOps operations model.            |
++--------------------+-------------------------------------------------------+
+| NCSP               | Network Cloud Service Provider (NCSP) is a company or |
+|                    | organization, making use of a communications network  |
+|                    | to provide Network Cloud services on a commercial     |
+|                    | basis to third parties.                               |
++--------------------+-------------------------------------------------------+
+| NFV                | Network functions virtualization (NFV) defines        |
+|                    | standards for compute, storage, and networking        |
+|                    | resources that can be used to build virtualized       |
+|                    | network functions.                                    |
++--------------------+-------------------------------------------------------+
+| NFV-I              | NFV Infrastructure (NFVI) is a key component of the   |
+|                    | NFV architecture that describes the hardware and      |
+|                    | software components on which virtual networks are     |
+|                    | built.                                                |
++--------------------+-------------------------------------------------------+
+| PNF                | PNF is a vendor-provided Network Function(s)          |
+|                    | implemented using a bundled set of hardware and       |
+|                    | software.                                             |
++--------------------+-------------------------------------------------------+
+| SDOs               | Standards Developing Organizations are organizations  |
+|                    | which are active in the development of standards      |
+|                    | intended to address the needs of a group of affected  |
+|                    | adopters.                                             |
++--------------------+-------------------------------------------------------+
+| Softwarization     | Softwarization is the transformation of business      |
+|                    | processes to reflect characteristics of software      |
+|                    | centric products, services, lifecycles, and methods.  |
++--------------------+-------------------------------------------------------+
+| Targeted           | Targeted Virtualization Environment is the execution  |
+| Virtualization     | environment for VNFs. While Network Clouds located in |
+| Environment        | datacenters are a common execution environment, VNFs  |
+|                    | can and will be deployed in various locations (e.g.,  |
+|                    | non-datacenter environments) and form factors (e.g.,  |
+|                    | enterprise Customer Premise Equipment). Non-datacenter|
+|                    | environments are expected to be available at more     |
+|                    | distributed network locations including central       |
+|                    | offices and at the edge of the NCSP's infrastructure. |
++--------------------+-------------------------------------------------------+
+| TOSCA              | Topology and Orchestration Specification for Cloud    |
+|                    | Applications (OASIS spec)                             |
++--------------------+-------------------------------------------------------+
+| VM                 | Virtual Machine (VM) is a virtualized computation     |
+|                    | environment that behaves very much like a physical    |
+|                    | computer/server. A VM has all its ingredients         |
+|                    | (processor, memory/storage, interfaces/ports) of a    |
+|                    | physical computer/server and is generated by a        |
+|                    | hypervisor, which partitions the underlying physical  |
+|                    | resources and allocates them to VMs. Virtual Machines |
+|                    | are capable of hosting a virtual network function     |
+|                    | component (VNFC).                                     |
++--------------------+-------------------------------------------------------+
+| VNF                | Virtual Network Function (VNF) is the software        |
+|                    | implementation of a function that can be deployed on a|
+|                    | Network Cloud. It includes network functions that     |
+|                    | provide transport and forwarding. It also includes    |
+|                    | other functions when used to support network services,|
+|                    | such as network-supporting web servers and database.  |
++--------------------+-------------------------------------------------------+
+| VNFC               | Virtual Network Function Component (VNFC) are the     |
+|                    | sub-components of a VNF providing a VNF Provider a    |
+|                    | defined sub-set of that VNF's functionality, with the |
+|                    | main characteristic that a single instance of this    |
+|                    | component maps 1:1 against a single Virtualization    |
+|                    | Container. See Figure 3 for the relationship between  |
+|                    | VNFC and VNFs.                                        |
+|                    |                                                       |
+|                    | |image2|                                              |
++--------------------+-------------------------------------------------------+
+
+
+References
+^^^^^^^^^^^^^
+
+1. VNF Requirements
+
+Comparison between VNF Guidelines and ETSI GS NFV-SWA 001
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+
+The VNF guidelines presented in this document (VNF Guidelines) overlap
+with the ETSI GS NFV-SWA 001 (Network Functions Virtualization (NFV);
+Virtual Network Function Architecture) document. For convenience we will
+just refer to this document as SWA 001.
+
+The SWA 001 document is a survey of the landscape for architecting a
+VNF. It includes many different options for building a VNF that take
+advantage of the ETSI MANO architecture.
+
+The Network Cloud and ONAP have similarities to ETSI's MANO, but
+also have differences described in earlier sections. The result is
+differences in the VNF requirements. Since these VNF Guidelines are for
+a specific implementation of an architecture they are narrower in scope
+than what is specified in the SWA 001 document.
+
+The VNF Guidelines primarily overlaps the SWA 001 in Sections 4 and 5.
+The other sections of the SWA 001 document lie outside the scope of the
+VNF Guidelines.
+
+This appendix will describe the differences between these two documents
+indexed on the SWA 001 sections.
+
+Section 4 Overview of VNF in the NFV Architecture
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This section provides an overview of the ETSI NFVI architecture and how
+it interfaces with the VNF architecture. Because of the differences
+between infrastructure architectures there will naturally be some
+differences in how it interfaces with the VNF.
+
+A high level view of the differences in architecture can be found in the
+main body of this document.
+
+Section 5 VNF Design Patterns and Properties
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This section of the SWA 001 document gives a broad view of all the
+possible design patterns of VNFs. The VNF Guidelines do not generally
+differ from this section. The VNF Guidelines address a more specific
+scope than what is allowed in the SWA 001 document.
+
+Section 5.1 VNF Design Patterns
++++++++++++++++++++++++++++++++++++++++
+
+The following are differences between the VNF Guidelines and SWA-001:
+
+-  5.1.2 - The Network Cloud does not recognize the distinction between
+   "parallelizable" and "non-parallelizable" VNFCs, where parallelizable
+   means that there can be multiple instances of the VNFC. In the VNF
+   Guidelines, all VNFCs should support multiple instances and therefore
+   be parallelizable.
+
+-  5.1.3 - The VNF Guidelines encourages the use of stateless VNFCs.
+   However, where state is needed it should be kept external to the VNFC
+   to enable easier failover.
+
+-  5.1.5 - The VNF Guidelines only accepts horizontal scaling (scale
+   out/in) by VNFC. Vertical scaling (scale up/down) is not supported by
+   ONAP.
+
+Section 5.2 VNF Update and Upgrade
++++++++++++++++++++++++++++++++++++++++
+
+-  5.2.2 - ONAP will orchestrate updates and upgrades. The
+   preferred method for updates and upgrades is to build a new instance
+   with the new version of software, transfer traffic to that instance
+   and kill the old instance.
+
+Section 5.3 VNF Properties
++++++++++++++++++++++++++++++++++++++++
+
+The following are differences between the VNF Guidelines and SWA-001:
+
+-  5.3.1 - In a Network Cloud all VNFs must be only "COTS-Ready". The
+   VNF Guidelines does not support "Partly COTS-READY" or "Hardware
+   Dependent".
+
+-  5.3.2 – The only virtualization environment currently supported by
+   ONAP is "Virtual Machines". The VNF Guidelines state that all
+   VNFs should be hypervisor agnostic. Other virtualized environment
+   options such as containers are not currently supported. However,
+   container technology is targeted to be supported in the future.
+
+-  5.3.3 - All VNFs must scale horizontally (scale out/in) within the
+   Network Cloud. Vertical (scale up/down) is not supported.
+
+-  5.3.5 - The VNF Guidelines state that ONAP will provide full
+   policy management for all VNFs. The VNF will not provide its own
+   policy management for provisioning and management.
+
+-  5.3.7 - The VNF Guidelines recognizes both stateless and stateful
+   VNFCs but it encourages the minimization of stateful VNFCs.
+
+Section 5.4 Attributes describing VNF Requirements
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+Attributes described in the VNF Guidelines and reference documents
+include those attributes defined in this section of the SWA 001 document
+but also include additional attributes.
+
+
+
+.. [1]
+   Softwarization is the transformation of business processes to reflect
+   characteristics of software centric products, services, lifecycles
+   and methods.
+
+.. [2]
+   "Virtual Network Functions Architecture" ETSI GS NFV-SWA 001 v1.1.1
+   (Dec 2012)
+
+.. [3]
+   European Telecommunications Standards Institute or `ETSI
+   <http://www.etsi.org>`_ is a respected standards body providing
+   standards for information and communications technologies.
+
+.. [4]
+   Full set of capabilities of Network Cloud and/or ONAP might not
+   be needed to support traditional IT like workloads.
+
+.. [5]
+   `xRAN <http://www.xran.org/>`_
+
+.. [6]
+   `OpenStack <http://www.openstack.org>`_
+
+.. [7]
+   `OpenDaylight <http://www.opendaylight.org>`_
+
+.. [8]
+   `OPNFV <http://www.opnfv.org>`_
+
+.. [9]
+   See, e.g., Figure 3 of GS NFV 002, Architectural Framework
+
+.. |image0| image:: ONAP_VNF_Control_Loop.jpg
+   :width: 6.56250in
+   :height: 3.69167in
+.. |image1| image:: VNF_Lifecycle.jpg
+   :width: 6.49000in
+   :height: 2.23000in
+.. |image2| image:: VNF_VNFC_Relation.jpg
+   :width: 4.26087in
+   :height: 3.42514in