diff options
Diffstat (limited to 'docs/vnf_guidelines')
| -rw-r--r-- | docs/vnf_guidelines/ONAP_VNF_Control_Loop.jpg | bin | 51913 -> 0 bytes | |||
| -rw-r--r-- | docs/vnf_guidelines/VNF_Lifecycle.jpg | bin | 16839 -> 0 bytes | |||
| -rw-r--r-- | docs/vnf_guidelines/VNF_VNFC_Relation.jpg | bin | 454310 -> 0 bytes | |||
| -rw-r--r-- | docs/vnf_guidelines/index.rst | 25 | ||||
| -rw-r--r-- | docs/vnf_guidelines/vnf_guidelines.rst | 1223 |
5 files changed, 0 insertions, 1248 deletions
diff --git a/docs/vnf_guidelines/ONAP_VNF_Control_Loop.jpg b/docs/vnf_guidelines/ONAP_VNF_Control_Loop.jpg Binary files differdeleted file mode 100644 index bc2d101..0000000 --- a/docs/vnf_guidelines/ONAP_VNF_Control_Loop.jpg +++ /dev/null diff --git a/docs/vnf_guidelines/VNF_Lifecycle.jpg b/docs/vnf_guidelines/VNF_Lifecycle.jpg Binary files differdeleted file mode 100644 index 45419e6..0000000 --- a/docs/vnf_guidelines/VNF_Lifecycle.jpg +++ /dev/null diff --git a/docs/vnf_guidelines/VNF_VNFC_Relation.jpg b/docs/vnf_guidelines/VNF_VNFC_Relation.jpg Binary files differdeleted file mode 100644 index 0457e86..0000000 --- a/docs/vnf_guidelines/VNF_VNFC_Relation.jpg +++ /dev/null diff --git a/docs/vnf_guidelines/index.rst b/docs/vnf_guidelines/index.rst deleted file mode 100644 index 26246d3..0000000 --- a/docs/vnf_guidelines/index.rst +++ /dev/null @@ -1,25 +0,0 @@ -.. 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. - - -VNF Guidelines -============== - -.. toctree:: - :titlesonly: - :maxdepth: 2 - :numbered: - - vnf_guidelines - diff --git a/docs/vnf_guidelines/vnf_guidelines.rst b/docs/vnf_guidelines/vnf_guidelines.rst deleted file mode 100644 index 3394fc6..0000000 --- a/docs/vnf_guidelines/vnf_guidelines.rst +++ /dev/null @@ -1,1223 +0,0 @@ -.. 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:: - :depth: 3 -.. - -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 |
