diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/vnf_guidelines/vnf_guidelines.rst | 157 |
1 files changed, 80 insertions, 77 deletions
diff --git a/docs/vnf_guidelines/vnf_guidelines.rst b/docs/vnf_guidelines/vnf_guidelines.rst index 061be00..4c20f76 100644 --- a/docs/vnf_guidelines/vnf_guidelines.rst +++ b/docs/vnf_guidelines/vnf_guidelines.rst @@ -5,9 +5,16 @@ **1. Purpose** ============== +- This document focuses on setting and evolving VNF standards that will facilitate industry discussion, participation, alignment and evolution towards comprehensive and actionable VNF best practices and standard interface. +- The goal is to accelerate adoption of VNF best practices which will increase innovation, minimize customization needed to onboard VNFs as well as reduce implementation complexity, time and cost for all impacted stakeholders. +- The intent is do drive harmonization of VNFs across VNF 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. **2. Scope** ============ +- The audience for this document are VNF providers, NCSPs and other interested 3rd parties who need to know the design, build and lifecycle management requirements for VNFs to be compliant with ONAP. +- These guidelines describes VNF environment and provides an overview of what the VNF developer needs to know to operate and be compliant with ONAP. +- These guidelines are applicable to the Amsterdam release of ONAP. +- Scope of the ONAP versions/release and future functionality **3. Introduction** =================== @@ -83,9 +90,8 @@ 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 AT&T in evolving these -guidelines in the OpenECOMP open source community to meet the industry’s -collective needs. +guidelines, NCSPs should be motivated to join ONAP in evolving these +guidelines to meet the industry’s collective needs. **Other interested parties** @@ -106,20 +112,20 @@ c. Program and Document Structure --------------------------------- This document is part of a hierarchy of documents that describes the -overall Requirements and Guidelines for OpenECOMP. The diagram below +overall Requirements and Guidelines for ONAP. The diagram below identifies where this document fits in the hierarchy. -+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| OpenECOMP Requirements and Guidelines | -+===============================================================================================================================================================================================================+ -| VNF Guidelines for Network Cloud and OpenECOMP | Future OpenECOMP Subject Documents | -+------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+ -| VNF Cloud Readiness Requirements for OpenECOMP | VNF Management Requirements for OpenECOMP | VNF Heat Template Requirements for OpenECOMP | Future,VNF Requirements Documents | Future Requirements Documents | -+------------------------------------------------+-------------------------------------------+----------------------------------------------+-----------------------------------+-------------------------------+ ++----------------------------------------------------------------------------------------------+ +| ONAP Requirements and Guidelines | ++==============================================================================================+ +| VNF Guidelines | Future ONAP Subject Documents | ++-------------------+-------------------------------------+------------------------------------+ +| VNF Requirements | Future VNF Requirements Documents | Future Requirements Documents | ++-------------------+-------------------------------------+------------------------------------+ Document summary: -**VNF Guidelines ONAP** +**VNF Guidelines** - Describes VNF environment and overview of requirements @@ -128,7 +134,7 @@ Document summary: - VNF development readiness requirements (Design, Resiliency, Security, and DevOps) -- Requirements for how VNFs interact and utilize OpenECOMP +- Requirements for how VNFs interact and utilize ONAP - Provides recommendations and standards for building Heat templates compatible with ONAP. @@ -203,9 +209,9 @@ and improved cycle time through careful design. 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. OpenECOMP provides the automation +consistent in their operation. ONAP provides the automation framework which VNFs can take advantage of simply by implementing -OpenECOMP compatible interfaces and lifecycle models. This enables +ONAP compatible interfaces and lifecycle models. This enables automation which drives operational efficiencies and delivers the corresponding benefits. @@ -231,7 +237,7 @@ and NCSPs. 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., -OpenECOMP), will improve service development and composition. VNFs +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 @@ -245,7 +251,7 @@ 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, -OpenECOMP and Network Clouds are all expected to evolve towards +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. @@ -259,32 +265,32 @@ 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 OpenECOMP is different than management -and control exposed in the ETSI MANO model. With OpenECOMP, there is +VNF management and control under ONAP is different than management +and control exposed in the ETSI MANO model. With ONAP, there is only a single management and control plane. In ETSI’s Framework [10]_, architectural options exist for preserving legacy systems that increase integration costs e.g., different VNFs can be controlled by VNF Managers (VNFMs) and Element Management Systems (EMSs) provided by different -software providers. OpenECOMP addresses the concern that multiple VNFMs +software providers. ONAP addresses the concern that multiple VNFMs in this space will hinder VNF reuse and increase VNF and service integration costs. Asking all VNF providers to take advantage of and interoperate with common control software mitigates related reuse and integration challenges. The common, SDN based, control platform -(OpenECOMP) is being made available as an open source project to reduce +(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. -Also under OpenECOMP, VNF providers do not provide their own proprietary -VNF Managers (VNFM) or Element Management Systems (EMS). Those -capabilities are provided by OpenECOMP. Hence, VNFs are required to -consume open interfaces to OpenECOMP in support of management and -control. The VNF Package must include the appropriate data models for -integration with OpenECOMP to enable management and control of the -VNFCs. -**Figure 1** shows a simplified OpenECOMP and Infrastructure view to + + + + + + + +**Figure 1** shows a simplified ONAP and Infrastructure view to highlight how individual Virtual Network Functions plug into the -OpenECOMP control loops. +ONAP control loops. |image0| @@ -297,7 +303,7 @@ 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 OpenECOMP, refer to +For a detailed comparison between ETSI NFV and ONAP, refer to Appendix C - Comparison between VNF Guidelines and ETSI GS NFV-SWA 001. @@ -333,7 +339,7 @@ edge of the network. 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 OpenECOMP and address 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 @@ -355,9 +361,9 @@ metal reference platform). Network Cloud Ready VNF characteristics and design consideration can be grouped into three areas: -- Cloud Readiness +- VNF Development -- OpenECOMP Ready +- ONAP Ready - Virtualization Environment Ready @@ -380,8 +386,8 @@ 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. -Requirements for Cloud Readiness can be found in the *VNF Common -Requirements for OpenECOMP* document. +Detailed requirements for VNF Development can be found in the *VNF Requirements* +document. VNF Design ~~~~~~~~~~ @@ -394,11 +400,11 @@ 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 to describe orchestration templates -for instantiating VNFs and VNFCs. Heat 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. +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 ^^^^^^^^^^^^^^^^^ @@ -418,7 +424,7 @@ Independence ^^^^^^^^^^^^ VNFCs should be independently deployed, configured, upgraded, scaled, -monitored, and administered (by OpenECOMP). The VNFC must be a +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 @@ -437,7 +443,7 @@ Network Cloud is not expected to support adding/removing resources 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 OpenECOMP. +controlled by ONAP. Managing State ^^^^^^^^^^^^^^ @@ -531,10 +537,10 @@ Initially, these requirements will fall into the following categories: DevOps ~~~~~~ -The OpenECOMP software development and deployment methodology is +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. Following these same principles better positions OpenECOMP and +services. Following these same principles better positions ONAP and VNF development to coevolve in the same direction. Testing @@ -557,7 +563,7 @@ 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. -OpenECOMP will orchestrate updates and upgrades of VNFs. The target +ONAP will orchestrate updates and upgrades of VNFs. The target 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 @@ -569,7 +575,7 @@ 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 OpenECOMP: +triggered or managed via ONAP: - Events and alarms @@ -582,9 +588,9 @@ triggered or managed via OpenECOMP: b. ONAP Ready --------------- -OpenECOMP is the “brain” providing the lifecycle management and control +ONAP is the “brain” providing the lifecycle management and control of software-centric network resources, infrastructure and services. -OpenECOMP is critical in achieving the objectives to increase the value +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 @@ -595,7 +601,7 @@ and capacity. For more details, refer to the `ECOMP Architecture White Paper <http://att.com/ecomp>`__\ [12]_. -One of the main OpenECOMP responsibilities is to rapidly onboard and +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 @@ -603,7 +609,7 @@ 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 OpenECOMP standards to +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**. @@ -611,12 +617,11 @@ resources when deploying services as depicted in **Figure 2**. \ **Figure 2. VNF Complete Lifecycle Stages** -In order to realize these capabilities within the OpenECOMP platform, it +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 OpenECOMP. +VNFs to integrate into ONAP. -Requirements for OpenECOMP Ready can be found in the *VNF Management -Requirements for OpenECOMP* document. +Requirements for ONAP Ready can be found in the *VNF Requirements* document. Design Definition ~~~~~~~~~~~~~~~~~ @@ -635,7 +640,7 @@ and GS NFV IFA011 V0.3.0 (2015-10) - Network Functions Virtualization Configuration Management ~~~~~~~~~~~~~~~~~~~~~~~~ -OpenECOMP must be able to orchestrate and manage the VNF configuration +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 must be allowed directly through standardized APIs without the need for an EMS. @@ -645,13 +650,13 @@ 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. OpenECOMP platform +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 without the need for an 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 OpenECOMP to proactively monitor, test, diagnose +architecture) to allow ONAP to proactively monitor, test, diagnose and trouble shoot the health and behavior of VNFs at their source. Virtualization Environment Ready @@ -707,7 +712,7 @@ 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. AT&T is contributing these guidelines to -the OpenECOMP open source community as a step in moving toward +the ONAP open source community as a step in moving toward standards. These guidelines are based on our experience with large scale deployment and operations of VNFs over the past several years. @@ -727,10 +732,10 @@ these guidelines are expected to remain broadly applicable across a number of service providers interested in acquiring VNFs. We invite feedback on these VNF Guidelines in the context of the -OpenECOMP Project. We anticipate an ongoing project within the OpenECOMP +ONAP Project. We anticipate an ongoing project within the ONAP Community to maintain similar guidance for VNF developers to enable them to more easily develop VNFs which are compatible with the evolving -releases of OpenECOMP. Comments on these guidelines should be discussed +releases of ONAP. Comments on these guidelines should be discussed there. Appendix A - Glossary @@ -739,6 +744,8 @@ Appendix A - Glossary +-------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Heat | Heat is a service to orchestrate composite cloud applications using a declarative template format through an OpenStack-native REST API. | +-------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ +| TOSCA | | ++-------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Network Clouds | Network Clouds 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. | +-------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Network Cloud Service Provider | 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. | @@ -760,11 +767,7 @@ Appendix A - Glossary Appendix B - References ======================= -1. VNF Cloud Readiness Requirements for OpenECOMP - -2. VNF Management Requirements for OpenECOMP - -3. VNF Heat Template Requirements for OpenECOMP +1. VNF Requirements Appendix C - Comparison between VNF Guidelines and ETSI GS NFV-SWA 001 ====================================================================== @@ -778,7 +781,7 @@ 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 OpenECOMP have similarities to ETSI’s MANO, but +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 @@ -806,8 +809,8 @@ the ECOMP Architecture White Paper\ [13]_. Section 4.3 Interfaces ~~~~~~~~~~~~~~~~~~~~~~ -Since OpenECOMP provides the VNFM and EMS functionality for all VNFs the -SWA-3 and SWA-4 interfaces are OpenECOMP interfaces. All OpenECOMP +Since ONAP provides the VNFM and EMS functionality for all VNFs the +SWA-3 and SWA-4 interfaces are ONAP interfaces. All ONAP interfaces are described in this package of documents. Section 5 VNF Design Patterns and Properties @@ -835,16 +838,16 @@ The following are differences between the VNF Guidelines and SWA-001: - 5.1.5 - The VNF Guidelines only accepts horizontal scaling (scale out/in) by VNFC. Vertical scaling (scale up/down) is not supported by - OpenECOMP. + ONAP. -- 5.1.5 - Since OpenECOMP provides all EMS and VNFM functionality - On-Demand scaling is accomplished through OpenECOMP and not directly +- 5.1.5 - Since ONAP provides all EMS and VNFM functionality + On-Demand scaling is accomplished through ONAP and not directly by the VNF Section 5.2 VNF Update and Upgrade ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- 5.2.2 - OpenECOMP will orchestrate updates and upgrades. The +- 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 @@ -859,7 +862,7 @@ The following are differences between the VNF Guidelines and SWA-001: Dependent”. - 5.3.2 – The only virtualization environment currently supported by - OpenECOMP is “Virtual Machines”. The VNF Guidelines state that all + 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. @@ -867,14 +870,14 @@ The following are differences between the VNF Guidelines and SWA-001: - 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 OpenECOMP will provide full +- 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. -- 5.3.11 - The VNF Guidelines only allows for OpenECOMP management of +- 5.3.11 - The VNF Guidelines only allows for ONAP management of the VNF. It does not allow a proprietary management interface for use with a 3rd party EMS @@ -947,7 +950,7 @@ https://creativecommons.org/licenses/by-sa/4.0/legalcode standards for information and communications technologies. .. [4] - Full set of capabilities of Network Cloud and/or OpenECOMP might not + Full set of capabilities of Network Cloud and/or ONAP might not be needed to support traditional IT like workloads. .. [5] |