diff options
Diffstat (limited to 'docs/vnf_guidelines.rst')
| -rw-r--r-- | docs/vnf_guidelines.rst | 1224 |
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 |